"If you still believe that agile and CMMI don't work well together, then what you'll learn in this issue is that, to put it plainly, you're wrong."

Opening Statement

Agile or CMMI. Agile and CMMI. AGILE AND CMMI! AGILE AND CMMI?!?!!#%&***@^@!!

Which is it? Where are you in it?

Is there an answer? The question is still out there.

There are many answers. There is no shortage of theories and angles from which to view both the questions and the answers. This likely explains why the agile CMMI conversation isn't dead yet.

Maybe you're an agile shop looking to adopt CMMI for the marketing benefits or (shh!) for its introduction of some structure, scalability, and discipline, but you're concerned about the expected documentation or the appraisal necessary to "prove" your accomplishments, and you're worried about losing your collaborative, trusting culture. Or perhaps you're a more traditional organization dipping your toe into the agile hot tub and are turned on by the rush of results and happy staff, but you're worried that you'll devolve from your predictable routines and paper trail.

The news in this issue of Cutter IT Journal is that it's not agile or CMMI that fosters your culture, and it's not agile or CMMI that shuns or requires documentation. In fact, as we'll see, it's really not about agile or CMMI. And perhaps "To agile or not to agile?" is the wrong question to ask and the wrong perspective on matters.

If culture and trust are not exclusive to agile methods, and documentation and artifacts are not required from CMMI, where's the problem? What if focusing on "agile" or "CMMI" is a misplaced effort? This issue looks into that. What if learning practices and rote copying by the "cargo cult" set is part of the problem that prevents learning by both sets of practitioners? What if CMMI actually contains valuable ideas that agile teams can use? What if agile teams already do many aspects of CMMI without knowing it? These are the questions our authors address in this issue.

Want case studies? Want a framework in which to make it all work? This edition of Cutter IT Journal has your back. We get a glimpse into several companies that are using CMMI and agile together and successfully earning "levels," and we also see how to put together modular processes that are entirely compatible with both CMMI and agile.

Got really big projects? Got unwieldy engineering? Need to scale agile to work such challenges? Need CMMI to not get in the way of progress? Stop saying "It can't be done here" and start reading how it's being done!

I'm pleased to report that the question is no longer one of whether or not agile and CMMI can coexist. Instead, the question has, if you'll pardon the term, matured to the point where we're asking what's going wrong when they don't work well together and what's going right when they do.

If you still believe that agile and CMMI don't work well together, then what you'll learn in this issue is that, to put it plainly, you're wrong. In fact, not only are you wrong, but by screwing your eyes shut, sticking your fingers in your ears, and yelling "la-la-la-la" at the top of your lungs, you're missing out. Is someone eating your lunch? Oh, what a shame! They're probably successfully blending agile and CMMI in ways you haven't realized were possible. While you were too busy investing in the belief that agile and CMMI are "oil and water," your competition was making and selling salad dressing.

What is likely true of many believers of the oil-and-water myth is that their experiences with agile and CMMI did, in fact, result in very unpleasant outcomes. But why? In all likelihood -- and this contention is supported by this month's contributors -- these horror stories have several characteristics in common. Common causes of horror include: a mandate to "get agile" or "get a CMMI rating"; a culture that punishes failure and experimentation and devalues trust; learning without understanding; CMMI appraisers or agile coaches who operate on practices without appreciating the values and principles of which the practices are merely derivatives; the plethora of appraisers/coaches who don't understand the other domain; mismatches in the work being done and the means of accomplishing the work -- and let's not forget the persistent lack of basic discipline in which neither agile nor CMMI can survive.

