BT

Scott Ambler Revisits Agile Process Maturity Models

by Chris Sims on Apr 27, 2009 |

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:

  1. Core Agile Software Development
    In this level Scott places Scrum, XP, Agile Modeling, and Agile Data.

  2. Disciplined Agile Software Development
    Here we get hybrids such as Scrum + XP, as well as RUP, OpenUP, and DSDM.

  3. 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.

Jeff Anderson and others commented that this isn't a maturity model, so much as a classification scheme for software processes. Adriano Comai explained it this way:

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.

Curt Hibbs pointed out a paper on the website of Professor Juliano Lopes de Oliveira. This paper proposed a different Agile Process Maturity Model, whose stated objective is:

... 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:

  1. Non-Agile
    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.

  2. Minimum
    This level contains the minimum requirements in order for a process to be considered agile.

  3. Consolidated
    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:

  1. Initial
    Characterized by the absence of particular practices.

  2. Organized
    Project management practices are established

  3. Disciplined
    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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Agile (Maturity) Models by Scott Duncan

I agree that the model Scott describes isn't a "maturity" model and is, instead, a classification model for processes, which does not, per se, convey maturity based on process size/complexity. The other model described (with both technical and managerial "scales") does not seem to be agile-related in particular and, inded, seem to be somewhat of a simplification of the CMM(I) staged maturity scale.

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 by Udayan Banerjee

Would we not love to have a maturity model which defines a checklist of practices that you have to follow so that you can be assessed at a certain level of maturity. This will give managers a clearly defined target to achieve.

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) by David Anderson

I first proposed an Agile Maturity Model in 2002 and it appeared as chapter 11 in my 2003 book, Agile Management for Software Engineering. I've since debunked it as a "maturity" model but I now refer to it as an Agile Adoption Model and it reflects the style of engagement I use with consulting clients in order to get them to adopt Agile change with the minimum resistance.

You can read the chapter here
books.google.co.uk/books?id=hawMF31KCRsC&pg...

and see it described on slide 21 of this 2004 presentation
www.agilemanagement.net/Articles/hidden/AGSE_Ov...

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?

David
www.agilemanagement.net/

Re: First Agile Maturity Model (2002) by David Anderson

Oops, The Maturity Model is described on slide 26 not slide 21 as I said above...
www.agilemanagement.net/Articles/hidden/AGSE_Ov...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT