Featured in
Architecture & Design

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Operations & Infrastructure

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Enterprise Architecture

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Does the Agile Community Need a Maturity Model?

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?

Write a simple story that describes the process you followed. Examples are included in the spreadsheet.

Rate your process on 12 criteria based on the Agile Alliance principles

Enter weights and view results.

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.

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?

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

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.

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.

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

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.

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?