Recently by Ed Willis

This article is about developing requirements for agile projects. I've used a number of different techniques and have recently happened upon one that's been the best of the bunch for me - hopefully it will prove useful to you as well. Along the way, I'll sketch out a couple of other techniques for comparison.
This article provides a brief introduction to the Capability Maturity Model Integration (CMMI) that aims to cover most of the ground, if at a fairly shallow depth. The CMMI is a process-based model that sketches out a comprehensive picture of development. It builds on that to define a method for developing organization standard processes and for keeping them relevant. Those processes are leveraged to ultimately deploy statistical process control to improve organizational performance. The model is supported by a standard method for assessing an organization, SCAMPI appraisals. My hope is that after reading this article, the reader will be able to make an informed decision on whether or not digging into the CMMI further is warranted. Note that the notion of the "organization" in the CMMI allows for smaller groups within a company to be the focus of CMMI-based process improvement - so you don't have to wait for your whole company to get on board to get started.
Back in 2000, Joel Spolsky published the first version of his "Guerrilla Guide to Interviewing" about hiring developers. Since then, he's published revisions to that article as well as including it in a book on hiring developers. I don't know when I first read it but it certainly stayed with me. Given how frequently people around me reference these sources - especially the guidance about the people to target ("smart and gets things done") - it seems to have resonated with many others out there also. That said, over the last few years I've managed a group that's done a fair bit of hiring and, while I love the confidence of that article, it's not enough for us.
I've managed a group that ran software projects using Scrum but also provided Scrum support to the wider R&D organization by developing Scrum templates and procedures, developing and delivering Scrum training and providing coaching and mentoring for groups taking their first steps down the Scrum path. So, to be honest, I pretty much figured I had Scrum licked. Then I read "Scaling Agile & Lean Development" by Craig Larman and Bas Vodde. I'd yet to scratch the surface of lean and so the excellent treatment lean gets in this book was expected to be new to me, but it was pretty embarrassing how much I learned about Scrum and agile development along the way. If anything it left me feeling a bit of an agile fraud.

News Topics

Recommended for You

Got a Question?