The Journal of Information Technology Management

Cutter IT Journal

Vol. 25, No. 11November 2012

Agile CMMI:Why Isn’t This ConversationDead Yet?

Opening Statementby Hillel Glazer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

The Agile CMMI Conversation Is a Dead Endby Bill Fox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Blending Agile and CMMIby Brian Button and Nate McKie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Agile CMMI: The Real Underlying Obstacles to Effective Integration and What You Can Do About Them by Paul E. McMahon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

CMMI vs. Scrum? No — CMMI + Scrum!by Jeff Dalton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Disciplined Agile Delivery Meets CMMIby Scott W. Ambler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

What Will It Take to Achieve Agility-at-Scale?by Douglas Schmidt, Anita Carleton, Erin Harper, Mary Ann Lapham, Ipek Ozkaya, and Linda Parker Gates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

“If you still believe that agileand CMMI don’t work welltogether, then what you’lllearn in this issue is that, toput it plainly, you’re wrong.”

— Hillel Glazer,Guest Editor

Cutter IT Journal®

Cutter Business Technology Council:Rob Austin, Ron Blitstein, Tom DeMarco,Lynne Ellyn, Israel Gat, Vince Kellen,Tim Lister, Lou Mazzucchelli,Ken Orr, and Robert D. Scott

Editor Emeritus: Ed YourdonPublisher: Karen Fine CoburnGroup Publisher: Chris GeneraliManaging Editor: Karen PasleyProduction Editor: Linda M. DiasClient Services: service@cutter.com

Cutter IT Journal® is published 12 timesa year by Cutter Information LLC,37 Broadway, Suite 1, Arlington, MA02474-5552, USA (Tel: +1 781 6488700; Fax: +1 781 648 8707; Email: citjeditorial@cutter.com; Website:www.cutter.com; Twitter: @cuttertweets;Facebook: Cutter Consortium). PrintISSN: 1522-7383; online/electronic ISSN: 1554-5946.

©2012 by Cutter Information LLC. All rights reserved. Cutter IT Journal®is a trademark of Cutter Information LLC.No material in this publication may bereproduced, eaten, or distributed withoutwritten permission from the publisher.Unauthorized reproduction in any form,including photocopying, downloadingelectronic copies, posting on the Internet,image scanning, and faxing is against thelaw. Reprints make an excellent trainingtool. For information about reprints and/or back issues of Cutter Consortiumpublications, call +1 781 648 8700or email service@cutter.com.

Subscription rates are US $485 a yearin North America, US $585 elsewhere,payable to Cutter Information LLC.Reprints, bulk purchases, past issues,and multiple subscription and site licenserates are available on request.

Part of Cutter Consortium’s mission is tofoster debate and dialogue on the businesstechnology issues challenging enterprisestoday, helping organizations leverage IT forcompetitive advantage and business success.Cutter’s philosophy is that most of the issuesthat managers face are complex enough tomerit examination that goes beyond simplepronouncements. Founded in 1987 asAmerican Programmer by Ed Yourdon,Cutter IT Journal is one of Cutter’s keyvenues for debate.

The monthly Cutter IT Journal and its com-panion Cutter IT Advisor offer a variety ofperspectives on the issues you’re dealing withtoday. Armed with opinion, data, and advice,you’ll be able to make the best decisions,employ the best practices, and choose theright strategies for your organization.

Unlike academic journals, Cutter IT Journaldoesn’t water down or delay its coverage oftimely issues with lengthy peer reviews. Eachmonth, our expert Guest Editor delivers arti-cles by internationally known IT practitionersthat include case studies, research findings,and experience-based opinion on the IT topicsenterprises face today — not issues you weredealing with six months ago, or those thatare so esoteric you might not ever need tolearn from others’ experiences. No otherjournal brings together so many cutting-edge thinkers or lets them speak so bluntly.

Cutter IT Journal subscribers consider theJournal a “consultancy in print” and likeneach month’s issue to the impassioneddebates they participate in at the end ofa day at a conference.

Every facet of IT — application integration,security, portfolio management, and testing,to name a few — plays a role in the successor failure of your organization’s IT efforts.Only Cutter IT Journal and Cutter IT Advisordeliver a comprehensive treatment of thesecritical issues and help you make informeddecisions about the strategies that canimprove IT’s performance.

Cutter IT Journal is unique in that it is writtenby IT professionals — people like you whoface the same challenges and are under thesame pressures to get the job done. Cutter IT Journal brings you frank, honest accountsof what works, what doesn’t, and why.

Put your IT concerns in a business context.Discover the best ways to pitch new ideasto executive management. Ensure the successof your IT organization in an economy thatencourages outsourcing and intense inter-national competition. Avoid the commonpitfalls and work smarter while under tighterconstraints. You’ll learn how to do all this andmore when you subscribe to Cutter IT Journal.

About Cutter IT Journal

Cutter IT Journal

