The article proposed the following as an agile maturity model:
More “observed” than “proposed” as indicated by emphasizing the notion of “grounded in reality”.
I didn’t find it to be a particularly useful model. Although descriptive, it won’t help your organization improve.
By being descriptive of “evolutionary stages”, it offers insight around “what next” in the journey. The model does not prescribe “how” to improve (or make the journey). How to improve involves adoption, which is outside the scope of the model.
For a maturity model to be useful, you have to be able to do two things.
- You must be able to determine where your organization is in the model.
- You must be able to identify actions you can take to “improve” your organization relative to the model.
If you can’t measure maturity, and the model does not provide guidance about how to improve, it’s useless. One challenge with maturity models is that they risk becoming contextually narrow in their application. The more concrete a measurement or suggestion becomes, the less extensible it is likely to be. Ideally, your model would be broadly applicable to many organizations.
Reality is messy and models are mere abstractions of reality, while models inform, they cannot be considered in isolation. Notice that it is “You” who is judging “where your organization is in the model” and “You” who is to “identify actions you can take to ‘improve’ your organization”. Thus, a model ought to be “grounded in reality” and is context-aware but not context-sensitive (that is, “guidance” without “becoming contextually narrow” but remaining ” broadly applicable”).
With an agile manifesto that emphasizes people over process, it is ironic to consider applying a metric that measures your agile process. So – goal #1 is immediately undermined. Goal #2 – improving your organization, is, however, very valuable.
The AMM does not suggest “a metric that measures your agile process”. To measure your Agility, measure your Responsiveness (people and business system, that is, structure and processes, etc.). Agility also pre dates the manifesto by far (see the blog for more).
One powerful use of a maturity model is highlighting the next-biggest hurdle you have to overcome. Unfortunately, most communication about maturity models is “look which hurdle we just overcame” – but the focus should be on “what’s next?”
Indeed, this is what is expressed by “evolutionary” as used in “evolution stages”, it offers insight around “what next”.
Its “adoption” (as the author says “agile agile adoption”) that focuses on how to achieve the “what next”.
That’s how you should use a maturity model – as guidance about “what’s next?”
AMM meets this (in the proper hands) but nothing can be used in isolation.
The author offers an “agile hierarchy of needs” (that he has “presented” “in the past”), which includes:
- Staffing the engineering team correctly.
- Assuring Quality is in your team’s DNA.
- Reducing overhead in the release process.
- Feeding the beast.
- Managing stakeholder expectations.
- Continuously learning from your markets.
If one examines the description carefully, you will see that:
- Steps 1, 2, and 3 generally relate to the AMM’s Speed stage as “efficiency” and “efficiently” are mentioned in the article.
- Steps 4 and 5 generally relate to the AMM’s Reactive stage as “make sure your management team is happy and engaged and knows that to expect”.
- Step 6 generally relates to the AMM’s Responsive stage as “business agility”.
Without further commenting on the steps (as there are many aspects on which to comment, both positive and negative), this further proves the common pattern expressed by the AMM (via observation and grounding in reality).