Appendix E: Capability Maturity Model (CMM)

CMM is a framework that describes practices that an organization employs in developing software. CMM consists of five levels, numbered 1 through 5. Level 1 means that the organization doesn ‚ t have any defined, repeatable, or improvable approach to building software; basically, developers hack their way to a solution. At level 5, an organization has a defined, repeatable, and improvable set of practices for developing software. Level 1 is considered an immature organization; level 5 is considered a mature organization. At each level, the practices that should be employed are defined as key practice areas (KPAs). Bill Curtis and Mark Paulk from the Software Engineering Institute (SEI) at Carnegie Mellon University developed CMM in the early 1990s.

If an organization believes that it has thoroughly implemented the KPAs for a specific level, it can engage someone who has been certified by SEI to assess this. If the organization is compliant, it is so certified. Certification is a big deal, because some companies and governmental agencies won ‚ t hire any professional services firm that isn ‚ t certified to at least CMM level 3.

CMM at MegaFund

I introduced MegaFund in earlier chapters. MegaFund spent three years and over $40 million to improve its software development practices until it was certified at CMM level 3. At this level, MegaFund not only had a repeatable approach for managing any conceivable software development project, but it also had formally defined these practices. We looked at how MegaFund scaled a project to quickly support its entry into Web, telephone, and other advanced management of funds by its customers in Chapter 9.

Unfortunately for MegaFund, it had not defined practices that addressed a time-critical project that would automate ill-defined requirements on advanced and untried technologies like the project in Chapter 8. When MegaFund brought in Scrum for this project, the project had already been stalled for over nine months while team members tried unsuccessfully to jump the procedural and bureaucratic hurdles the CMM level 3 imposed on progress in unforeseen and undefined circumstances. I gained an unfavorable impression of CMM from this and later encounters with CMM implementations . However, as I was asked more frequently what I thought of CMM and how it related to Scrum, I realized that I needed more information and knowledge. To this end, I set up a meeting with Mark Paulk at SEI in the fall of 2002.