Name Title

Company Address

City State/Province ZIP/Postal Code

Email (Be sure to include for weekly Cutter IT Advisor)

Fax to +1 781 648 8707, call +1 781 648 8700, or send email to service@cutter.com. Mail to Cutter Consortium, 37 Broadway,Suite 1, Arlington, MA 02474-5552, USA.

SUBSCRIBE TODAY

Request Online LicenseSubscription Rates

For subscription rates for online licenses,contact us at sales@cutter.com or+1 781 648 8700.

Start my print subscription to Cutter IT Journal ($485/year; US $585 outside North America)

Opening Statement

3Vol. 25, No. 11 CUTTER IT JOURNAL

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 theo-ries and angles from which to view both the questionsand the answers. This likely explains why the agileCMMI conversation isn’t dead yet.

Maybe you’re an agile shop looking to adopt CMMI forthe marketing benefits or (shh!) for its introduction ofsome structure, scalability, and discipline, but you’reconcerned about the expected documentation or theappraisal necessary to “prove” your accomplishments,and you’re worried about losing your collaborative,trusting culture. Or perhaps you’re a more traditionalorganization dipping your toe into the agile hot tuband are turned on by the rush of results and happystaff, but you’re worried that you’ll devolve from yourpredictable routines and paper trail.

The news in this issue of Cutter IT Journal is that it’snot agile or CMMI that fosters your culture, and it’s notagile 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 wrongquestion 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 fromCMMI, where’s the problem? What if focusing on“agile” or “CMMI” is a misplaced effort? This issuelooks into that. What if learning practices and rotecopying by the “cargo cult” set is part of the problemthat prevents learning by both sets of practitioners?What if CMMI actually contains valuable ideas thatagile teams can use? What if agile teams already domany aspects of CMMI without knowing it? Theseare the questions our authors address in this issue.

Want case studies? Want a framework in which tomake it all work? This edition of Cutter IT Journalhas your back. We get a glimpse into several com-panies that are using CMMI and agile together and

successfully earning “levels,” and we also see howto put together modular processes that are entirelycompatible with both CMMI and agile.

Got really big projects? Got unwieldy engineering?Need to scale agile to work such challenges? NeedCMMI to not get in the way of progress? Stop saying“It can’t be done here” and start reading how it’sbeing done!

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

If you still believe that agile and CMMI don’t work welltogether, then what you’ll learn in this issue is that, toput it plainly, you’re wrong. In fact, not only are youwrong, but by screwing your eyes shut, sticking yourfingers in your ears, and yelling “la-la-la-la” at the top ofyour lungs, you’re missing out. Is someone eating yourlunch? Oh, what a shame! They’re probably successfullyblending agile and CMMI in ways you haven’t realizedwere possible. While you were too busy investing in thebelief that agile and CMMI are “oil and water,” yourcompetition 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 andCMMI did, in fact, result in very unpleasant outcomes.But why? In all likelihood — and this contention issupported by this month’s contributors — these horrorstories have several characteristics in common. Commoncauses of horror include: a mandate to “get agile” or“get a CMMI rating”; a culture that punishes failure and

by Hillel Glazer, Guest Editor

Get The Cutter Edge free: www.cutter.com

If culture and trust are not exclusive to agilemethods, and documentation and artifacts arenot required from CMMI, where’s the problem?

©2012 Cutter Information LLCCUTTER IT JOURNAL November 20124

experimentation and devalues trust; learning withoutunderstanding; CMMI appraisers or agile coaches whooperate on practices without appreciating the values andprinciples of which the practices are merely derivatives;the plethora of appraisers/coaches who don’t under-stand the other domain; mismatches in the work beingdone and the means of accomplishing the work — andlet’s not forget the persistent lack of basic discipline inwhich neither agile nor CMMI can survive.

The good news is that in this issue we have lined upsix articles that address everything from the rightquestions to ask (in Bill Fox’s lead-off piece) to howto deal in an agile manner with very large systems(in a discourse from a number of folks at the venerableSoftware Engineering Institute). It seems a fairly uni-versal conclusion that it’s not agile or CMMI that areincompatible but the way they’re applied in a givensituation that makes them incompatible.

What’s important to note, however, is that situationsaren’t what cause the incompatibilities, it’s how agileand/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 wrapour heads around the topic, the articles are organizedto move us through the following stages: thinking,learning, applying, and broadening.

In our first article, Bill Fox looks at whether we’reasking the right questions and reflecting on what we’retrying to accomplish. By the time you read this, Foxwill have interviewed three dozen experts in the field.Within two dozen, he came across a fascinating discov-ery that can change your own thinking on how to speeddelivery and improve quality — and every other notionoften attributed to agile, CMMI, or both. What if successwith agile or CMMI really has nothing to do with agileor CMMI? Fox takes us down that thought path.

