Kanban/Agile Coach @ AgileSparks
Disclaimer – I’m not a CMMI expert. Far from it. My experience with CMMI sums up to working with a few organizations that already have a CMMI certificate and are looking at Lean/Agile as a way to improve, some organizations who improved their performance using Lean/Agile and are also looking at a CMMI certification of their maturity, and a reasonable amount of reading and following people like Hillel Glazer, Richard Hensley, David Anderson who have more experience in the matter. Call me a Kanban Practitioner reaching out…
In several recent engagements with enterprise-level organizations the topic of CMMI has come up. It typically comes up as an early question that goes something like “But what will our CMMI Appraiser think about this?” this being – The emphasis on learning through working software, actual feedback, adjusting plans, rather than comprehensive phase gates and specification documents. When I describe the fact that the process itself will shift some of the people having post-traumatic stress from preparing to their CMMI audits really lose it… From a naïve perspective this should come as a surprise. After all, CMMI talks about Continuous Improvement as the ideal maturity level (Maturity Level 5). Doesn’t that mean you will actually have to change your process as part of that improvement? Isn’t it clear that improvement means improving the system of work and if your maturity model says you are documenting the way you work, then it means changing that documentation?
I think the conflict arises from the fact that on one end many CMMI Appraisers come from an experience of waterfall/phase-gate environments and their approach to CMMI calcified around comprehensive planning, documentation and handoffs as a way to show maturity. On the other end many agilists carry the revolutionary flag waving Manifestos and lack of any planning/documentation using reasons/excuses such as empiric processes, emergence, uncertainty. The poor practitioners in the field think they have to choose a side. And this obviously creates fear of exploring the “other side”. Which is a shame. Yes CMMI seems to be quite complex. Yes there is a definite overhead. But it does seem like it brings some formality and discipline that many organizations can benefit from to take their maturity to new levels. Yes lean/agile preaches different trade-offs trying to reduce your batch sizes and emphasizes moving ahead with imperfect information and exploring the requirements uncertainty as well as execution uncertainty. Yes you will have to revise your processes. Yes you might have to revise your processes quite frequently. But for most product development/IT shops today it is becoming more and more a necessity not a choice. Therefore I believe we should try to work together.
There’s been an ongoing thread of activity on the subject of bridging the perceived gap between CMMI and Lean/Agile. See some materials for further reading down below. I’m seeing more and more openness for going agile in a CMMI environment. On the other hand CMMI is still perceived as very heavy and formal and a certification-oriented method rather than a potential maturity improvement approach by organizations not forced into it by their clients/ecosystem. Are we throwing the baby out with the bath water? Isn’t there something useful about CMMI that these Product Development companies are missing because they are afraid of the overhead? Is the CMMI vision/intent of being an approach for guiding process improvement underserved by its current perception as a certification scheme for project companies based on evidence of comprehensively documented and audited work processes? I think this might be the case.
One of the steps I took to bridge the perceived gap was to try mapping Kanban – my favorite method of guiding your lean/agile journey – into the CMMI model. The Kanban Method as described by David Anderson includes 6 key practices:
- Limit WIP
- Manage Flow
- Make Process Policies Explicit
- Implement Feedback Loops
- Improve Collaboratively, Evolve Experimentally (using models/scientific method)
I recently looked at a few diagrams outlining the CMMI model (actually starting with a keynote David gave at Agile Israel back in 2010 – see Video and PDF). Take for example this one:
(By Sally Godfrey (What is CMMI ?) [Public domain], via Wikimedia Commons
I started to think that there might be an interesting mapping between the core Kanban practices and the CMMI Maturity levels. This ties into discussions about the order of the practices back in the 2012 Kanban Leadership Retreat in Austria.
(Picture of reordered practices courtesy Hakan Forss from his great blog about the subject)
A twit of my early thoughts/sketches seems to have resonated with quite a few folks in our community. There were some questions as well as reinforcements to the thinking.
Basically, I see the Kanban Practices as helping you take the CMMI maturity steps. In addition you follow the Kanban foundational principles of “Starting with what you do now” and “Agreeing to pursue incremental, evolutionary change” as another way to look at this maturity journey. You also need to “Encourage acts of leadership at all levels” these acts of leadership being setting the direction towards higher maturity and leading there by example, expecting it from your teams and people, including it in your day to day management routine. Note that while this diagram calls for an order between the Kanban practices (similar to the one Hakan documents above), you can of course start doing a practice in lower levels of maturity, but it would typically mean you are doing some optimization before achieving qualitative management or fully defining your process. I think that is fine. Do what works. My fellow sparkies (AgileSparks Coaches) are wondering whether the majority of organizations will proceed linearly or will need a more complex mapping similar to the “Kanban Depth Kivieats”. This is certainly a big question. Trying to map several of the organizations I’m familiar with shows promising results (most of them at Level3 btw – which shouldn’t be a big surprise…) but the jury is still out. I’m really hoping a simple linear mapping can provide guidance for many situations as I think while not as comprehensive it is more directional which is a benefit. A related point is that of course these maturity levels don’t indicate the agility level of your processes and interactions (e.g. high-trust culture). The maturity level SHOULD indicate the pace at which you are improving your agility/leanness. Low maturity will indicate there is a good chance your capabilities are standing still or even deteriorating. High maturity SHOULD indicate focus and improvement (If not, then we are measuring inputs/outputs and not outcomes, which will be a shame).
How will you use this? As both Hillel Glazer and Richard Hensley (respected thought leaders and practitioners in both the Lean Systems and CMMI space) recommend – After you use Kanban to make a maturity improvement step, you can then use CMMI to appraise/certify your current level. Then take another maturity step, and re-appraise or certify. As David Anderson comments in his Agile Israel 2010 keynote mentioned above there are some process areas in CMMI that Kanban doesn’t explicitly guide you towards so you might need to go an extra mile to actually match a certain maturity level you are seeking. But Kanban done right with leadership and discipline will certainly take you a long way quite quickly.
The mapping can be only a starting point though. I see a deeper opportunity here. As I mentioned above, Product Development companies refrain from taking on CMMI if they don’t really have to (and most of them don’t). But what if there was a light-weight CMMI-inspired model that provides some extra guidance beyond the Kanban Depth model, something that organizations will be able to grasp without requiring expert help, that they will feel brings them real value (not just a stamp of approval), can help them in the pursuit of incremental evolutionary change towards higher maturity, can make acts of leadership more concrete for the leaders? I think some of the more serious product development companies would love to embrace such an approach. Now that might be an interesting mashup/love story that can help us in this quest for improving the world of work through its systems…
Shortcut to CMMI – Lean First, by Hillel Glazer – www.agileCMMI.com/index.php/2012/03/short-cut-to-CMMI-lean-first
CMMI or Agile? Why not embrace both – by Hillel Glazer, Jeff Dalton, David J Anderson, Mike Konrad, Sandy Shrum – http://www.sei.cmu.edu/reports/08tn003.pdf
Viewing a Lean System through a CMMI lense – Richard Hensley at Lean Systems and Software Conference 2010 – http://www.leanssc.org/videos/lssc11/Hensley/Hensley.html
Agile CMMI: Why Isn’t This Conversation Dead Yet? (Cutter Journal issue available for purchase) http://www.cutter.com/itjournal/fulltext/2012/11/index.html