CMMI and the NewAgile
By Ted Smillie on Tuesday, September 29th, 2015
Features in QESP Newsletter
Volume 27 , Issue 9 - ISSN 1325-2070
An Editorial I wrote about CMMI in the Feb 2004 Newsletter (Yes, way back then) has been receiving some hits recently via Research Gate, no doubt in part due to events like the CMMI® Institute Conference EMEA 2015 and Global Congress 2015. The Feb 2004 Editorial criticized the Victorian Government’s initiative to help small-to-medium software developers “lift their game” by providing $1 million over the next 3.5 years for obtaining CMMI Level 2. While applauding the good intentions (and of course the funding), I thought it was a big mistake to push CMMI certification as a good approach, let alone the only approach, for small- to-medium developers. The Feb 2004 Newsletter was in favour of CMMI but gave some statistics showing that there were better and far cheaper options for small-to-medium business. It also noted that “another argument against pushing CMMI is the recent software industry backlash against old-style methodologies? Can we ignore the Agile Alliance (eXtreme Programming, et al)?”
So what has changed since 2004? Maybe not as much as you might think. Back then, the “waterfall” approach was typically iterative and could include delivering production software as part of an iteration. More importantly, the SEI’s Team Software Process (TSP), introduced by Watts Humphrey in November 2000, was a forerunner of the distributed Agile approach and self-directed teams which global organisations are embracing today. The article Is Agile Taking Over? in our August Issue noted that IBM’s new CIO had introduced this approach in February2015.
However, what is now making a significant difference is the CMMI® Institute’s push to raise awareness of the benefits of CMMI/Agile integration and to dispel some of the myths. The CMMI® Institute Conference EMEA 2015 is a good example and a couple of the presentations are in the public domain. The Agile Risk Management presentation suggests that “A great deal of explicit risk management becomes unnecessary when a project uses an agile approach.”
The presentation explains how the agile approach mitigates traditional risks during Implementation via Agile Risk Management, Risk Recognition and Agile Risk Management In Practice, which uses a- Light Approach to Identify, Classify, Quantify, Rate and Measure Risk.
Quantitative Results are provided for Productivity, Time to Market and Quality
Lessons Learned include:
“Risk management become a series of conversations not a series of documents.
Risk management using CMMI and Agile becomes leaner and a truly continuous process
Each build is assessed, issues identified and the backlog of tasks is reviewed and
prioritized and the most important tasks, issues and risk mitigation are scheduled for the next sprint.”
Another presentation which is publicly available from the CMMI® Institute Conference EMEA 2015 is Agile – Distributed At Scale, presented by SITA, which supports almost every international airline and airport. SITA achieved CMMI L3 in December 2014. The presentation gives an overview SITA’s Delivery Challenge, Distribution Challenge and Agile Challenge and of how Agile Throughput and Agile At Scale are used within the Process Architecture and CMMI® Framework. The Delivery Challenge covers Very Large Programme Recovery and Multiple Large Programmes in parallel.
The Agile At Scale Productivity for Programme Recovery is impressive:
- Vital productivity gains: 3.5 fold increase
- Cost reductions: 55%
- Quality improvements: 60% less defects
- Deployment: Down from 3 months to 3 hours
One of the questions which arose from the Agile Risk Management presentation was about risk management when contracting for Agile. A subsequent CMU/SEI Technical Note (TN) prepared for the US Department of Defense gives comprehensive (75pp) advice for DoD contracting officers, that could be useful to purchasing officers anywhere. The August 2015 TN Contracting for Agile Software Development in the Department of Defense: An Introduction , by Eileen Wrubel and Jon Gros, Software Solutions Division, notes “Throughout our data gathering for this paper,… we heard a frequent refrain: program office teams do not feel that they “speak the same language” as contracting officers with whom they must collaborate.”
The TN gives advice to contracting professionals on the modifications needed to traditional mile-stones, documentation, delivery, and progress monitoring activities. It aims to provide “a foundation for contracting officers to “hit the ground running” when they collaborate with programs seeking to employ or explore Agile methods.”
Tags: Agile