Next Brian Button and Nate McKie observe that manyagile organizations’ failures to effectively use CMMIlikely result from copying what others are doing with-out understanding or learning why they do it or whyit works. Instead of learning, they argue, too many orga-nizations are rote copying — and that leads to trouble.Rote copying isn’t an agile value and doesn’t work inCMMI either. In their article, we get to see, throughtheir eyes, what it’s like to apply the agile principle oflearning to the adoption of CMMI. The authors relatehow using CMMI allowed them to expose and addresssome of their growing pains, which other companiescommitted to agile may also experience. From changingwhat they initially believed about CMMI, to learningfrom their doing (and certain wrong turns made alongthe way), Button and McKie discuss what they discov-ered when they stopped to understand what CMMI wastrying 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 doneabout them. He further describes innovative ways tointerpret and apply CMMI so that its practices actuallymake sense in agile settings. McMahon’s real-worldexperience is recast to protect the guilty in a series ofaccessible cases of actually making it work.

Lest we ignore the demand for specific guidance, JeffDalton walks us through a fairly thorough applicationof CMMI in Scrum settings. He further demonstratesan approach to CMMI that is not only compatible withScrum, but also uses Scrum and agile thinking to facili-tate CMMI! It’s not merely a matter of such-and-soScrum practices demonstrating this-or-that CMMIpractice — that would be both easy and disingenuous.Dalton practices what he preaches and would neverlead a company down a path that only solves theirperformance needs once, leaving them with nothingwith which to fend for themselves when circumstanceschange. Instead, he offers us a delightfully simple androbust architecture that we can use to build processesincrementally and iteratively. How agile!

UPCOMING TOPICS IN CUTTER IT JOURNAL

DECEMBER Roger Evernden

Enterprise Patterns

JANUARYVince Kellen

SMAC: Social, Mobile, Analytics, and Cloud

It seems a fairly universal conclusion that it’snot agile or CMMI that are incompatible butthe way they’re applied in a given situationthat makes them incompatible.

5Get The Cutter Edge free: www.cutter.com Vol. 25, No. 11 CUTTER IT JOURNAL

We round out the issue by getting into more thought-provoking ideas with work from Cutter SeniorConsultant Scott Ambler, a well-known columnist,Internet agile personality, and author. Ambler discussesan architecture for disciplined agile delivery and whathappens when it … meets CMMI. It’s not exactly a com-plete smackdown, but it definitely makes us rethinkwhat we know about agile and CMMI! Ambler pullsdata from several broad, well-thought-out industrysurveys he’s conducted and scrutinizes the results. Headdresses the “agile vs. CMMI” rhetoric head on anddescribes a framework he’s been working on based onthe findings. The result, Disciplined Agile Delivery(DAD), is a decision framework for determining theright processes to use. In the article, he points out howDAD supports both agile and CMMI and provides themeans of letting you figure out what will work bestfor your organization. He doesn’t let CMMI practition-ers off the hook for their predisposition to focus onprocesses rather than results, but he also holds theagilistas’ feet to the fire to evolve and mature as well.

Finally, if ever there were a way to confront resistancefrom either agile or CMMI, it would be embodied in theSEI’s broad perspective on “agility-at-scale.” You thinkyou’ve got agile/CMMI compatibility issues? They’rechild’s play compared to what you’ll see the SEI is upto. Unless you plan to work out of your minivan forthe rest of your career, you don’t want to miss themind-expanding problems that Doug Schmidt andhis coauthors are dealing with! Schmidt et al. observethat everyone wants to “be agile,” but sticking to agilepractices and lore when they’ve run out of utility is likesticking with a brand of running shoes when they’vestopped providing you support. Looking at the matterfrom the perspective of questions about risk, measures,technical debt, and strategy sounds uncharacteristicallylike business value, not process compliance. Well, itmay come as a surprise to some, but at the SEI, these

topics have always been at the center of CMMI. Whichreturns us to our starting point: it’s not what’s in CMMIor 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 andwelcome your thoughts!

Hillel Glazer, a Senior Consultant with Cutter’s Agile Product& Project Management practice, is recognized as the world’sleading authority on introducing Lean and Agile concepts into thecompliance-driven world. Mr. Glazer has helped companies of allsizes and industries around the world successfully streamline theiroperations, increase value, and expose and eliminate practices thatprevent them from achieving their performance goals. And he doesso while simultaneously accounting for all the external compliancepressures on their operations.

Mr. Glazer has been successfully pioneering the introduction of Leanphilosophies, methods, and techniques into businesses and industriesotherwise believed to be either too chaotic or too constrained by theircompliance and regulation requirements to adopt high-performanceapproaches. His leadership, originality, excellence, and direct contribu-tion to the community in this field have been recognized by the LeanSystems Society, which honored him as a Fellow of the Lean SystemsSociety in its inaugural induction of fellows.

