Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Posted 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:
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:
Similarly, 3 levels are proposed for managerial process maturity:
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.
Learning to be a Good Product Owner: Foundation Skills
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
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.
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.
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/
Oops, The Maturity Model is described on slide 26 not slide 21 as I said above...
www.agilemanagement.net/Articles/hidden/AGSE_Ov...
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
4 comments
Watch Thread Reply