The good news is that in this issue we have lined up six articles that address everything from the right questions to ask (in Bill Fox's lead-off piece) to how to deal in an agile manner with very large systems (in a discourse from a number of folks at the venerable Software Engineering Institute). It seems a fairly universal conclusion that it's not agile or CMMI that are incompatible but the way they're applied in a given situation that makes them incompatible.

What's important to note, however, is that situations aren't what cause the incompatibilities, it's how agile and/or CMMI are being applied that make them so. Very often, these incompatibilities are self-inflicted, not imposed by anything in agile or CMMI. To wrap our heads around the topic, the articles are organized to move us through the following stages: thinking, learning, applying, and broadening.

In our first article, Bill Fox looks at whether we're asking the right questions and reflecting on what we're trying to accomplish. By the time you read this, Fox will have interviewed three dozen experts in the field. Within two dozen, he came across a fascinating discovery that can change your own thinking on how to speed delivery and improve quality -- and every other notion often attributed to agile, CMMI, or both. What if success with agile or CMMI really has nothing to do with agile or CMMI? Fox takes us down that thought path.

Next Brian Button and Nate McKie observe that many agile organizations' failures to effectively use CMMI likely result from copying what others are doing without understanding or learning why they do it or why it works. Instead of learning, they argue, too many organizations are rote copying -- and that leads to trouble. Rote copying isn't an agile value and doesn't work in CMMI either. In their article, we get to see, through their eyes, what it's like to apply the agile principle of learning to the adoption of CMMI. The authors relate how using CMMI allowed them to expose and address some of their growing pains, which other companies committed to agile may also experience. From changing what they initially believed about CMMI, to learning from their doing (and certain wrong turns made along the way), Button and McKie discuss what they discovered when they stopped to understand what CMMI was trying to show their agile operation.

Transitioning our attention from learning to application, Paul McMahon exposes "the real underlying obstacles" to agile CMMI and also shows us what can be done about them. He further describes innovative ways to interpret and apply CMMI so that its practices actually make sense in agile settings. McMahon's real-world experience is recast to protect the guilty in a series of accessible cases of actually making it work.

Lest we ignore the demand for specific guidance, Jeff Dalton walks us through a fairly thorough application of CMMI in Scrum settings. He further demonstrates an approach to CMMI that is not only compatible with Scrum, but also uses Scrum and agile thinking to facilitate CMMI! It's not merely a matter of such-and-so Scrum practices demonstrating this-or-that CMMI practice -- that would be both easy and disingenuous. Dalton practices what he preaches and would never lead a company down a path that only solves their performance needs once, leaving them with nothing with which to fend for themselves when circumstances change. Instead, he offers us a delightfully simple and robust architecture that we can use to build processes incrementally and iteratively. How agile!

We round out the issue by getting into more thought-provoking ideas with work from Cutter Senior Consultant Scott Ambler, a well-known columnist, Internet agile personality, and author. Ambler discusses an architecture for disciplined agile delivery and what happens when it ... meets CMMI. It's not exactly a complete smackdown, but it definitely makes us rethink what we know about agile and CMMI! Ambler pulls data from several broad, well-thought-out industry surveys he's conducted and scrutinizes the results. He addresses the "agile vs. CMMI" rhetoric head on and describes a framework he's been working on based on the findings. The result, Disciplined Agile Delivery (DAD), is a decision framework for determining the right processes to use. In the article, he points out how DAD supports both agile and CMMI and provides the means of letting you figure out what will work best for your organization. He doesn't let CMMI practitioners off the hook for their predisposition to focus on processes rather than results, but he also holds the agilistas' feet to the fire to evolve and mature as well.

Finally, if ever there were a way to confront resistance from either agile or CMMI, it would be embodied in the SEI's broad perspective on "agility-at-scale." You think you've got agile/CMMI compatibility issues? They're child's play compared to what you'll see the SEI is up to. Unless you plan to work out of your minivan for the rest of your career, you don't want to miss the mind-expanding problems that Doug Schmidt and his coauthors are dealing with! Schmidt et al. observe that everyone wants to "be agile," but sticking to agile practices and lore when they've run out of utility is like sticking with a brand of running shoes when they've stopped providing you support. Looking at the matter from the perspective of questions about risk, measures, technical debt, and strategy sounds uncharacteristically like business value, not process compliance. Well, it may come as a surprise to some, but at the SEI, these topics have always been at the center of CMMI. Which returns us to our starting point: it's not what's in CMMI or agile that causes this conversation to remain in play, it's what you do with them.

I hope you enjoy this month's Cutter IT Journal and welcome your thoughts!

ABOUT THE AUTHOR