As an in-demand speaker, presenter, and facilitator, Mr. Glazer iswidely read, broadly published, and appears worldwide on the topicspertaining to operational excellence in compliance-driven industries.His work appears in many publications, including periodicals andthe following SEI publications: CMMI for Services, CMMI forDevelopment, and Integrating CMMI and Agile Development.He is the lead author of the SEI’s 2008 seminal Agile/CMMI work,“CMMI or Agile: Why Not Embrace Both!” and author of the well-received book High Performance Operations.

Currently, Mr. Glazer is focusing attention on Agile in systems engi-neering and Lean at the enterprise. He lives in the Baltimore suburbswith his fabulous wife and four amazing children, and when not trav-eling around the planet making Lean and Agile things happen, he’s anavid pilot, musician, and an active volunteer with several nonprofitsand charities. He can be reached at hglazer@cutter.com.

©2012 Cutter Information LLCCUTTER IT JOURNAL November 201222

When searching for inspiration, I turn to Charlie Parker.

Charlie “Bird” Parker was a brilliant, though seriouslyflawed, pioneer of the American jazz scene. While hispersonal challenges are well documented, Parker isknown as the undisputed master of the idiom, whounderstood that being great was not simply about beingtalented. His legacy, regarded by music historians asone of the most powerful in the history of Americanmusic, was not an accident. It was arrived at throughyears of disciplined study, practice, and experimenta-tion, which resulted in the very definition of the artform. But it was not simply about study, nor was it onlyabout a disciplined adherence to structure. Parker knewwhat so many in software engineering still struggleto understand today: that great accomplishments areachieved through mastering and synthesizing all threeelements — talent, learning, and discipline.

What really set Bird apart was his ability to masterthese concepts with extraordinary agility. When heperformed, he heard something very different fromthe music of his predecessors. While standing firmlyon the shoulders of the giants who came before him,he created a new, agile style that catapulted jazz intoan entirely new dimension. With its short bursts of cre-ativity, rapid real-time adaptations, and incremental,iterative improvisational character, this style — whichcame to be known as “be-bop” — would be betterdescribed as real-time composition.

Unlike the music that preceded Parker’s 1939 debut, hiswas incremental and iterative in three dimensions. The

first was internal to the skills of any accomplishedmusician, who learns to hear the sound in the split-second it takes for it to escape his or her instrument,and then incrementally inspects and adapts the tone,inflection, and pitch — sometimes before the soundwave has even reached the audience. The seconddimension was the real-time collaboration among andbetween the members of his group: between saxophoneand piano, between drums and bass, between pianoand guitar, and a continuous build of those collabora-tions across the ensemble. The magic of be-bop is inthe real-time composition created when a group ofaccomplished players collaborate as a team, fail fast,and deliver the minimum viable product throughoutthe course of the composition. Finally, Bird wouldcollaborate with his audience — reading their reaction,inspecting and adapting, and recalibrating his comp-ositions to meet the desires of his fans.

If it sounds as though I’m saying that agile methodshave been around a lot longer than Scrum, XP, and thespiral model, I am. While I have immense respect forthe authors of the Agile Manifesto,1 they were 60 yearsbehind Bird.

The lessons from Charlie Parker are as relevant to agileteams today as they were to musicians in the 1940s —most software organizations still struggle with the syn-thesis of talent, learning, and discipline. It’s not for lackof trying. The landscape is littered with models, tech-niques, and tools in search of software’s perfect chord,yet we continue to struggle with the processes required

CMMI vs. Scrum? No — CMMI + Scrum!by Jeff Dalton

MAKING AGILE BETTER

Product Backlog Sprint Backlog Sprint Sprint Demo

“The Set” “The Tune” “Rewriting the Tune” “Applause“

Figure 1 — The first agile teams.

23Get The Cutter Edge free: www.cutter.com Vol. 25, No. 11 CUTTER IT JOURNAL

to improve productivity and increase the predictabilityand stability of software projects.

The theme of this issue is “Agile CMMI: Why Isn’t ThisConversation Dead Yet?” It’s a great question, and onethat I ask myself frequently when, for the 20th time eachweek, someone asks on my blog,2 “Are CMMI and agilecompatible?” For five years,I’ve dutifully answered thequestion with a resounding “Yes!” and a full explana-tion of how it might work. However, instead of explor-ing that question yet again, I suggest that we arefocusing on the wrong question altogether.

I would posit that the right question is “CMMI andagile together: why aren’t we having this conversation?”In a community whose most vexing problem is how tomake agile work in a business that is decidedly notagile, it would seem that characteristics inherent in thearchitecture of CMMI — robustness, scalability, pre-dictability, and structure — would be useful in scalingagile to the enterprise.

It’s not that CMMI and agile don’t work well together;of course they do. Given the fact the agile exists toimprove the products we build, and CMMI exists toimprove how that work is accomplished, why are wenot using them together? Why not embrace CMMI tomake agile better?

WHY NOT EMBRACE BOTH! A HISTORY

