Does the Agile Community Need a Maturity Model?

| by Amr Elssamadisy on Oct 16, 2007. Estimated reading time: 1 minute |

Periodically an Agile Maturity Model or a Framework for Agile Adoption shows up on the radar. There are also several consulting companies performing Agile 'readiness assessments' as a precursor to helping their clients 'become' Agile.  Are these indications of an unfulfilled need in the community?

Nick Malik of Microsoft, created the Simple Lifecycle Agile Maturity Model in an effort to help people determine how agile they are:

Using this model, the team follows a simple process:

  1. Write a simple story that describes the process you followed. Examples are included in the spreadsheet.
  2. Rate your process on 12 criteria based on the Agile Alliance principles
  3. Enter weights and view results.
  4. Create a list of steps to address deficiencies. Follow the normal agile process to estimate these steps and add to the backlog.

Earlier this year, Ahmed Sidky and James D. Arthur, presented a framework for Agile Adoption which relies on a readiness assessment that rates a group/organization/enterprise.  Based on the readiness level, a set of practices are prescribed to help guide the team/organization/enterprise in which practices to adopt to get to the next level of maturity.

A quick Google search on "agile readiness assessment" will result in list of consulting companies that are ready, willing, and (claim to be) able to help you find out how ready you are for Agile.

Are these offers filling a real need?  Is being Agile an end in-and-of-itself?  Should you or I care how Agile we are?  If this is a true need, then which of these offerings are correct?  Is it a one-size-fits-all problem that can be addressed with one model?

Or, is being Agile not the goal at all?  Could it be that Agile is a means to an end?  Could the end be valuable, maintainable software that meets and exceeds the needs of its users?  And, if being Agile is not the goal, should we be focused on becoming Agile - or should we be focused on achieving our true goals and only using Agile practices when they get us closer to our goals?

Rate this Article


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

I suppose I shouldn't be surprised. by Bruce Rennie

Has anyone ever seen "We need to be Agile" in any business goals of any company, anywhere, at any time?

I haven't and I hope to god I never do.

Agile is nothing. Producing value for the company is the only thing that matters. If we can do that via Agile methods and practices, then cool. If not, then why would I want to be "more Agile"?

This is pretty much exactly where most ISO and CMM efforts get it wrong. Let's please not follow them down that path.

Re: I suppose I shouldn't be surprised. by Johannes Brodwall

No, no, we need to find a Process by which we can Document how we adhere to agile Practices. Based on this document we should make everyone sign the Plan on how we will adhere to all Practices and Document how we value

  • Working software over comprehensive documentation

  • People and interactions over processes and tools

  • Adapting to change over following a plan

  • Customer collaboration over contract negotation

Or maybe not.

Re: I suppose I shouldn't be surprised. by Paul Russell

Health cynacism is good, and I agree to some degree.

One thing I would say though is that I've worked for companies before who claim to be doing agile, and actually just use it as an excuse to 'not-do-waterfall'. This can lead to virtual anarchy, since none of the principles and practices present in a proper Agile project are in place. When these projects run into difficulties, it's quite common for management to attempt to lay the blame at the feet of 'Agile'. It is very useful therefore to be able to somehow identify projects that fit into this category.


Re: I suppose I shouldn't be surprised. by Bruce Rennie

Do you think companies who are knowingly doing this are going to be interested in hiring a consultant to tell them their agile "quotient"? Or would be interested in the results even if they did?

I do really wish Agile proponents would stop spending so much time trying to defend the good name of Agile. It can't be done. People WILL abuse the name of Agile. Let's just admit it will happen and move on. Let's NOT put in place a bunch of meaningless measurements that will only add noise and provide no value to those who are approaching Agile in an honest manner.

Re: I suppose I shouldn't be surprised. by Amr Elssamadisy

It is very useful therefore to be able to somehow identify projects that fit into this category.

So, are you suggesting that a maturity model or a readiness assessment can identify this problem? Then, once it is identified it is no more the fault of 'Agile'?

So how does this help the team in question?

Cynacism aside... by Amr Elssamadisy

Are there legitimate uses for readiness assessments and maturity models for guidance? I can see some limited benefit to help teams go in a generally good direction, but I also see this as wasteful - not all teams have the same problems.

But, focusing on business value means that the company adopting agile practices will need a value-to-practice mapping. One way to look at it is shown in this article.

Wow this is dumb by Marc Stock

Yes what Agile really needs is more crap like this. This is all about making money and has nothing whatsoever to do with being Agile.

If you want to know if your project is agile, there's no test required, no checklist to look at, no special "assessment" needed. Just ask yourself if your project "feels" agile. If the answer is no, then you're not agile. Then ask yourself what parts don't feel agile and address them. Wow, real rocket science, eh?

Why people need to make something that is so very simple so complicated is beyond me (besides the obvious profit inscentive). There's a lot more people talking about agile than doing it, it seems.

The other side of the coin... by Amr Elssamadisy

All of the comments so far have been anti-maturity model and anti-assessment (including mine). So let's call out some of the needs of groups that are adopting Agile practices:

1) A group can adopt things 'by-the-book' and not see the benefits. For example, a group adopting Scrum (without TDD) works iteratively and then hits a wall near the end of the release because of a large number of bugs and inability of the existing architecture/design to accommodate the new requirements.

