Channels ▼


The Agile Maturity Model (AMM)

The Agile Maturity Model

The primary goal of a maturity model is to provide guidance to an organization to help improve a facet of its business. So, an ice cream maturity model would provide guidance for improving the production of ice cream and a marketing maturity model would provide guidance for improving your approach to marketing. In this article, I describe the Agile Maturity Model (AMM), a five-stage model that provides guidance for improving your effectiveness at agile software development.

Level 1 of the AMM is the Rhetorical stage. Agile practitioners at this level accept that agile is the art of the possible where developers have the courage to deal with tomorrow's problems tomorrow. Level 1 development teams adopt agile process frameworks because they know that defined processes, or methods depending on your chosen terminology, will only lead them astray. We know this because agile process frameworks are empirical, although to be fair non-agile processes and process frameworks can also be equally as empirical were the same rhetoric applied. Respect is important, except when it comes to traditional/classical ideas which have observably, or dare I say empirically, worked for many project teams worldwide.

At the Rhetorical stage decisions are made within our self-organizing teams by pigs and accepted (hopefully) by chickens, although I'm concerned that many agilists insist on being thought of as pigs. We should desperately avoid finding ourselves in "Scrum But" situations because we couldn't possibly benefit from adopting just a few agile practices, such as short timeboxes or hiring product owners with wringable necks, regardless of the overwhelming empirical evidence to the contrary. Level 1 agile teams typically succeed because agile strategies were applied on hand-picked pilot projects, by a small team of flexible and often highly-skilled people, and were given sufficient management support. Our rhetoric tells us that the fact that the team had adopted agile strategies is clearly the primary reason for success in these situations. Other important rhetoric is that if the emperor isn't wearing any clothes then you should tell him or her, unless or course it's an agile rhetoricleader, oops I mean agile thoughtleader, because whatever they say should be accepted verbatim.

Level 1 agile teams have made a good start but still have a long way to go. At the rhetorical stage agile teams often waste significant effort reinventing the "process wheel"... oops I mean the "process framework wheel", because they're too busy bashing any development strategy that came before agile. Our respect towards product owners is also questionable considering we love pointing out that theirs is the one neck we're going to wring. Level 1 agile practitioners generally don't respect management either, luckily they rarely seem to know what management does so that makes it easier, pointing out how stupid and ineffective managers are in practice. Waxing rhetorically about respect is much easier than actually giving respect after all.

Level 2 of the AMM is the Certified stage, the goal of which is to ride on the coattails of existing certification programs run by non-agile communities (the very same communities that we mock at the Rhetorical stage, so apparently they're good for something after all). The distinguishing feature of the Certified stage is that most team members have stayed awake in a two-day certification course and have successfully parroted back agile rhetoric in a multiple guess test which few people seem to fail. To maintain this level you must annually pay tribute to one or more of alliances of agile certifiers whose power relies solely on you being too timid to point out their naked greed and ambition. The certification program is nothing but a façade over a blatant money grab by the agile emperors, but as certified agile masters we're happy because we can now add a new certification logo on our business cards and email signatures. Granted, we'll eventually need to learn to live with the embarrassment once others discover how little we had to do to "earn" that certification, and live with the subsequent undermining of our organization's agile adoption effort, but those are tomorrow's problems which we're courageous enough to deal with tomorrow.

Level 3 of the AMM is the Plausible stage. At this stage we begin to focus on agile strategies which may in fact be actually viable within the organizational context in which we find ourselves. The focus is on small development teams working in a pretty much co-located manner, a strategy which increases the chance of project success dramatically (shown time and again by Dr. Dobb's project success surveys). At the plausible stage we struggle with scaling issues, such as strategies for large or distributed teams, because we didn't learn how to do so in our two-day agile mastery certification course. We abandon the marketing rhetoric of earlier stages after observing what actually works in practice -- interestingly, actually following the empiricism rhetoric of the agile rhetoricleaders undermines much of their other rhetoric, supporting the argument that this level should be called the Irony stage instead. We also abandon the certification façade and instead focus on gaining the skills, and understanding the strategies, required to successfully deliver high-quality working software to our stakeholders and thereby pay down the integrity debt built up during the Certified stage.

Level 4 of the AMM is the Respectable stage. At this stage agile teams adopt a full delivery lifecycle, not just a development lifecycle, and tailor their approach to meet the unique needs of the situation in which they find themselves. They adopt strategies from a variety of sources, including Scrum, Extreme Programming (XP), Unified Process (UP), Agile Modeling (AM), Lean Software Development, and more. They focus on producing solutions, not just software, and respect the fact that it may in fact be possible that non-agile approaches have their advantages too. Our focus is on delivering high-quality solutions, not just software, recognizing that we also work with hardware and motivate changes in both the business process and organization structures of our stakeholders. A focus on working solutions over just working software moves us beyond the developer and consultant driven rhetoric of the agile community to address the full spectrum of what agile delivery teams actually do. Furthermore, disciplined agile delivery teams at this stage are self organizing within an appropriate governance framework, recognizing that they work within the constraints of a larger organizational ecosystem.

Level 5 of the AMM is the Measured stage. With this strategy you collect information from instrumented and integrated tools to provide you with accurate information in real time, enabling you to steer your project based on real empirical information and not just observational guesswork. At this stage we respect the fact that most managers are very smart people doing the best that they can given the less-than-perfect information available to them. By providing more accurate information to management they are more likely to make better decisions, and appear empirically smarter as a result. This could also be called the "Agile, but…" or "hybrid" stage because your strategy weaves techniques from the agile, traditional, lean, and other paradigms in order to be as effective as possible. Level 5 agile practitioners are truly respectful of history, recognizing that the people who built the systems which are currently running the world had a bit of a clue after all. They tailor their approach to meet their actual needs, often addressing several of the scaling factors called out in the Agile Scaling Model (ASM), a topic that I'll discuss in detail in a future column.

This column was published on April 1, 2010 so it's up to you to determine whether or not the AMM is an April Fool's joke or not. Sadly, I suspect that this newsletter hits far too close for home for many readers, and I suspect that's because many within the agile community has lost its way in the last few years. Happy April Fool's day in any event.

Additiona Reading:

In Agile CMMI: Complimentary or Oxymoronic? I overview the Software Engineering Institute (SEI)'s technical note entitled CMMI or Agile? Why Not Embrace Both! , discussing the applicability of Capability Maturity Model Integrated (CMMI) to agile. If you're serious about an agile maturity model, these articles are likely a good starting point.

The Scum Certified Agile Master (SCAM) program at is a great opportunity for agile developers.



The Glacial Methodology is a new software process which is based on sound software engineering principles.

The article Embracing the OMG overviews the advantages of the Object Management Group (OMG)'s MDA, CWM, and XMI specifications.





The article An Executive Primer on Cloud Computing: What Vendors Aren't Telling You provides an overview of cloud computing and lifts back the covers to reveal some of the challenges being experienced by organizations that have adopted a cloud-based approach to their technical architecture.

My Agility@Scale blog discusses strategies for adopting and applying agile strategies in the complex environments. This is no joke!


Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags


<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags


<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