Agile puristas scoff at the idea. CMMI process teamsshake their heads, struggling to understand how theycan simultaneously “get a level” and be agile. In ourSoftware Engineering Institute (SEI) Technical Note“CMMI or Agile: Why Not Embrace Both!”3 my coau-thors and I argue that there is no real conflict betweenthese communities — only a complex misunderstandingbased on an unfortunate confluence of events. Indeed,there are not two communities; there is just one, whoseonly desire is to bring excellence to software engineer-ing. Think about it. Both CMMI and agile methods existfor the same reason: to help us build better products.

In the 1980s, before agile was “agile,” and almost 15years before CMMI reached maturity, the SEI sprangforth as a federally funded R&D center, forging a part-nership between government and academia whosefocus was on the research and development of newways to improve the state of software engineering.While the SEI has done a remarkable job expandingits scope over the years to include other models andtechnologies — most notably CMMI for Services(CMMI-SVC), People-CMM, and CMMI for Acquisition(CMMI-ACQ) — it is the Capability Maturity Model

Integration for Development (CMMI-DEV) that hasbeen its crown jewel and most successful product formany years.

When considering the perspective of the research scien-tists at the SEI during that period and the methods thatwere dominating the software industry at the time, onemight forgive them for not promoting agile methods,such as Scrum, which had not yet been established. Thatthe CMMI hasn’t done so since is not the result of anoversight or lack of understanding, as its critics oftensuggest. Rather, CMMI is a method-agnostic modelthat is more akin to a behavioral improvement model thanan engineering process improvement model. It was neverintended as a process to be followed, but as frameworkto improve the methods we are following. And to thosewho continue to believe that CMMI is about “fillingout forms” and “getting a level,” I would ask, how dothose things improve the performance of the methodssoftware teams are using?

The language embraced within the CMM for Software(SW-CMM), and later CMMI, was based on the pre-vailing language of the day, such as “Work BreakdownStructure,” “Configuration Status Accounting,” “ProjectAudits,” “Technical Data Package,” and others that arestill present in the latest version of CMMI-DEV (v1.3).For agile evangelists, this language appears to clashwith agile values and has led to the persistent questionsabout CMMI’s compatibility with agile. These questionsabout compatibility are rooted in the perception, voicedby many in our industry, that CMMI was intended foruse in traditional waterfall-style project environments.

Members of the agile community routinely use thephrases “top-down,” “command and control,” and “low-trust environment” to describe both CMMI and waterfall-style methods, but associations between those phrasesand CMMI are incorrectly applied. In order to under-stand how software professionals came to see CMMI asanalogous to waterfall, and seemingly at odds with thevalues of the Agile Manifesto, we must consider the timeframe and the predominant methodologies that existedwhen SW-CMM, and subsequently CMMI, were beingdeveloped. While researching and compiling their work,the staff at the SEI — who, like agile teams, are prettygood at collaboration themselves — enlisted the expertise

CMMI was never intended as a process tobe followed, but as framework to improvethe methods we are following.

©2012 Cutter Information LLCCUTTER IT JOURNAL November 201224

and input of a broad cross-section of organizations thatwere demonstrating success in software engineering.Many of these organizations were running successful,large-scale programs using what we now call “tradi-tional” or “waterfall” lifecycle models, and many of theseorganizations became early adopters.

As CMMI became more popular, so did the case studiesof the early adopters, thus setting a standard for CMMIimplementation that mirrored their successes. The USfederal government’s mandate (now expired) that itssoftware suppliers achieve a level of CMMI drove lateradopters to emulate their predecessors, and thus apattern was established for everyone to follow.

Today, a growing number of agile software teams arechallenging the conventional wisdom that continuousprocess improvement requires substantial investmentsin overhead and documentation. Instead, they favorreal-time collaboration, information radiators, colocatedteam rooms, and increased transparency within theteam. These agile values are not in conflict with theintent of CMMI. They may be in conflict with the valuesof the early adopters, but their use of the model wasonly a single instantiation from an unlimited set ofpossibilities. Those early users were simply applyingCMMI in the way it was intended — to make whatthey were already doing better!

Agile methods, like more traditional waterfall methods,are a collection of values and techniques that are appliedin order to accomplish a task. Instantiations of agile suchas Scrum encapsulate those values and techniques into asystem that delivers value to customers in an iterative,collaborative, and transparent way. CMMI is neither aset of values, nor a set of techniques. It’s a set of guide-lines intended to make any software development

approach — whether it be agile or traditional — more efficient, effective, and predictable.

CMMI CAN IMPROVE AGILE

As I often say to my students, CMMI is many thingsto many people.

Some see it as a way to measure organizational perfor-mance. Others see a requirement for bidding on federalcontracts that only adds overhead. Some others see itas a giant checklist of “must have” process steps, whilestill others see a set of guidelines for continuousimprovement.

