Scott Ambler Revisits Agile Process Maturity Models
Scott Ambler, who once wrote 'Has Hell Frozen Over? An Agile Maturity Model?', has started writing about something that he is calling the Agile Process Maturity Model. The discussion around Scott's model has uncovered another model by the same name, and renewed the debate over the usefulness of a maturity model for agile.
Scott describes the motivation for his model this way: "The goal of the Agile Process Maturity Model (APMM) is to provide a framework which provides context for the plethora of agile methodologies out there today."
Scott's first article about the APMM described his model as having three levels:
- Core Agile Software Development
In this level Scott places Scrum, XP, Agile Modeling, and Agile Data.
- Disciplined Agile Software Development
Here we get hybrids such as Scrum + XP, as well as RUP, OpenUP, and DSDM.
- Agility at Scale
Scott doesn't list any examples here, simply stating that this level is about "explicitly addressing the complexities which disciplined agile delivery teams face in the real world." In a subsequent article, he explains that Level 3 is Level 2 with one or more scaling factors prevalent.
A maturity model, in our industry at least, defines levels of adoption, by a specific organization, in its specific context, of certain practices... A maturity model classifies levels of maturity in adoption of practices by an organization, and shows areas of interest that the organization should address to in order to improve.
... to stimulate a discussion in the Software Engineering community to define a standardized and consensual model, that can be adopted by organizations that are interested in beginning or improving the application of Agile Methods for software development and evolution.
In this model, an organization could assess its level of agile process maturity along two dimensions: technical and managerial. Along each dimension, a three level rating scale is proposed.
Along the technical levels are:
No particular practice is established in this level. An organization whose software process is at this level does not follow the basic premises of the agile attitude.
This level contains the minimum requirements in order for a process to be considered agile.
In this level, the organization begins the quest for technical improvement of its process, departing from the minimum features that define an agile process towards a more disciplined, professional, efficient, and productive process.
Similarly, 3 levels are proposed for managerial process maturity:
Characterized by the absence of particular practices.
Project management practices are established
Intra-project practices support management decisions with numerical data.
This is not the first time that InfoQ has reported on potential maturity models for agile. In October of 2007, Amr Elssamadisy wrote 'Does the Agile Community Need a Maturity Model?' That same month, the topic came up in 'What is the Value of the Nokia Test?'
Would an agile maturity model be useful? If so, what would it look like? Leave a comment and share your thoughts.
Agile (Maturity) Models
As to whether a maturity model would be useful, I am not sure it would be until there was some broad acceptance of what beliefs, behaviors, practices, etc. define "agile" and which ones represent lower vs higher levels of capability.
I think what could help organizations is an adoption progression scale that would help organizations new to agile understand a reasonable path toward becoming more and more agile. With this, the next step could be assessing maturity/capability based on how effectively organizations achieve the goals at each level of progression. This is, in effect, what the CMM(I) scales were/are about, i.e., an improvement guide rather than "qualification" scale.
Perhaps the worst thing at this time would be a model that would somehow lead people to think an organization could be "certified" to some level of maturity as a public statement to others instead of just as a guide for their own growth. This is what happened to the CMM because of the use to which its DoD sponsors wanted to put it. The agile community is not directed by funding agents who are demanding a model, so we can be thankful for that.
Having worked somewhat on the IEEE group looking into a recommended practice for the customer-supplier relationship in an agile context, it is quite hard to get significant consensus in this area. Hence, various individuals/groups are trying to develop their own variations in these models without worrying about a consensus process at the moment.
I think the time to develop such models would do the community more good if a consensus approach were taken and people dedicated themselves to that, allowing the resulting effort to then be tested in industry and incrementally improved based on that experience. This is, in fact, what the intent of the IEEE effort is at the moment.
Empire "trying to" strike back
Unfortunately, agile software development methodologies are based on principle of emergence where 2 + 2 may not be equal to 4. See this - setandbma.wordpress.com/2009/04/25/agile-method...
Time has come for managers to have a paradigm shift in thinking.
First Agile Maturity Model (2002)
You can read the chapter here
and see it described on slide 21 of this 2004 presentation
The message is simple...
First describe the workflow or value chain, decide how to instrument it (which metrics to use)
Second implement a tracking system, start gathering the metrics and reporting them transparently
Third stabilize the performance and make it more predictable by implementing agile changes to reduce variability such test-first, continuous integration, velocity tracking etc etc
Fourth start to use the information to drive changes and adopt appropriate agile practices to make incremental improvement to throughput
Fifth (finally) start to use more advanced prioritization schemes and decision making techniques to balance risk across a portfolio and make more risky choices - innovate more
Another way of thinking about this is that it is a model for trust building. The level of trust (or social capital) increases as you move up the levels.
I no longer consider this an Agile Maturity Model but consider it an Agile Implementation Model. It's a model that allows for transition to Agile in an agile / learning organization fashion rather than a big-bang transition implemented through command and control. Ironically, most of the folks out their selling "agile transition" are doing it in a non-agile fashion.
So given this additional insight... Are Scott and others talking about a true Maturity Model in the sense of MMM and CMMI where the model assesses the capability of an organization to make well informed risk management decisions and to adapt gracefully to changing conditions, or are they really talking about an Adoption Model that describes the timing and sequence of adoption of Agile techniques?
Re: First Agile Maturity Model (2002)
Delivering Performance Under Schedule and Resource Pressure: Lessons Learned at Google and Microsoft
Ivan Filho Mar 06, 2014