What is the standard for evaluating team maturity?

Question

There are ever so many references to the team's 'maturity' in the Agile/Lean related books and articles/blogs.

Using my common sense I think I can get the idea. I can see how my team has evolved over the last year and how is still evolving. But still, I know for sure that we lack maturity.

We are a self-organizing team without anyone experienced enough to guide us through the difficult time of changes. We are finding our way (with myself - the most recent enthusiast of kanban and lean methodology) and we will get there.

We are in our early days working aside the kanban board, getting there to automate a number of processes. Learning. We are getting agile bit by bit. We are growing and I can feel it.

But is there any way to measure where we are? Is there any benchmark? And what are the next steps?

Answer 1

Your team is the benchmark.

If last week you weren't doing Test-Driven-Development, but you all agreed that was something you wanted to change for the next go-round, and you did...there you go. If you decided to give it a go - but didn't - well, you didn't follow through...not the end of the world, but could probably do with some follow-through and improvement if it was a stated goal.

If you are using Lean with a Kanban board, I'm assuming you are tracking how long it takes for an item to go from ready to done. How long items spend in each column. Etc. When you find out where your bottlenecks are - identify them, mark them as being "found out" - then start figuring out how to iron down that molehill (or whether that's a molehill you can iron down, or even if it should be ironed down). Did you manage to do it? Great! Not so much? Do the 5 whys exercise.

Basically, don't compare yourself against other teams, it's just asking for trouble. Your circumstance is different. Your "vibe" is unique. Your team culture is not their team culture. Your marketplace is not their marketplace. That's the beauty of Agile, as something internalized (pardon the cheese for a moment) - it doesn't say: You must do it this way, and just look at the $50 billion team over there - they're way better than us...sure, but you aren't there yet. Are you doing better than you did the last time in some measurable way (that you, as a team, have determined is worth measuring)? Then you're doing just fine. There are enough users and tasks to complete for everyone to have a piece and leave enough for the next generation.

Hope that helps. And maybe answers the question.

Answer 2

Formal Definitions

At this time, there are no formal definitions of maturity across agile methodologies. However, the Capability Maturity Model Integration (CMMI) framework uses five levels to define process maturity:

• Level 1 - Initial (Chaotic)
• Level 2 - Repeatable
• Level 3 - Defined
• Level 4 - Managed
• Level 5 - Optimizing

If you're looking for a formal methodology to define maturity, then you may want to take a closer look at CMM and CMMI.

Maturity in Agile Methodologies

Generally, I try avoid the term "maturity" in talking about agile methodologies. I prefer to talk about framework experience and effectiveness of the implementation.

Personally, I use the following metrics to measure the experience and effectiveness of a team:

1. How well the team understands the theory of their framework.
2. How well the team understands the daily practice of their framework.
3. How well the team implements their framework's required practices.
4. How much self-organization and initiative the team applies to their processes.
5. How effective the team is at estimating work.
6. How effective the team is at continual process improvement (a.k.a. kaizen).
7. How effectively the team completes work as a team.

Please note that nowhere in those metrics do I include velocity, cycle time, work completion, or other project metrics vulnerable to externalities. It is extremely important to assess the team's capabilities directly, rather than using proxy metrics and trying to reason backwards from project metrics to team-capability metrics.

Answer 3

There are universal signs of team maturity. Use the Forming, Storming, Norming, Performing model as an example. The stages just in framework give a clue as to what you might see as your team matures. When you just form, you can expect to see civility between the members and high morale, but performance will be low, and direction from the boss will be high. As the team enters storming, as the name suggests, conflict will grow, allies and enemies created, sabotage is likely, and morale will drop. The boss will even have to provide higher direction and more micro management (this is when micro management is NOT bad despite the general belief most have). Then, into norming, the team starts to settle in, roles begin to emerge (think Belbin roles here, where individuals start assuming various roles that complete a team), morale grows again, and boss direction begins to drop. Performance starts to improve as well where the deliverables become "collective" in responsibility. If Bob fails, we all fail.

Finally, in perform, boss direction is near hands off, the team is self organizing, morale is high, productivity is high, conflict still occurs as a natural consequence of working together but how it is resolved is worlds apart from the storming stage.

So, opposite of what Josh suggests, comparison to other teams is what you need to do, as this is how these various teaming frameworks were developed in the first place.

Answer 4

I am of the opinion that it is more valuable to compare your team's current maturity against where you want to be rather than against where you started. To this end:

• Define a reasonable, achieveable future state. This definition needs to be based on your business requirements and not on what a text book says. Key to success here is engaging your team in arriving at this definition/vision.
• Identify meaningful metrics for measuring success. These would ideally be objective but could be subjective (e.g. polling the team for their opinions on current team maturity, soliciting lessons learned, etc). As part of the definition you should also specify how and how often the metrics are measured.
• Plan for ongoing follow up. It is all fine and good to come up with an idea and monitor metrics, but you need to have a plan to ensure that the team stays mature over the long haul once it gets there.

Answer 5

Your benchmark must be your customers' satisfaction, your recovery from failures, and reaction time. The last two affects the first.

Let's say that team immaturity exist which means that the team cannot perform well without an external supervision. The team doesn't learn, but waits [and excepts] for external help. Therefore an immature team has long reaction time (due to the waiting), and practically no self-recovery (due to the help). These two will result in poor customer satisfaction.

A mature team learns from previous team experiences and from external supervision, and the dependency between the team and the external supervision is loose. The team's reaction time is shorter and recovery is faster week by week. This results in better and better customer satisfaction.

Answer 6

Rather than thinking about measuring the maturity of the teams progress with agile, think about measuring what you are using agile to achieve. Agile allows you to deliver real business value to the customer as quickly as possible.

So to that end I would recommend looking at the practice of continuous delivery. The book Continuous Delivery by Jez Humble and David Farley was the most inspiring book I read last year and has really helped my team to grow to the next level.

The reason I mention this is that in the back of the book they describe a maturity model, which I also found online (look at the table right at the bottom of the page). This describes several categories to measure your teams maturity by.

I know this could be considered a little off topic, and not necessarily a measure of agile/lean maturity. But in my opinion it's a great benchmark that gives you real tangible targets to aim for.