The topic of CMMI and Agile has come up again with a Technical Note from SEI on how CMMI and Agile might be somehow connected. This is one of those "must read" papers. But not necessarily for the reasons the authors might expect.
The abstract opens with:
are often perceived to be at odds with each other. This report clarifies why the discord need not exist and proposes that CMMI and Agile champions work toward deriving benefit from using
both and exploit synergy's that have the potential to dramatically improve business performance.
This is a common perception for many reasons. But the first sentence in the Problem Definition section is a bit puzzling at least so for a hypothesis statement:
and conflict as the adoption of each approach increases. In addition, each approach includes principles of good software development often overlooked but needed by the other approach thus being knowledgeable in both is important to project success. In the long term, this discordant situation is not healthy for the software engineering profession.
It's not clear from my experience that CMMI shops in the space and defense business are seeking agile in the way the Agile proponents would like them too. Much of the software developed in A&D (aerospace and defense) using the CMMI Framework is also DO-178B and DO-248A driven. These specifications are probably unheard of outside the flight software world. In the Nuclear Power world NQA-1 is another software verification and validation specification. 21CFR in the pharma and medical equipment world, Oil & Gas process controls have another, turbines and off shore have SINTEF software guidelines, etc. etc.
So the question is:
This is an important question for several reasons:
- There may be competitive advantages from agile that need to be explored.
- The current development processes may need improving for all the right reasons, while maintaining the CMMI appraisal level. But I will say the red herring of Waterfall is rarely practiced in any mature defense software organization. In fact Spiral is mandated by DoD.
- There may be some advantages to agile development processes for adopting some the Process Areas of CMMI in areas where more rigor is needed for all the right reasons.
The paper doesn't address these, which is not a problem. But the questions are still there for us here in the field.
The Conclusion provides some boundaries for further discussion:
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 wouldn't have used the term purposely absent, since CMMI provides little or no guidance for any of the Process Areas at the implementation level. I'm deeply involved in the Program Planning and Controls Process Areas, where scant advice is provided on how to comply using our EVMS/748B approaches. Although the SCAMPI guidance does provide "some" appraisal evidence suggestions.
What's more interesting though is:
A scaling limitation of several Agile methods has yet to be overcome with any consistency while
still adhering to Agile principles. Adhering to Agile principles is inherently challenging given the
context of large, long-term projects with geographically and organizationally dispersed project
teams (a situation whose prevalence may be increasing). The mode of communication on large
projects—in terms of spanning distance, time, and audiences—is necessarily a slower more involved endeavor than is possible with face-to-face, real-time, kinetic presence among project team members.
The mode of communication on large projects is not in the style of agile for good reason. Large projects are expensive, have inherent risks not directly associated with the requirements, and most often involve many layers of contribution and control. Formal communications keeps all these moving parts moving. The Integrated Product Team (IPT) approach is the response. As well the Systems Engineering paradigm, of managing requirements and progress reporting at the interfaces is another approach.
But the authors restate the obvious and may have not experienced the current management approaches in large scale defense and space programs when they conclude:
Although the complexities of large-scale projects require a more involved infrastructure, this fact is not a license to create unnecessary bureaucracies and unbalanced production at the expense of productivity. This creation of unnecessary bureaucracy occurs especially, but is not limited to, when CMMI is misused and a level rating is the principal expected outcome of a CMMI-based process improvement effort. As a result, over-engineering within process improvement activities is a common issue.
Over engineering, unnecessary bureaucracies and unbalanced production is not caused by CMMI. It is caused by poor management. This is a common "red herring" for some reason. Initiatives like LM21 (Lockheed Martin 21st Century) is a poster child for how to have rigor within adaptation.
Conclusion
In my direct experience of deploying Agile within the CMMI framework, the starting point is CMMI. Then the Agile work processes not only have a home, they have a framework that can be used to assess their usefulness. Section 10 has the beginnings of a comparison of CMMI and Agile practices. But it has some over generalized content. CMMI can be applied to specific programs (I'm on one), specific activities within a Program (I'm on one of those as well), departments or roles within a Business Unit (we have those too), or possibly an Enterprise. The summary seems to continue these over generalizations in ways that make it difficult to apply their learning's to specific programs or business activities.
It seems from the comparisons that what is missing is the hands on day to day execution of a program using CMMI. When I walked through the content of Table 1, with our Program Planning and Controls staff and their CAMs (Control Account Managers) on a major manned spaceflight avionics program, there were lots of wrinked foreheads and comments like "naw that can't be right."
One author is a Lead Appraiser, who "understands small agile firms" (says the tag line), one is from a technology strategy company (CMMI Partner), one an Agile Thought Leader, and 2 CMMI authors. Having directly experienced CMMI at the execution level and working closely with internal Lead Appraisers, there is a wide variety of experiences, capabiltiies, and even opinions of what it means to be CMMI Level 3.
So in the end this paper is a great start to the conversation. As they state:
This report clarifies why the discord need not exist and proposes that CMMI and Agile champions work toward deriving benefit from using both and exploit synergies that have the potential to dramatically improve business performance.
Much more work remains. And most critically direct field experiences from Programs where CMMI is considered Mission Critical, niot just a a "check in the box." This means people die, entire country sides are poluted or made uninhabitable, or licenses to operate are revolked. You know "real projects."