CMMI-DEV is organized into a hierarchy of 22 processareas (PAs), each with multiple goals, practices, andsubpractices. While these process areas contain clustersof related practices, they are not processes, and it isnecessary to trace a path between multiple PAs andpractices in order to “follow a thread” as one establishesa localized model that can be applied to an organiza-tion’s instantiation of agile methods.

Traditionally, and all too often, companies take a“CMMI-centric” approach to process developmentthat is model-focused rather than value-focused.This results in a process with excessive “process debt”that does not reflect the values of the organization.

Consider the process flow in Figure 2, which takes amodel-centric approach to defining part of a planningprocess. We often see something like this when aprocess is designed to “comply” with CMMI.

I prefer to interpret CMMI as a set of questions about theenvironment in which we choose to work. The answersto those questions will determine the experience that

EstablishScope

EstimateWork

Productsand Tasks

DefineLifecycle

EstimateEffort

DevelopProject

Plan

Figure 2 — Linear, model-centric processes don’t reflect agile values.

25Get The Cutter Edge free: www.cutter.com Vol. 25, No. 11 CUTTER IT JOURNAL

practitioners will have, and they will also affect the qual-ity of a software team’s products and the predictabilityof project delivery.

The questions must be asked within the context of teamnorms and the methods and techniques that the teamhas agreed to adopt. Interestingly, this is precisely howwe should conduct CMMI-based SCAMPI Appraisalsfor any type of software development organization.

A value-focused approach for an agile project mightseek to answer the following questions, derived fromCMMI, about planning for releases and sprints:

How are we projecting our ability to deliver value?

How long will our sprints be? How many sprints arein a release?

Is our team clear on how we’ll interact with projectstakeholders?

Do we know what we need to produce duringthe sprint?

Have we broken down our stories into tasks?

How will we know how our sprint is progressing?

What keeps us up at night? Where do these risksoriginate?

Figure 3 shows the process flow from Figure 2 reimag-ined as a value-focused process using questions derivedfrom CMMI but translated to the local team’s language.

A value-focused approach is more concerned with thenatural flow of the work that is to be accomplished andless concerned with adherence to a linear, step-by-stepprocess, letting a task management framework suchas Scrum drive the sequence. In this way, the “process

assets” evolve into a set of process objects that haveencapsulated within them a robust set of characteristicsthat enable them to be adopted by the enterprise andimproved over time. These process objects are instan-tiated as needed, based on the goals and objectivesof the organization and the desire to improve on thehighest-priority aspects of agile performance.

The practices that CMMI makes available to us includethose that help bring greater clarity and strength to theScrum ceremonies themselves (the “specific practices,”or SPs), and those that help strengthen the understand-ing, adoption, and continuous improvement of the agilevalues and behaviors (the “generic practices,” or GPs).Scrum ceremonies are loosely defined, with implemen-tation left to self-organizing teams. While teams thatare performing Scrum with integrity would be loath toaccept rigid process oversight, the fact remains that suc-cessful implementation across the enterprise has provenelusive to many companies, especially where organi-zations have attempted to scale agile by applying a“Scrum of Scrums” framework. How can we strengthenScrum so that it can scale?

Figure 3 — Agile planning is iterative and incremental.

How can we strengthen Scrum so that itcan scale? The solution lies not in applyingCMMI directly to Scrum, but in asking the“CMMI questions” of an organization’sScrum ceremonies.

©2012 Cutter Information LLCCUTTER IT JOURNAL November 201226

The solution lies not in applying CMMI directly toScrum, but in asking the “CMMI questions” of anorganization’s Scrum ceremonies. For example, thefollowing questions are derived from CMMI:

Release Planning

How many epics should be in a release?

How are epics allocated to each release?

How often are releases scheduled?

How are releases organized into a definable lifecyclethat we can communicate to our business customer?

How many sprints are contained within a release?

How many story points are projected to be in eachrelease?

Sprint Planning

How long are our sprints?

What criteria determine the length of sprints?

How are stories allocated to each sprint?

What criteria are used to determine allocation?

Sprints

What design artifacts are useful to our teams?

How are effective code reviews conducted?

What criteria are included in our definition of “done”?

Retrospectives

Which stakeholders should participate?

How does the information gathered at retrospectiveshelp the rest of the organization?

What categories do we use to brainstormimprovements?

The mind map in Figure 4 ties these ceremonies, andothers, to CMMI process areas, and the questions arederived from CMMI’s SPs.

For a more detailed example, let’s examine the retro-spective. In Scrum, the retrospective is intended as amethod for the team to learn lessons, in near real time,from the most recently executed sprint. Scrum itselfgives little guidance, but many teams discuss the suc-cess or failure of the sprint, how closely they met theirprojected velocity, how well they collaborated together,

Figure 4 — Scrum ceremonies and events can be improved through questions derived from CMMI.

