Does the Agile Community Need a Maturity Model?

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.

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

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.

Paul

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.

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

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.

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.

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?

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.

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.

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

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

Are you mature enough for Agile?

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.

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.