2) A group adopts TDD in a legacy environment and slows down 50%. They are seen as being ineffective and there is little 'proof' that the code base is better. In fact, several compromises have been made (in the form of sprouting), to put the legacy code under test.

3)A team has a Customer-part-of-team but still has trouble with competitors on a function/usefulness/usability standpoint.

What's wrong with each? What practices are faulty? Are they faulty? They don't have the experience/expertise to debug their practices because this is their 'first time around the block'. They need help.

So - can an assessment or maturity model help here? Or do they need help from a more experienced person who's made these mistakes before? Or what?

Re: The other side of the coin... by Bruce Rennie

I'm not sure how I see an assessment helping anyone in the situations you cited. The only thing that can help in those situations is:

1. Having people around with some experience
2. A willingness to listen to those people

Otherwise, it's a learning situation.

I don't know. I guess I just feel that if you're trying to implement Agile in an environment where the organization is going to throw in the towel that early then an assessment isn't going to save you.

Maturity Level is very different from Readiness by Deborah Hartmann

In my preferred model, an organization advances toward team agility as an organic process. In this model, a team starts at a certain maturity level (circumscribed by organizational constraints or team understanding) and embarks on a journey through various stages of maturity until it reaches a level that is sufficient for their needs (return/cost = optimal for their situation). What level is that? You won't be surprised to hear me say "it depends". I like Ron Jeffries' byline: How good do you want to be, and when?

Teams practicing continuous improvement should be constantly looking at their process, and Agile teams tend to look at it in relation to the Agile values and principles, as does the SLAMM proposed. The problem with formal a model that "ranks" maturity is the implication that a "higher" level is better. Of course, applied judiciously, as a thinking tool, such a ranking may be useful input for a team with a mature attitude. (I didn't download the software, so I don't have a first hand opinion of the tool in question.)

I would like to point out, however, that "readiness" for agile adoption may be something else entirely. Whether measuring the readiness of a traditional organization for agile adoption, or the readiness of a partially agile team for further agile improvement... this probably needs to look at contextual elements not easily revealed by looking at the (abstract) agile manifesto.

I suspect the "agile readiness" assessment has emerged to fill two needs: 1) help consultants filter out organizations attracted by the agile "fad" but unwilling/unable to adopt the underlying values and paradigm; and 2) to help management evaluate areas of risk for agile adoption - and whether to move forward with adoption. Having evaluated the feasibility and risks, the cost of adoption can be properly assessed, a normal "due diligence" step for any business. If the assessment provides useful information for these purposes, it seems a natural activity - and one which will probably happen informally if not approached through a formal exercise.

The question is: what constitutes "readiness"? I believe some of the parameters for this lie outside the organization's current process, in the domains of organizational culture, management style, compensation schemes, morale, etc.

And, of course, if an organization doesn't very much need a change in order to perform, the cost of process change may well outweigh any benefits. It IS all about organizational performance... the lesson of lean is to look at the whole value stream, and not to play CYA by implementing sub-optimal process changes in IT. If this isn't part of the assessment, it's short-sighted.

Re: Maturity Level is very different from Readiness by Deborah Hartmann

PS: the Agile Manifesto is at and does not require any download of software :-)

Re: Maturity Level is very different from Readiness (are they?) by Amr Elssamadisy

Isn't readiness assessment a type of maturity model with only a TRUE/FALSE answer?

Are you mature enough for Agile?

Re: Maturity Level is very different from Readiness (are they?) by Deborah Hartmann

Well, perhaps the question is:
{Are you | Is your organization} mature enough for {a new incarnation of your process}?

A team may be ready to begin implementing Agile, but then they get stuck - say, due to pushback from other parts of the organization. Sometimes they'll pull in an outside coach to help. It's important for that coach to evaluate: Can they realistically move forward toward a more effective process? If those outside groups are not open to dialogue, then perhaps not... in which case it might be prudent to put the needed "blockers" in place, and opt for a slower bridge-building effort, which might bring them to readiness later.

Re: Maturity Level is very different from Readiness (are they?) by Deborah Hartmann

From the Industrial XP website, about their readiness assessments, specifically for XP implementation:
Readiness Assessments can take days or minutes. We have conducted 3-day Readiness Assessments and we've conducted 20-minute ones.

Below is a list of the kinds of questions we ask:

  • We ask technical questions to learn whether we can establish the kind of programming environment IXP requires (staging machines, pair-programming workstations, a database we can actually evolve, version control that is under our control, etc).

  • We learn whether Subject Matter experts will be available for a project, whether we can get on-going feedback from the people for whom we'll be creating software

  • We ask about the dedication to continuous improvement, whether there is a commitment to doing retrospectives both during and at the end-of the project.

  • We ask questions about the organizational culture and structure, whether other parts of the system will support change or construct barriers to change. We ask about the history of change in the organization.

  • We ask about the outcomes and dynamics of previous projects and about those who will be involved in the current project community.

  • We ask and talk and learn enough to give us a sense of whether IXP could happen.

Note that they ask about past experiences with process change: frequently cited as an important aspect of assessment, and something that might be missing from a manifesto-based assessment. Teams jaded by past "silver bullet" process change initiatives may pose particular obstacles to adoption.

As ever, I'd maintain that the unspoken guiding questions are: how good do you need to be, and how much do you want to spend getting there?

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

14 Discuss