27Get The Cutter Edge free: www.cutter.com Vol. 25, No. 11 CUTTER IT JOURNAL

feedback from the sprint demo, and other sprint-relatedexperiences. With a self-organized team, the retrospec-tive can be very effective in improving performance. Butthe rest of the organization learns little from this exer-cise, and changes based on the experience of the Scrumteam often do not translate into benefits for other teams.

CMMI provides guidelines for the conduct of retrospec-tives in GP 3.2: “Collect Process Related Experiences.”The guidelines exist in every process area and can beapplied to all Scrum ceremonies and activities beingperformed by Scrum teams.

By using CMMI to drive structured brainstorming,retrospectives become more powerful and provideincreased value to the rest of the teams in the organiza-tion. Using the mind map in Figure 4, or better yet, aScrum team’s own interpretation, a team can categorizeretrospectives into logical buckets and use questionsfrom the applicable PA to enrich their learning. Forexample:

Technical lessons — practices from TechnicalSolutions and Product Integration to drivediscussions

Sprint lessons — practices from Project Planning,Project Monitoring and Controlling, andRequirements Management

Testing lessons — practices from Validation andVerification

Scrum performance lessons — CMMI’s genericpractices

Teams may want to take care not to overload their ret-rospectives. They might consider rotating topics fromone sprint to the next, or from process area to processarea, and then share the information outside of the teamso that others can learn and benefit from the experience.Collaboration exists beyond the Scrum team, and it’sthe key to enterprise-wide performance improvement.

MASTERY AND SYNTHESIS OF TALENT, LEARNING, AND DISCIPLINE

For more than a quarter of a century, software organi-zations have launched one attempt after another toestablish a useful framework for effective continuousimprovement. Both CMMI and agile methods have had

a positive effect on the software industry, but neitherapproach has yet to succeed in driving the industry-wide levels of adoption we need in order to claimvictory. Why not combine the best of each?

The entire enterprise can leverage CMMI to make agilemethods like Scrum better and more powerful. Insteadof trying to achieve “a level of CMMI,” embrace CMMIto improve what is already being done within theScrum team, to scale Scrum to the enterprise, and toexpand the scope and influence of agile methods fromthe team room to the boardroom.

Seventy years ago, Bird proved that the integration ofagility with talent, learning, and discipline can breakdown the barriers to greatness, and in doing so hecreated a revolution in music that lives on to this day.We can do the same with agile.

