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.
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:
- 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. - Minimum
This level contains the minimum requirements in order for a process to be considered agile. - 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:
- Initial
Characterized by the absence of particular practices. - Organized
Project management practices are established - 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.