Would the process capability levels fit an Agile Environment?

In CMMI, the scale to measure a process capability is divided into 5 levels: performed, managed, defined, quantitatively managed and optimizing. Do these levels make sense inside the Agile world? Would this be the improvement path that an Agile organization should follow to improve its processes? Is the scale compatible?

Let’s look at the 5 levels:

Performed Process

“A performed process accomplishes the work necessary to produce work products”. The first level falls outside any approach, so it’s pointless to analyze it.

Managed Process

A managed process “is planned and executed according to policy; employs skilled people who have adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description.”. The key difference with respect to a performed process is that the managed process is planned and then measured, having the possibility of taking corrective action “when the actual results and performance deviate significantly from the plan.”

What would it be a managed process inside an Agile environment? Well, basically I believe there are no managed processes, at least not in the way suggested here which distills a command and control project management mentality where management means “monitor, control and take corrective action”. This type of management is in the heart of CMMI (Prof. Judson Neff says “the only way to manage complex operations is to manage, to detailed and precise plans”). Agile, on the other side, relies on another type of management. One that sets the limits and get the resources, but that allows the team to self-organize to accomplish the work. It relies on a management that uses leadership to manage. Well, probably it’s just my view because nowhere does it says that a project manager is the one that monitors, controls and take corrective action (does it?). It is important nonetheless to stress that the process should be managed by the team, which should be the one that plans, monitors and take corrective action if necessary.

Defined Process

“A defined process is a managed process that is tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines; has a maintained process description; and contributes work products, measures, and other process improvement information to the organizational process assets”. This level is where standarization/institutionalization comes in. Projects learned from the organization standards, and the organization learns from the projects as knowledge goes both ways.

I believe that besides having defined processes, an organization would benefit from having a defined set of values. For example, I think that an organization may have a process to gather requirements from customers. As important as the process itself is that everyone believes that having constant communication and collaboration throughout the project is vital to success. Another example that I can think is that of technical excellence. I believe that more important than having a defined process for developing is having the mentality of a software craftsman and understand why technical excellence is so important (why doing automated tests, clean code, etc.).

Agile was described for the first time as a set of values, and it is this set of values what guides agilists. Having these values defined and clear inside the organization is probably of more value than having the exact process definitions. I know it does sound unrealistic, as having a repository of values probably doesn’t make a lot of sense. Probably values live more on the tacit knowledge of the organization and they are more like a human asset. Well, Agile is more about people than about processes after all...

Quantitatively Managed Process

“A quantitatively managed process is a defined process that is controlled
using statistical and other quantitative techniques. The product quality,
service quality, and process-performance attributes are measurable and
controlled throughout the project.” Measuring and statistically analysing allows to identify the special causes of variation and prevent its recurrence.

There are 2 things that I am afraid to, when measuring the processes. First, something that stayed firmly in my mind after reading Highsmith’s book: Value over constraints. It’s far more important to measure, or at least to understand, how  much value a certain process provides than to measure and optimize for the constraints. A team worried by meeting objectives related to constraints is at great risk of generating dysfunctional behaviours which decrease the value that the team is able to generate. The second thing that I am afraid of is relying only or too much on numbers and measures. I know from an organization perspective (broad perspective) understanding what works and what doesn’t in terms of numbers is perhaps the only way to know what’s working and what isn’t but my experience in development teams says that common sense and team feeling are also important, not measurable and equally important. I guess I am reluctant to believe that everything in a human intensive task such as developing software can be quantifiable.

Optimizing Process

“An optimizing process is a quantitatively managed process that is changed and adapted to meet relevant current and projected business objectives. An optimizing process focuses on continually improving process performance through both  incremental and innovative technological improvements.                              Process improvements that address common causes of process variation, root causes of defects, and other problems; and those that would measurably improve the organization’s
processes are identified, evaluated, and deployed as appropriate.”

A couple of thoughts came to my mind after reading the CMMI optimizing process level: First, it seems to me that the definition is geared towards a production environment, not a development one. Variable results are good in development, when knowledge is formed and not good in production. Second, it is weird to me that the idea of optimizing comes only in the last level coming from the Agile world, where introspection and improvement are performed since the very beginning (at a very intuitive level). On one side, it makes sense because to be able to optimize, you need to have a managed process and be able to measure/quantify what needs to be improve. On the other, leaving the optimize mentality until the last level could be harming (in my opinion). Finally, nowhere does it say that the optimization is to be able to produce more value for the process, which I think should be the first objective. Probably, in other engineerings or in manufacturing, optimization is performed to decrease variation or find root causes for defects. In software development, where variability creates knowledge, this is not entirely true.

Conclusions

I believe that intuitively, the capability levels are compatible. The first improvement from not doing anything is that the process is managed, i.e plan and monitor to take corrective action. Doing it in an Agile way, it should be managed by the team. Then, there is institutionalization. I believe that the institutionalization of the Agile values is equally important than institutionalizing the processes. Then, there is understanding how good or how bad the process is working and optimizing it. The most important, but probably most difficult thing to quantify is how much value the process provides. Also, something to keep in mind is that software development is very different than doing manufacturing.