CMMI, practically speaking
Process improvement conference keeps it real
To some extent, it's a marketing exercise, but the presence of representatives from the Software Engineering Institute (SEI ) at Carnegie Mellon and truly independent consultants such as Marilyn Bush and others, means it provides real information content.
However, Andrew Griffiths (MD of Lamri)gave a keynote presentation entitled "Buying the right to Change" in which he pointed out that the key skills for transforming an organisation (which is the essence of CMMI process improvement) are, in essence, sales and marketing skills – and he really does have a point there...
This conference is also an excellent opportunity for networking. Over the conference dinner, for example, I had the opportunity to talk about pressures for CMMI adoption with a "process person" from an aerospace firm that's revisiting CMMI because it's becoming a "filter" in procurement. In his field, only firms appraised at CMMI Maturity Level 3 may be in with a chance soon.
Of course, this situation raises the spectre of "check-box compliance" with the letter rather than the spirit of CMMI, but my dinner companion agreed that this sort of approach has all the overheads of CMMI adoption but delivers few of the strategic benefits (apart from, possibly, the tactical benefit of staying in business for the time being).
Jay Douglass from the SEI reported on what is new in CMMI 1.2 and then gave us an introduction to the latest CMMI models : CMMI for Acquisition and CMMI for Services (CMMI-ACQ and CMMI-SVC respectively). Douglass listed the three main drivers for v 1.2 as:
- Reducing the complexity of CMMI in use
- Increasing coverage
- Increasing confidence in appraisals
Points one and two are straightforward improvements based on practical experience with CMMI, but the third is probably more significant, to my mind (and addresses the "check box" issue which concerned my dinner companion). It used to be possible to "cheat" with CMMI for marketing purposes; to appraise one part of an organisation and claim a maturity level for the whole of it; to select lead appraisers with little real experience of maturity level four and five organisations; and to base maturity claims on wildly out of date appraisals.
Since the appraisal process is central to CMMI, the SEI has moved to address any such issues: appraisal disclosure has been tightened up, special training is mandated for high-maturity appraisers, and appraisals now have a "shelf life" (three years). The SEI has also instigated appraisal audits for some maturity level four and five appraisals (unusually rapid progress through the maturity levels, for example, might attract audit). CMMI v 1.2 finally replaces v 1.1 around August 2007.
CMMI-ACQ helps deal with the possible maturity mismatch between organisations building software and the organisations acquiring it from them; and CMMI-SVC deals with IT service delivery. Both initiatives are based on existing work in the CMMI community and CMMI-ACQ is just about complete and should be delivered shortly (June 2007).
CMMI-SVC will then be delivered (it's currently at "final comment" stage and scheduled for March 2008 delivery; but may well arrive sooner). Douglass wasn't really able to talk about CMMI-SVC in detail, but I remain to be convinced as to how well a project-based framework such as CMMI will support and complement ITIL, which is task-based, and which I see as the most practical approach to service delivery available today. If developers want to design systems for operational manageability, resilience, and service delivery (as they should), it's ITIL that provides a guide to the requirements.
Marilyn Bush represents the CMMI community in general rather than the SEI itself, although she's worked for the SEI. She is an extremely experienced CMMI practitioner and mentor (and one of that select band of IT people who've worked in the space industry and can be called a "rocket scientist" with some credibility).
She gave a presentation on the "Good, Bad and the Ugly" in the latest incarnation of CMMI. It's healthy that practitioners can constructively criticise the framework - and healthy that the CMMI community tolerates this. Despite the fears of some Agile practitioners, most CMMI process gurus certainly don't underestimate the people aspects of CMMI process improvement and this extends to encouraging debate about CMMI itself.
Her concerns with CMMI include:
- It sometimes oversells the "continuous representation" of CMMI, which allows you to pick and choose what high maturity processes you adopt – but only up to a point, as process areas are often dependent on each other.
- It hides the importance of active involvement by senior management – more than just "sponsorship" is needed.
- It implicitly assumes the importance of early defect removal without explicitly stating it.
- It over-emphasises testing as opposed to early defect removal; you should be putting a high-quality product into the testing process.
- The (misuse) of appraisal as an audit process, with consequent production of documents solely for appraisal.
Despite this, there are many good things about v 1.2, such as the improvements in the appraisal process in v 1.2 - better disclosure statements and the three year appraisal lifespan. Since CMMI is all about process improvement, the fact that CMMI itself is evolving and improving is a good sign, and Ms Bush's concerns are being addressed.
Another valuable presentation came from Gary Guttridge, looking at the integration of CMMI and ITIL (and he delivered some brownie points for this conference, as you're generally more likely to hear about CMMI at ITIL conferences than ITIL is at CMMI ones).
ITIL  is a set of best practices for operational service support, and is currently being updated (as Version three) with a services lifecycle framework. It is becoming ubiquitous as a framework for operational support worldwide (although it is perhaps more popular outside of the USA, perhaps) and it is more successful, in terms of uptake, than CMMI.
Guttridge pointed out, however, that there's precious little overlap between ITIL and CMMI, with both communities operating in their own silos. They are also different in approach, with ITIL being more compliance focused (ISO 20000 certification is available), whereas CMMI is about internal process improvement.
Nothing in ITIL should cause problems with CMMI appraisal; but, on the other hand, ITIL capabilities probably wouldn't be recognised explicitly (the same applies to ITIL ISO certification and CMMI appraisal, in reverse). In fact, when Jay Douglass was asked about ITIL support in CMMI-SVC, in another session, he admitted that the SEI was rather US-focused and probably didn't care about ITIL much.
This really should be a CMMI issue, as ITIL is an obvious approach to actually delivering real IT service support in a high maturity organisation – CMMI is at a higher level than ITIL and should help you to implement ITIL effectively (many ITIL "best practices" involve high-maturity processes).
Nevertheless, there are initiatives in CMMI that synthesise a common view from both CMMI and ITIL (Lamri is involved in one) but these are not really mainstream in the ITIL community; neither are they widely adopted. The consensus seems to be that ITIL and CMMI are complementary (most CMMI adopters will probably take up ITIL as well), although Guttridge was rather pessimistic about the possibility of formal cross-fertilisation - people feel comfortable in their silos and tools vendors are very happy about selling tools twice over, once to the developers and once again to Operations.
This is both a pity (because the business is interested in service, not product, delivery from IT these days) and an opportunity for an IT organisation to add value by synthesising both approaches for itself. As tool vendors go, Guttridge singled out MKS  for praise, as it supplies a rich configuration management toolset that can support both development and operations at the same time – and since today's mantras for developers include "deliver business services" and "design for operations manageability" this may well merit a look.
"Leo" from GCHQ presented one of the more useful case studies, because it examined the "dark side" of the CMMI adoption process as well as a success story. One of the key people issues you'll meet with CMMI seems to be top management support. Management "sponsorship" and enquiries as to "how's delivery coming?" are simply not enough; management should be saying something like "I understand the CMMI process - now, how can I help.
People implementing process improvement also need rewards - and if the head honcho at the end of a speech recognising progress in process improvement also sticks in a recognition of the long hours put in by the fire-fighters in the organisation, everybody takes away a wrong (but a very realistic) message about the real importance of process maturity. CMMI is about "getting it right first time" and discourages fire-fighting; but many managers got to where they are by being successful fire-fighters (where "success" didn't have any very defensible "lifecycle cost" metrics). This can be a problem.
I've only had room to touch on the presentations at this conference. All levels of familiarity with CMMI were catered for, and CMMI was placed in context against Six Sigma and Lean, as well as ITIL and IBM's RUP process. Case studies came from a range of experienced practitioners ranging from Mark Smith of Accenture  to Ramona Demure of AppLabs . The latter was particularly interesting as it covered the journey to Maturity Level 5 in an Indian software QA and testing organisation as an alternative to the usual general development shop.
The conference chair was Peter Mothersill, with over 20 years' experience in senior management in various technology sectors, including periods with ITT, Rockwell Corporation, BAe and Colt Internet. The conference was sponsored by the DSDM Consortium , Holagent Europe , IBM , Lamri , MKS , Pearson Education  and Telelogic .
All in all then, an extremely useful conference for anyone (whether contemplating formal CMMI or not) interested in software development process improvement – and, these days, what developer isn't?