The SEI addresses Agile

The SEI recently published a paper that asks the provocative question: why not embrace both agile and CMMI? In an earlier post, I wrote that Perficient achieved level 5 using an agile approach, so I know it is possible.

Both CMMI and agile have a long history, it turns out. Although modern agile methodologies mostly emerged in the 1990's in the context of small teams, maybe the origins of agile and CMMI really weren't so different after all.

The paper traces the roots of agile back to Iterative and Incremental Design and Development (IIDD), a technique developed more than 75 years ago by engineers including W. Edwards Deming. It's also noteworthy that Demind is one of the fathers of the lean movement who is credited in part for bring lean to Toyota many decades ago.

An early progenitor of IIDD was Dr. W. Edwards Deming who began promoting Plan-Do-Study-Act (PDSA) as the vital component of empirical engineering. Early adopters of Deming’s teachings in the aerospace industry include NASA (National Aeronautics and Space Administration) and the US Air Force, each of which developed entire systems using time-boxed, iterative, and incremental product development cycles.

Origins of CMMI

everyone working to develop the initial CMM was looking for the solution to the “software problem” from the perspective that software is a component of a larger system and that if it failed, lives would be lost (e.g., aircraft, ships, weaponry, medical devices).Systems were evolved using careful and deliberate development paths according to lower risk,standardization-heavy and contractually-driven relationships between the developer and the customer.

The paper does a good job of explaining some of the reasons why the 2 camps are often at odds, which includes the fact that both approaches are often misused, which adds fuel to the fire.

Here's a paragraph that summarizes the paper's conclusion.

Agile methods provide software development how-to’s, purposely absent from CMMI, which work well on small co-located projects. Meanwhile, CMMI provides the systems engineering practices often required on large, high-risk projects. CMMI also provides the process management and support practices (and principles) that help deploy and continuously improve the deployment of Agile methods in an organization regardless of organization or project size.

I tend to agree, except that agile approaches can also be successful when small teams aren't co-located; I know because I've done it.

A final quote, reminiscent of Rodney King's famous "can't we all just get along?"

If those of us in both the Agile and CMMI camps would understand and accept our differences and explore the advantages of the other, we will find new ways of combining the ideas of both to bring improvement to a whole new level. Our challenge to CMMI and Agile proponents alike is to learn the value of the principles and technology of the other and begin to use them in their work

In my opinion, CMMI is too often misued to force a heavyweight, waterfall methodology on an organization for the primary purpose of marketing the organization's supposed capabilities rather than truly improving the organization's capability to sustainably produce business value for customers. That's why I will probably always be leary of any CMMI initiative started by non-engineer management folks.