Friday, November 28, 2008

We can't seem to get a clear description of what "Agile" is. Can you help?

We see a lot of discussion on Agile development and sometimes fanatics get involved and add a lot of fog to the conversations. Other than a vague (and contradictory) 'Agile manifesto', is there a definition that can be used to base opinions on or will this 'tag' remain a myth to most of us. I, for one, believe that 'Agile' is a qualitative word that should not be used to represent a methodology.

There isn't enough space to write an entire treatise on this, but here is the nitty-gritty.

"Agile" is a generic term that refers to a loose set of methodologies that include Scrum, XP, Feature Driven Development, and other iterative AND incremental methods. You are correct in that it is not a methodology in itself.

You often hear very loose descriptors like "trust," "iterative," "low documentation" etc used to describe "Agile" but these are pretty nebulous. To be more precise:

1) Agile methods are iterative, where the complete lifecycle (plan, reqt's, design, test, build) happens in short durations, often 30 days or less. These activities are usually not linear, but empirical, and do not always occur in a specific sequence

2) Agile methods are incremental, where a small set of features is developed, followed by refinement or another set of features. The methods don't espouse the "big bang" but more like small bits at a time

3) Agile methods negotiate scope, not time and budget. A "waterfall project" usually has a fixed scope, and a fixed budget. If a major change is requested, the timeline and budget is negotiated. Agile methods EXPECT change, but negotiate each release (or iteration) to contain a certain amount of "features" (or functionality). If they don't get it all done, they execute another release.

4) Agile methods MUST have buy-in from the end-user or customer, because this type of negotiation is not IT or engineering driven, it's driven by the business, so it's not for everybody.

The different Agile methods have other specifics (XP uses Pair Programming as a form of real-time validation, Scrum has "stand-up meetings and "sprints" for instance) but these are ornamental - not core to the concept of "Agile."

For more information (and for a discussion of CMMI and Agile methods) you can download an SEI Technical Note (CMMI and Agile: Why not Embrace Both!") which I co-authored with several other very talented individuals.

Good luck!

Friday, November 21, 2008

How can we be Agile and still satisfy estimation requirements for ML5?

I work in an ML5 organization. We're experimenting with scrum to see what benefits can be gained over our traditional waterfall model. But I'm stuck on the estimating part! When I've done scrum in the past we've done some planning poker and called it a day. But the head of my SEPG tells me that wideband delphi estimation is frowned upon at the high maturity levels because it is akin to guessing. Can you recommend how we can perform agile estimation in a way that's compatible with HM organizations?

So what's wrong with guessing?

I'm not sure your problem is as much about "Scrum" as it is about the inflexibility and lack of experience within your SEPG! The CMMI does not speak to specific estimating methods and while "planning poker and calling it a day" may not be enough to satisfy the CMMI, there isn't a requirement to perform more "traditional" methods such as SLOC, KOKOMO, or the like either.

There have been whole books written on high maturity and estimating, so now is not the right time to get into all of the glorious and fun-filled detail but I'll touch on some of the concepts.

As to Wideband Delphi being "akin to guessing" I guess I would say "it depends" (I'm not saying it's a "high-maturity practice" either). To say that is akin to saying that a design that has been put together by an expert software architect, and then peer reviewed by other experts, and then prototyped is akin to guessing on a design. It isn't. We call all of those things TS, VER, and VAL don't we?

But, on to the meat of it.....

The difference between a ML2/3 organization and a ML5 organization isn't in how they do things, but it is in the data used to make the decision on how to do things. The essence of ML5 is trying new and innovative techniques to improve performance based on data gathered through the execution of the process (like Scrum for instance).

Someone in your organization should be gathering appropriate data, developing baselines (determining the natural bounds of process performance), and performance models using various statistical methods. That data should be used to estimate and plan projects as well as select potential innovations (such as the use of Scrum) for piloting and eventual deployment.

So, if I were to use historical performance baselines as input into a wide-band delphi process that was intended to "feed" a scrum project, and I was doing so because I had identified Scrum as an innovation that could improve performance (supported by data that told me that phase and cost overruns were a problem we a problem) then I would be behaving exactly like a High Maturity organization was supposed to perform.

Of course, that's a hypothetical situation. You'd have to determine your own thread for getting value from Scrum and ML5, but if you read our latest SEI Technical note "CMMI and Agile: Why not Embrace Both" you'll learn a lot more about it. Get it at:

Wednesday, November 12, 2008

The CMMI-Agile Technical Report has been released!

Agile or CMMI: Why not Embrace Both! has been released by the Software Engineering Institute.

A new SEI technical note has been published. Please visit the following page to download the PDF version of the report.



CMMI® or Agile: Why Not Embrace Both!

Hillel Glazer (Entinex, Inc.)
Jeff Dalton (Broadsword Solutions Corporation)
David Anderson (David J. Anderson & Associates, Inc.)
Mike Konrad
Sandy Shrum




Agile development methods and CMMI (Capability Maturity Model® Integration) best practices 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 synergies that have the potential to dramatically improve business performance.


keywords: Agile, Agile methods, CMMI


cover: November 2008

publication date: November 2008

distribution: unlimited

editor: Sandy Shrum (