Is the Measurement and Analysis Process Area Compatible with Agile?

Introduction

The measurement and Analysis process area, a process area at maturity 2, aims at developing a measurement capability that is used to support management information needs. Measurement objectives based on identified information needs are defined and using these objectives, objective and quantifiable measures are defined. Mechanisms to collect and store the data should also be defined.

Below are the specific goals and practices:

SG 1 Align Measurement and Analysis Activities

SP 1.1 Establish Measurement Objectives

SP 1.2 Specify Measures

SP 1.3 Specify Data Collection and Storage Procedures

SP 1.4 Specify Analysis Procedures

SG 2 Provide Measurement Results

SP 2.1 Collect Measurement Data

SP 2.2 Analyze Measurement Data

SP 2.3 Store Data and Results

SP 2.4 Communicate Results

Are they compatible?

Agile possess a culture of continuous improvement, through continual inspection and adaptation. The concept of Kaizen, that comes from the Lean world is also very popular. The question is ‘how is this improvement attained?’ and ‘is it always aligned with the wider company objectives?’.

How is this improvement attained? How should be the process to improve? The mechanism suggested by CMMI is the only one I know. The objective is identified, measurements that tell us if the objective has been reached as well as a plan to get there are defined and then successive measures are taken through the path. Having a company wide process improvement framework like CMMI can help identify these objectives in a project more easily and also assures that the objectives selected are aligned with the wider company objectives. It can also help define the measures, which should be “precise, quantifiable measures”.

However, I have a couple of concerns related with setting objectives and trying to reach these objectives:

1. Not weighting properly the importance of the objective within the whole context of the project

Let me picture this with an example, for which I will use Highsmith’s Agile triangle.

We may set up our objective as “Improve prior levels of quality” (taken from the CMMI examples). What is a quantifiable precise measure for this objective? Probably most will say counting the number of raised bugs. Having no bugs is really wonderful, but having no bugs on a software that doesn’t do what the customer needs is really valuable?

2. Creating dysfunctional behaviours

The human beings find ways to reach the objective that don’t match exactly what the objective was created for. Having raised less bugs assures us that the software is more robust? Are we really doing things better? The human/social aspects could be tricky.

Another thing to keep in mind when devising measurements and processes to be used inside a project is that all these processes and measures are “waste” (things that don’t add value to the product). Of course, this could all be good waste, because it will allow the company to improve, to do things better in the future. Nonetheless, they should be treated as such and designed to be as light as possible. Probably, automation (again) is the key in this regard.

Conclusion

I believe that creating more formal mechanisms to improve, that are aligned with company objectives, could be beneficial to Agile projects which in general focus their improvements efforts informally and with a project scope. The real objectives and the human aspects should be taken into consideration to avoid optimizing in the wrong side. The improvements processes should be light and agile.


Other Process Areas

- Is the Requirements Management Process Area compatible with Agile?
- Is the Project Monitoring and Control Process Area compatible with Agile?
- Is the Project Planning Process Area compatible with Agile?