Blog

CMMI version 1.3 has been released! Some first reflections

Mike Philips wrote a release note with the new model. Here, he indicates that the major changes are in the high maturity section (levels 4 and 5) and in the architecture of both representations, staged and continuous. I won't dig into the high maturity changes here.

The changes in representations are major. But, ordinary CMMI users working with maturity levels 2 and 3 will not notice the differences. But in the total architecture of the model it is a major change to eliminate generic goals 4 and 5. In practice this means that you can only use the continuous representation for levels 2 and 3. If you aspire high maturity you will have to use the staged representation.

The structure of the model document has not changed. Good news, that makes the transition easier.

The paragraph listing the changes with version 1.2 indicates more support for Agile practices. That really sounds interesting! Besides that it is good to see that quite many examples are given about combining CMMI with Product Lines. For years the two departments for CMMI and Product Lines were completely separated at the SEI. Apparently there is some synergy finally.

The introductory chapters have not changed much. It is striking however that the paragraph that states that the inspiration for CMMI comes from process improvement in manufacturing has not been removed. My experience with and study of Agile has taught me that this is not the right basis. Manufacturing is fundamentally different from development. In manufacturing there is a justified interest in standardisation and repeatability. In development it is however variation that is important. Development needs to adapt to ever changing customer demands, to evolving technical insights. Too much standardisation distracts from being open for these inputs. So, despite all attention for Agile in version 1.3, there is still a fundamental difference in philisophy.

There is separate section on "Interpreting CMMI When Using Agile Approaches". It is interesting to notice that this section refers to the Agile manifesto, but then Agile is described as:

Such approaches are characterized by the following:

Direct involvement of the customer in product development

Use of multiple development iterations to learn about and evolve the product

Customer willingness to share in the responsibility for decisions and risk

It leaves me wondering why the manifesto itself is not quoted. Would it be that the manifesto's first statement that Individuals and Interactions have more value than Processes and Tools hurt too much? Or the second statement about working software being more important than comprehensive documentation?

Part 2 contains two major changes: the generic goals at levels 4 and 5 have been removed. And there is a textual change. All information about generic practices has been written only here and has not been repeated with the process areas. That has been the major trick to reduce the size of the model. Unfortunately that does not really reduce the conceptual size of the model, just the size of the document.

Now for the 'real model', part 3, the description of the process areas (PAs). I will discuss just a few PAs.

Configuration management (CM) has not changed much. But it include several better examples of items that can be put under CM in a hardware environment (drawings, product data files) and in an Agile environment (user stories and iteration backlogs). In the 'Agile interpretation box' there is the justified signal that CM is even more important in an Agile context. There is some smell of different values between Agile and CMMI. Agile puts a lot of value on team performance, self-organisation, and tries to reduce the number of specialist roles. CMMI suggest here to make one team member responsible for CM.

Within Measurements and Analysis (MA) there is a very good table indicating the intention behind information needs, measurement objective and measurement definition. In the past, many people made spastic attempts to link measurements to business goals and ended up in stupid generalisations. The table indicates very clearly that the objectives are the intent of the measurement. For example, milestone performance is being measured to gain objective insight into project progress. It is not neccessary to link this to shareholder value.

To my surprise there is no Agile hint with Project Monitoring and Control (PMC). No explicit attention for burndown charts and daily standup meetings. But Project Planning contains several useful hints.

Requirements management contains a very useful Agile hint. Traceabiity within Agile projects is achieved by demonstrating in the Sprint Review that the User Stories that have been agreed at the start of the Sprint have been implemented. That means that no complicated and hardly maintainable traceability matrices do not need to be created. Great!

I have some mixed feelings about the Agile hint with Risk Management (RSKM). On the one hand, CMMI recognises that within Agile projects a lot of risk management is embedded deep within the Agile methodes. Principles like 'fail fast' and 'spikes' to reduce uncertainty early are mentioned. But on the other hand, the SEI still expects us to apply their risk management method, because that is a systematic approach. That really strikes me! So, an Agile approach that embeds risk management systemically is not systematic, and an approach that maintains risk lists in parallel to 'the real work' is systematic?

A similar remark can be made about the Agile hint at Verification (VER). It is admitted that Agile achieves a lot of validation by having intensive customer interaction and by using short iterations. But a full appreciation is not given. The separation between VERification and VALidation in this CMMI will still lead to a more systematic approach. I don't believe this.

The Glossary contains several useful improvements. The bizarre, CMMI-centric definition of 'process', as "activities that can be recognised as implementations of CMMI practices" has been removed.

Also the definition of 'project' is back to normal: "a set of activities [...] with a clear beginning and end". The end of a project has been removed in version 1.2, so services could also fit under the definition of a project. But in a model that is so project-centric you cannot amputate the definition of a project. Fortunately that mistake has been repaired.

In summary I conclude that version 1.3 is a somewhat better model than version 1.2. Especially within the scope of maturity levels 2 and 3 as discussed in this post.

I am really curious to see the changes in SCAMPI. In practice, appraisers play a crucial role in the interpretation of the model. Some SCAMPI rules made the model more rigid than was necessary, I hope this will be improved.

André Heijstek is certified Lead Appraiser and Trainer for CMMI and is also Certified Scrum Master.

« back to the overview page

Search

Laatste nieuws

Volgorde van de backlog

De product backlog hoort geordend te zijn. Dingen die als eerste opgepakt moeten worden staan bovenaan, wat later mag komen staat onder.

In het algemeen wordt als advies gegeven dat de items op volgorde van waarde...

» lees meer

Events

07-06-2012 t/m 08-06-2012

Basis training Agile en Scrum

Improvement Focus biedt een tweedaagse cursus Agile/Scrum. U krijgt deze dag een overzicht van het Agile denken (Agile Manifesto), en door diverse praktische oefeningen en spellen de eerste ervaringen met de...