ENDNOTES1Agile Manifesto (http://www.agilemanifesto.org).2Ask the CMMI Appraiser (http://asktheCMMIAppraiser.com)3Glazer, Hillel, Jeff Dalton, David Anderson, Michael Konrad,and Sandra Shrum. “CMMI or Agile: Why Not Embrace Both!”SEI/Carnegie Mellon University, November 2008.

ADDITIONAL READING

Sims, Chris, and Hillary Louise Johnson. The Elements of Scrum.Dymaxicon, 2011.

Chrissis, Mary Beth, Mike Konrad, and Sandy Shrum. CMMIfor Development: Guidelines for Process Integration and ProductImprovement. 3rd edition. Addison-Wesley Professional, 2011.

Agile CMMI (www.agileCMMI.com).

Jeff Dalton is President of Broadsword Solutions Corporation, aprocess innovation firm based in southeastern Michigan. Mr. Daltonis an SEI Certified SCAMPI Lead Appraiser, CMMI Instructor,ScrumMaster, and author of agileCMMI, Broadsword’s methodologyfor incremental and iterative process improvement designed to elimi-nate the process debt that demoralizes engineers and destroys anypotential productivity gains. He is Chairman of the SEI’s PartnerAdvisory Board and President of the Great Lakes Software ProcessImprovement Network. Mr. Dalton is author of the popular blog Askthe CMMI Appraiser and builds experimental aircraft in his sparetime. He can be reached at appraiser@broadswordsolutions.com.

them and get innovative ways tointerpret and apply CMMI so that itspractices actually make sense in agilesettings.

CMMI vs. Scrum? No — CMMI +Scrum! by Jeff Dalton. Disover asimple and robust architecture thatcan be used to build processesincrementally and iteratively.

Disciplined Agile Delivery MeetsCMMI by Scott W. Ambler. Learnhow Disciplined Agile Delivery (DAD)supports both agile and CMMI byproviding a decision framework fordetermining the best processes touse in your organization.

What Will It Take to AchieveAgility-at-Scale? by DouglasSchmidt, Anita Carleton, Erin Harper,Mary Ann Lapham, Ipek Ozkaya, andLinda Parker Gates. Learn how risk,measures, technical debt, andstrategy come into play whendealing with Agile/CMMI issues.

Order your copy of Agile CMMI:Why Isn’t This Conversation DeadYet? today and SAVE 50%! Just useCoupon Code AGILECMMI50 whenyou visit bookstore.cutter.com. You’llreceive your copy immediately in PDF.

To Order/For More Info:

Go to our secure bookstore at bookstore.cutter.com.

SUMMARY

It’s not agile or CMMI that fosters yourculture, and it’s not agile or CMMI thatshuns or requires documentation. Infact, as we’ll see in this issue of CutterIT Journal with Guest Editor HillelGlazer and his host of six expertauthors, it’s really not about agile orCMMI. And perhaps “To agile or not toagile?” is the wrong question to askand the wrong perspective on matters.

This issue addresses everything fromthe right questions to ask to how todeal in an agile manner with very largesystems. It seems a fairly universal con-clusion that it’s not agile or CMMI thatare incompatible but the way they’reapplied in a given situation that makesthem incompatible.

Table of Contents:

The Agile CMMI Conversation Is aDead End by Bill Fox. Get keyrecommendations on where torefocus your efforts to speed deliveryand improve quality.

Blending Agile and CMMI by BrianButton and Nate McKie. Explore howto apply the agile principle oflearning to the adoption of CMMI.

Agile CMMI: The Real UnderlyingObstacles to Effective Integrationand What You Can Do About Themby Paul E. McMahon. Understand“the real underlying obstacles” toagile CMMI and how to overcome

FOR MORE INFORMATION/TO ORDER:

Go to our secure bookstore atbookstore.cutter.com for moreinformation and/or to orderthis report. Your report will be delivered immediately in PDF.

You can also order by:Email: service@cutter.com;Tel: +1 781 648 8700

Published: November 2012, 40 pages, PDF format

CUTTER CONSORTIUM

Agile CMMI: Why Isn’t This Conversation Dead Yet?

CUTTER CONSORTIUM

Go to bookstore.cutter.com

Cutter IT Journal

The Journal of Information Technology Management

Get global perspectives and solutions to some of the most critical business technology issues facing organizations today!

Special Offer: Save $100 on a New Subscription!YES! Please start my new, one-year subscription to Cutter IT Journal for just $385 (US $485 outside North America) — I save $100 off the regular price of $485/US $585! Plus send all 2012 issues on CD-ROM!

Name Title

Company Dept.

Address/P.O. Box Mailstop/Suite

City State/Province

ZIP/Postal Code Country

Phone

Fax

Email

Order online at bookstore.cutter.com (enter Priority Code CITJSAVE100 to save $100). Or fax form to +1 781 648 8707, call +1 781 648 8700, or sendemail to service@cutter.com. Mail to Cutter Consortium, 37 Broadway, Suite 1, Arlington, MA 02474-5552, USA.

Your Front-Row Seat to ITManagement Debate at the Highest Level!Every day, your organization is confrontedwith the stark reality of having to achievemore aggressive goals with a shrinkingbudget, ever-changing requirements, andimpossible deadlines.

Few of you have the time to develop well-supported arguments on how to getyour organization to improve its IT opera-tions. It’s a tough trap: you know solutionsare out there, but you’re too busy to identifythem and convince your organization toimplement them.

Advice, Solutions, and ExperienceThat You Can Rely OnA Cutter IT Journal subscription helps youbreak out of the trap. Every month, CutterIT Journal features a select Guest Editorwho articulates the controversial issues,offers his or her opinion on them, invitesothers to introduce opposing viewpoints,and sparks a lively debate.

Cutter IT Journal provides you the opportu-nity to experience a variety of perspectives:viewpoints that will be instrumental inadvancing the cause of better softwaredevelopment. No matter where you standon these issues, the thoughtful discoursedelivered in Cutter IT Journal will certainlyhelp you clarify your position.

In addition to your monthly journal issue,you will also receive its companion Cutter IT Advisor. Each Advisor brings youpractical advice and thoughtful analysis fromwell-known and respected experts in the ITfield. Learn from the experiences of others,including what you should avoid and whatyou should consider implementing.

As a subscriber to Cutter IT Journal, you’llstay up to date on important IT issues suchas project management, security, risk man-agement, business intelligence, sourcing,enterprise architecture, requirements, trendsin technology, and more. Whatever thetopic, you can be sure you’ll receive frank,unbiased opinions, in the no-holds-barredmanner Cutter IT Journal is known for.

Don’t miss upcoming issues on:

Making Managerial Dashboards Useful

SMAC: Social, Mobile, Analytics, Cloud

The Emerging Cloud Ecosystem

Special offer for new subscribers!

Begin your subscription to Cutter IT Journaltoday and save $100 off the regular subscrip-tion rate!

Plus receive all 2012Cutter IT Journalissues on CD-ROM.

To subscribe for just $385 ($485 outside N.America) and receive your Free CD-ROM, goto bookstore.cutter.com and enter CouponCode CITJSAVE100 at checkout. Or completeand return the form below by fax +1 781648 8707, phone +1 781 648 8700, oremail service@cutter.com.

For more information on Cutter IT Journal,please visit www.cutter.com/itjournal.html.