What is the Purpose of an Agile Maturity Model?

In my last post, my attempt to answer the question “What is an Agile Maturity Model?” did not get too far before we ran into potential semantic confusion with the term “maturity model.”  We established that there are at least two types of maturity models, namely Lifecycle models and (tentatively)  evolutionary models. Although they share the attribute of progressive phases, they also have important differences. The lifecycle models maturity as the aging process: Birth, growth, decline and death. The evolutionary model advances but does not decline or if decline does occur — unlike aging — it’s reversible. Since Agility is a quality that is voluntarily acquired and does not inevitably progress, the lifecycle model appears to be a poor fit. This allows us to reduce some semantic ambiguity by tentatively replacing the term “maturity” with the more narrowly defined “evolution.” Unfortunately there are also problems with the term “evolution.”

Although the term “evolution” is often used to denote progress, the biological theory of evolution is entirely devoid of this notion. Organisms adapt as needed to changing conditions in the environment. End of story. The statement that “humans are more highly evolved than other animals” is not based on science. So perhaps the term “evolution” is not the best fit, after all. So then what?

I proposed the term “progressive phases” in my last post as a common quality of lifecycle and evolutionary models. Can we use that term? Well, since we are being picky, the word “phases” has some issues. “Phases” of the moon starts us back on the lifecycle track and phase states (e.g., solid, liquid, gas) has (like evolution) no innate quality of progress. How about the word “stages”?

“Stages” means that changes take place in discrete, characteristically recognizable steps, which can be used to identify the subject’s current stage. For example, if a butterfly has wings it has reached its adult stage. Stages (for our purposes) are also successive (e.g., the pupa stage always precedes the adult stage of the butterfly). This is in contrast to change with unpredictable or arbitrary outcomes (e.g., evolutionary change). “Stages” is a better fit than “Phases.” How about “progressive”?

“Progressive” may mean that things get better as they succeed through stages. For example, each successive stage in Maslow’s need hierarchy represents a qualitatively superior state compared to its predecessors. Alternatively, progressive may mean moving closer to a goal. For example, in the case of the cognitive phases of a buyer (i.e., Awareness -> Interest -> Desire -> Action), although things succeed through stages, there is no payoff until the final stage. The term “better” matches our needs more closely than “closely” since we do expect things to get better as we progress through stages. Therefore we will restrict our use of “progressive stages” to mean “gets better and better in stages”.

We can avoid much of the semantic ambiguity of the term “maturity model” by substituting the phrase “model that characterizes the progressive stages (of something)”. Now we can now update our previous template for an Agile maturity model to the following:

A model that characterizes the progressive stages of something
(as yet undefined) that gets (measurably) more Agile.

We now find ourselves in a better position to consider the purpose of our Model.

More confusion

Turns out in addition to metaphoric confusion there is also the potential for confusion about purpose or, to put it more precisely, confusion between means and ends. Although the immediate purpose of an agile maturity model — to measure the stage of maturity that has been achieved — is clear enough, it is not very satisfactory. To obtain a more satisfying answer we need to link it to a further purpose. To do so we can employ laddering,  a technique used in TQM to depict means-end chains.

The rungs of the ladder represent the links between means and ends. Whether or not a particular rung is viewed as a means or an end depends on if you are going up or down the ladder. When you go up, the current rung is viewed as the means to the rung directly above. When you go down, the current rung is viewed as an end to the rung directly below. As you go up the ladder the answer to the question “Why the current rung?” is provided by the rung directly above. And as you go down the answer to the question “How to achieve the current rung?” is provided by the rung directly below. Let’s now create our own ladder:

Agile Maturity Ladder SolutionsIQ

Starting at the bottom we can work our way up the ladder, while asking the question “Why?”

1Why an Agile Maturity Model?Identify Maturity Stage
2Why identify Maturity Stage?Determine how Agile we are becoming
3Why Become more Agile

Lets pause here for a moment and consider an article posted by Esther Derby entitled “Achieving Agility: Means to an end. Or end in itself”.

She points out that seeking to grow more Agile as an end in itself serves no useful purpose. Agility has utility only insofar as it serves as a means to obtain some business objective (i.e., an end). The broader purpose of our Agile maturity model then depends on the specific business objectives we are trying to obtain. Since each business has different business priorities the extended purpose of Agility (and our Agility maturity model) will vary from organization to organization. Therefore there is no point in asking questions such as “Am I more agile than Company B?”

It is also pointless to ask questions such as “What percent agile am I?” (or what Agile stage have I achieved) outside the context of specific business goals. In fact, these questions may be pointless even if they are attached to business goals.

First of all, progressive stages of maturity need to correspond to progressive changes in business objective performance. Secondly, although business objectives vary, the Agile stages must remain the same. If both of these conditions don’t hold, then the stages attribute of our model will also not hold. If the stages attribute does not survive our inquiry, our grounds for calling our model a maturity model become very shaky. It’s interesting to note that of the six examples of maturity models that are progressive stage models (numbers 2 and 8 are excluded as lifecycle models) listed in my previous post, four are criticized for having successive stages. The critics complain that if the stages exist they don’t necessarily take place in the prescribed sequence. One of the remaining two models, CMMI, offers both staged and non-staged versions, which suggests that “stages” are not a hard constraint. This is a change from CMMI’s precursor, CMM, which was a staged model and was criticized for being so. Since we are talking about it, it’s definitely worth remembering that CMM implementations were heavily criticized for being conducted as ends in themselves. Although engineering groups at considerable expense became certified as CMM Level 3, 4, & 5, the business at large did not necessarily improve. Even though CMMI has been designed to avoid this problem, justified or not it still suffers this criticism. This of course is the very problem that Esther Derby exhorts us to avoid.

So where does this leave us? Well, if we are going to hang on to the notion of “(successive) stages”, we need to come up with pretty convincing empirical evidence that these stages actually exist. And, if we fail, maybe it’s time to give up on the notion of an Agile Maturity Model. I think it’s interesting to consider that in our survey of models across several disciplines that were originally designed as staged models, most have subsequently been de-legitimized for being so. It makes one wonder if our underlying paradigm for progress is shifting from a staged paradigm to something else. If a more fitting paradigm for progress is emerging, maybe that is where we should be looking for a useful model. Something for us to keep in mind.

Getting back to Esther Derby’s fundamental point, whether we end up sticking with a maturity model or come up with a new kind of model, we will still need to convincingly demonstrate how the model is linked to business objective improvements, if it is to have utility. Something else for us to keep in mind.

We climbed up our ladder high enough to determine that the adoption of Agile practices should be linked to the higher purpose of achieving specific business objectives if advancement in Agility is to have any meaning. At some point someone should move further up the ladder to make sure that the business objectives themselves are linked to a higher purpose. In the world of commerce, the ultimate purpose that we find at the top of the ladder is to increase business value. Ultimately then our use of agile practices should be part the of  a means-end chain that leads to the generation of business value.
Creative Commons License

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.