Jeff Sutherland (co-creator of Scrum) has just posted on using Scrum in a CMMI Level 5 environment. CMMI Level anything, almost without exception, implies that an organisation is running with a waterfall process with lots of paperwork and red tape involved. If asked, most people would say that CMMI is all about increasing levels of bureaucracy and paperwork in software development, and it means that software takes for ever to get delivered. While this may be right in most cases, in many respects this is unfortunate because at it's heart CMMI is not about adding red tape and slowing down the process at all, but rather it's about evaluating how good a company is at delivering software on a repeatable bases. Yet, when you look at the definitions of the various levels you can see why people get this impression:

Level 1 - Uncertainty. Success depends on individual effort.
Level 2 - Awakening. Basic project management practices are established.
Level 3 - Enlightenment. Standard process throughout organization.
Level 4 - Wisdom. Detailed metrics are collected and evaluated.
Level 5 - Certainty. Continuous process improvement via metrics feedback.

Anything that talks about "management practices", "standard processes", and "detailed metrics" will make most people instantly think of the waterfall delivery processes, limited flexibility and mountains of paperwork (especially when metrics are discussed). What people don't think about is that an agile methodology like scrum not only covers the areas of "management practices", "standard processes" and "detailed metrics" but it also provides for the "continuous improvement via feedback" needed for CMMI Level 5 and does so in a way that cuts through the meaningless paperwork, the tedious meetings, the wasted up front design efforts and provides a platform for managing and adapting to the inevitable change that all software projects experience.

So what happens when a company is brave enough to introduce Scrum into a CMMI:5 environment? Here's what Jeff found:

- Productivity doubled in less than six months reducing total project costs by 50%.

- Defects were reduced by 40% in all Scrum projects (despite the fact this company already had one of the lowest defect rates in the world.)

- Planning costs were reduced by about 80%.

- User satisfaction and developer satisfaction were much higher than comparable waterfall implementations.

- Projects were linearly scalable, something never seen before. The productivity of individual developers remains the same as the project increases in size.

That first statistic alone is enough to make senior management sit up and pay attention, but when combined with linear scalability and improved satisfaction, it's hard to think of reasons why Scrum shouldn't be used in most software development projects.

Thanks and credit to Jeff Sutherland, Carsten Jakobsen and Kent Johnson for the work they've done and the guts shown in not only implementing Scrum in a CMMI environment, but also in putting this information together. For more detail read the findings.