CMM Vs. Agile - WOAD talk

Like my notes from the Websphere and Struts talk, this is going to be a stream of consciousness sort of thing...

Steve Ornburn of GBC, David Kane of SRA speaking.

The Problem - CMM is being mandated by a lot of the government - especially defense - organizations. At the same time, there's a lot of interest in XP/Agile, especially at the grass roots level. The theory - the two are in conflict. Are they?

The answer - there are real differences, both in the approaches and in the philosophies. There are ways to meld, but they are high risk.

Right off, I notice an interesting bias - CMM is called "High Maturity", as opposed to Agile. Interesting.

Issues

• Is AD a mature process?
• Can AD fit into a high maturity shop?
• Is it worth it?

There's a map of the meta-model of software life-cycle. Highly oriented towards CMM, which makes mapping Agile to it problematic, IMHO. Now we have some definitions - Spiral development is defined as a Risk driven development model. Others are Waterfall, Iterative, Evolutionary. Requirements driven, Architecture driven. The point being made - different projects require different models based on the risks.

Agile maintains a balance between a requirements driven and an architecture driven approach. So the question here is, for what risk profile is Agile appropriate?

Safety Critical - Managed change and requirements, so the environment is stable. Their example - the Space Shuttle. Bad, bad example IMHO. I think the shuttle was more of a budget driven project with overblown process layredon, so the whole thing went badly. In any case, I'm not sure I'd use it as an example of a place that is appropriate for CMM.

Not safety critical, but unpredictable change - appropriate for Agile. Again, IMHO, this sets up a straw man that Agile is unsafe. I don't think that's fair, and I think that the overall failure rate in the software business - including in the safety critical side - is not encouraging.

This actually engendered a huge conversation - I think a lot of people here are incomfortable with the straw man being presented. For instance, one of the speakers from the last time I came here brought up the fabled 350,000 lines of code from the original Space Shuttle project - 5 years, virtually no defects. Well. Note how slowly the space program has moved - compared, say, to the early aerospace efforts - which were very much agile efforts.

In contrasting with Agile, this talk is going to focus on XP and the Agile Manifesto.

The CMMI -

• Meets the needs of software organizations
• Is as upgrade to the sW-CMM
• Benefits from best practices contributed from all three source models (the older ones0

CMMI is best described here. Ranges from Level 1 (Chaos) to Level 5 (Optimizing, Continuous Improvement). So, the question - can XP/Agile methods be mapped to CMM continuous improvement standards? IMHO, a lot of this was covered by Scott Ambler in his XP Brazil talk - it's all about what you pack vs. what you actually need (overhead).

Requirements and Software planning map pretty well from Agile to CMM. For instance, stories capture requirements, customer interaction deals with ongoing planning. etc. What they say Agile misses is doing organizational change - because, in their opinion, Agile (especially XP) is more focused at the raw development level - not at the corporate level.

CMM really wants a definable process, so that said process can be evaluated. Given things like emergent requirements (etc), can a CMM definable process be defined from XP? CMM had notions that process is akin to manufacturing - it can be defined and refined, somewhat like an assembly line. This isn't how Agile looks at this. CMM has moved somewhat away from this view. So based on all this, the claim is that one can map the XP processes to CMM level 3 pretty easily.

"Fixing" XP - Agile omits process ordering; this can be addressed. Comment from the crowd - CMM is largely mandated from above, in order to get the "good housekeeping seal of approval". The engineers often don't buy into this, and it all becomes worthless. The way to make this mapping work is not to get overly detailed. CMM is partly about artifacts (reproducability), while Agile isn't. Another example - XP teams use whiteboards and other ephemeral documents - CMMI wants documentation and artifacts. This will have to be addressed carefully in order to make a CMM assessor happy.

Lots of things are not dealt with at all by Agile - subcontract management, Technology Change Management, Process Change Management, etc. IMHO, that's because these are not practices day to day developers need to worry about. Ultimately, CMMI is aiming at a broader scope than XP/Agile. IMHO, CMMI is aimed up at the CIO level, not at the project/project manager level.

A Level 5 Shop Improvements are selected based on quantitative measurements. How do you get that? It could easily be via Agile methods. What if the shop is less than level five? Be prepared for resistance and turf battles (for instance, architects and QA folks, for whom there is no defined role in XP). If that's not resolved, you get politics - which destroys projects quickly.

Next question - is the attempt worth it? Is Agile succeeding through a self selecting, superior developer crowd? Is it just that better programmers succeed, almost without regard to the practices?

Agile - focused on small to medium sized projects, assume a high level of customer trust CMMI - Frequently applied to large, complex projects, often require detailed conceptuial models before cutting code, often used as part of a formal acquisition process

Ultimately, I think one of the big issues with trying to relate software to real engineering is best practices - construction (for instance) has a suite of best practices. In software, we don't really have an agreed upon set of best practices. We are still arguing over what they are.