I’ve been to Creative Chaos a number of times recently.
In the recent set of posts (same link as above), Matthew Heusser has some thoughtful insights about AgileCMMI.
Although it seems like his actual hands-on experience with CMMI comes from a particular flavor of ultra-heavy CMMI implementation, I think he does a pretty fair (as in balanced) job of representing CMMI and some of the challenges when implementing it in an otherwise agile development environment.
I could also appreciate him pointing out several blanks in the agile approaches as well and his recognition of some disconcerting trends in the software industry.
But none of this rises to the top of reasons of why I decided to cross-post his blog. What compelled me most to cross-post is a statement he makes in a number of places about CMMI’s inherent “value system involving comprehensive documentation”.
I think Matthew deserves a lot of credit for making — even given this way of understanding CMMI — a number of very astute leaps in logic to move past this inherent “value system” and towards ways of implementing process improvement with CMMI that can co-exist with agile development.
What I would like to add to the discussion are these observations from the “other side” of the CMMI table that may, I hope, make it even easier for others to make the same leaps in logic:
It’s not “documentation” that CMMI expects, it’s *evidence* of a process that shows up in “work products” of the process. CMMI does not dictate or expect documentation, evidence types or work products. The projects (or their organization) can determine those for themselves — and should! The common problem in far too many CMMI implementations is the interpretation of the model in ways that make the lives of the appraisal team easy and the lives of the developers painful. That’s where most of your ‘heavyweight’ documentation-centric stories come from. I sympathize with any organization who has or is taking that route. It’s completely unnecessary and in many cases the wrong path to be on.
The current version (v1.2) of CMMI is 150 pages shorter than the one Matthew mentions (v1.1). That’s a 21% reduction in page count. The formatting is the same and the vast majority of the model is intact, yet the SEI was able to simultaneously support the current version of its flagship product while also improving it by 21% (using just page-count as a metric) in about 5 years. Some who know might say that dropping 3 process areas makes it easy to drop page-count. But those who understand would point out that the process areas were dropped, but the goals and practices from those process areas were transferred to other process areas, not eliminated. What page-count doesn’t convey is the improvements in communicating the material or in clarifying the implementation of the model. Unfortunately this is purely subjective and can only be demonstrated through usage and “proven” (for lack of a better term) through surveys. But why does this point about v1.2 matter? Because it demonstrates that the SEI and CMMI are not immutable or infallible, and, to re-enforce the idea that if something as abstract as a model for process improvement can be made better, what are the implications for interpreting the [CMMI] model and also interpreting the “model” for Agile so that they grow towards each other? Perhaps, if the ‘manifesto’ were also viewed as a model it could help things move along.
I’d like to toss something out there… while there are way too many folks misreading CMMI that ends up with document-centric, heavy-handed implementations, I suspect there’s a comparable number of Agile proponents mis-reading the manifesto resulting in the “things on the right” being forbidden, let alone valued less than the “things on the left”.
