Are Level 4 CMMI Process Areas compatible with Agile?

Introduction

I merged the process areas in level 4, because they are really inter twinned and probably don’t make sense to do one and not the other. The first one, the Organizational Process Performance aims at “establish and maintain a quantitative understanding of the performance of the organization’s set of standard processes”. Based on these baselines, the Quantitative Project Management process area sets the objectives and “quantitatively manage the project’s defined process to achieve the project’s established quality and process-performance objectives.

The Organizational Process Performance goals and practices are listed below:

SG 1 Establish Performance Baselines and Models

SP 1.1 Select Processes

SP 1.2 Establish Process-Performance Measures

SP 1.3 Establish Process-Performance Baselines

SP 1.5 Establish Quality and Process-Performance Objectives

SP 1.4 Establish Process-Performance Models

The Quantitative Project Management goals and practices are listed below:

SG 1 Quantitatively Manage the Project

SP 1.1Establish the Project’s Objectives

SP 1.2 Compose the Defined Process

SP 1.3 Select the Subprocesses that Will Be Statistically Managed

SP 1.4 Manage Project Performance

SG 2 Statistically Manage Subprocess Performance

SP 2.1 Select Measures and Analytic Techniques

SP 2.2 Apply Statistical Methods to Understand Variation

SP 2.3 Monitor Performance of the Selected Subprocesses

SP 2.4 Record Statistical Management Data

Metrics? What metrics?

In CMMI Level 4, the organization reaches a level where the existing processes can be quantitatively measured. Objective objectives can be set based on these measures. Being able to measure is vital to being able to manage and optimize. Jurgen published a post recently that states “You cannot manage what you don’t measure”.

A very important point to keep in mind when selecting what to measure is that these metrics need to be compatible with the Agile values and practices. Wrongly selected metrics may create dysfunctional behaviours, detrimental to the organization’s objectives. Dave Nicolette has a very nice presentation regarding Agile metrics. Some of the metrics he discusses are “Running Tested Features”, “Hard Financial Value” and “Earned Business Value”. I wonder, with these metrics, how to handle at the organizational level the context differences among the projects. I mean, each project is different, runs under different circumstances, will deliver business value in a different way, etc. All these factors need to be considered to draw conclusions from the metrics.

These metrics need to provide the picture needed by upper management to take decisions and manage risk appropriately. Being able to visualize the processes used, detect and resolve problems is of utmost importance in mature organizations.

Can everything be measured?

There’s a nice quote by Albert Einstein in Dave’s presentation that says “Not everything that counts can be counted, and not everything that can be counted counts.”. Is there place for subjectivity in a mature organization? How and where would it work? Agile methods stimulate optimization since the very beginning and this is performed, in most cases, subjectively. Teams introspect on the previous iteration, try to determine how they feel and propose ideas that would optimize the process. At upper levels, it would be impossible to optimize this way. Managers need to see the broad view and the only way seems to be through measures.

Keep it light!

I must confess that after reading both process areas in level 4, I ended up a bit scared. It really sounds difficult and requirements seem pretty heavy. Agile processes are characterized by their minimum overhead. The machinery required to measure and optimize processes shouldn’t increase this overhead significantly. For this, measures should be taken in the most automatic way, only what is needed should be measured and when it’s not needed anymore it should be dropped. There should be constant improvement in the improvement processes.

Conclusion

Being able to measure, to understanding where it is standing allows an organization to set improvement objectives. These measures need to be align with the Agile philosophy. The improvement machinery should be kept light.