Men pushing puzzle pieces

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:

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.