The Elastic Leadership Book



        RSS Feed

Latest Entries


The 3 maturity stages of a software team and how scrum fails to identify them

Many so called ‘Agile’ teams fail so miserably to deliver for the simple fact that the teams simply are not mature enough to be part of an agile process that requires self managing teams.

I’ve learned to recognize three states a team can be in in terms of maturity -

  • Chaotic Stage – the state where a team does not posses the skills, motives or ambition to become a mature self managing team.
  • Mid-Life stage – where a team possess some skills for self management and decision making , and can make some of its own decisions without needing a team lead.
  • Mature stage – where a team is practically fully self managing and a team leader is mostly a coach rather than a decision maker.

The trick most team leaders need to do is to recognize which stage a team is in, and to advance their team to the next stage.

Most teams are chaotic

I would easily say that most teams are chaotic – either in technical lack of knowledge (‘what’s source control?’), lack of motives (‘I just code X lines of code and try to avoid QA’), or lack of ambition (‘things are fine the way they are’)

You can’t take a team that doesn’t even do source control, and say “you’re self managing from now on, GO.”  - no one will know what to do, or have any inclination to do it.

Maturing a team

The process of bringing a team to maturity, where a team leader as a dictator is never needed, still lacks a name. I’ve been asking around for possible names for this process. some of them were quite interesting:

    • Resetting a Team
    • Rebooting a Team
    • Reorienting a Team
    • Redirecting a Team
    • Team Regrouping
    • Team Rebirth
    • Team Renaissance
    • Team Reframing
    • Team Reincarnation
    • Team Resurrection

Each stage needs a different kind of team leader

Different team lead tactics apply to each stage. For the same reasons Scrum Masters (who are nothing but active coaches) fail to really help immature teams, as do team dictators, who hurt more than they help truly mature, self managing-able teams.

The chaotic stage needs a strong, dictator like leadership

-- if only to bring some much needed peace and quiet to a team that might be mostly struggling to keep its head above water all day long.

A dictator team lead is there in the first stage, to bring the team up to a specific state, where they also have the time and patience to learn new things. The team lead will help put out fires and put the team in a bubble so that decision making becomes easier until the team can make its own decisions. they will start doing code reviews and many of the things this blog advocates for.

Many of these same things will be seen with very big question marks on the faces of many agile coaches out there. They fail to realize that a chaotic team still isn’t ready for a coach. it needs a direction, a back wind, and an open road to get going.

The Mid-Life stage needs a coach-dictator

As the team lead feels that the team has reached some “safe shore” – they will move on to the next stage in the team’s life – the learning stage – the stage where a team will learn the skills needed to become self managing, all within a very concrete series of constraints that will slowly open up as the team progresses.

For example, the team lead will insist that code reviews be done on each check in, but will teach the team to do its own code review so that the team lead is no longer the bottleneck, and so that the team learns essential skills for code quality and decision making on what’s an acceptable piece of code.

Slowly but surely a team can progress to become fully self managing. At each stage of the team’s life, it learns skills that help it make its own decisions, until, at some point in time, the team lead does not need to make any day to day decisions. The team has all the skills needed to move on to the next stage.

This and the next, are the stages many scrum masters need in order to achieve anything. Sadly, most teams are not at this stage, and nothing but some good old fashioned dictatorship can help change things for those teams.

The Mature stage needs a coach

A team that can self manage just needs a coach for the personal team members, to grow them, to teach them new skills. They need someone to keep an open eye for interesting things that they may not have noticed, and they can use (not need!) a second look every once in a while if they are facing interesting dilemmas.

« Leadership and the mature team | Main | The Bus Factor - Why your ‘best’ developer is your biggest problem »

Reader Comments (7)

I wrote about this some time ago

I do think that scrum helps for this. Scrum helps for the first phase as it is this framework that gives the hard guiding that you want.
In a forming phase (chaos as you call it) it's good to have a scrum master that is very strict on the scrum process, that will help a team to give guidance.


May 18, 2010 | Unregistered CommenterYvesHanoulle

Hi Roy
It is usually thought that teams go through 4 stages forming, storming, norming and performing and the management style should adjust to the different stages.
Naturally SCRUM is a better fit for the later stages rather than the initial ones but I think that most of the practices should be there from the beginning so that the people would get used to them. for example, a lot of times when I talked to teams about estimation in points I got odd looks and people "secretly" converting days to points etc. - It takes time to make these transitions as well


May 18, 2010 | Unregistered CommenterArnon Rotem-Gal-Oz

Found this post really enlightening, it articulated something that has been knocking about in my head for a while.
I find myself saying "works really well in this environment" on client sites many times when referring to just this. It also explains why some coaches work really well in some environments and not others. As an agile coach you need to assume different behaviour in different environments to be effective.

May 21, 2010 | Unregistered CommenterPaul Velonis

I vote for "Redicreting a Team" or "Team Regroupiong". And a spell checker.

May 22, 2010 | Unregistered CommenterProf

'Redicreting' is a well-known motivational technique, often used by the mafia, and refers to the quick-setting conrete of the same name; 'Team Regroupiong' is a Korean software enginerring practise.

May 26, 2010 | Unregistered CommenterAnon.

Anon: LOL. I won't fix the typos just so your comment stays relevant :)

May 26, 2010 | Unregistered CommenterRoy Osherove

Nice post. I think dictatorship is relevant, but perhaps at one end of a spectrum?? At the other extreme we have completely passive adoption - laissez faire, but with fostering of team learning and a focus on continuous improvement. Just as laissez faire might not gain traction in some teams, in some cases dictatorship might also provoke revolt! Perhaps the better the team, the more easily it can gravitate towards the optimum part of the curve.

As a bit of a tangent, do you know of anywhere that technical adoption is driven by incentive? By that I mean, take the x% yearly bonus component of our salary and align it with how well we meet the 'definition of done'? So for the set of features shipped, the bonus could be

Bonus = k x SUM(Feature business value x Quality Factor)

In other words, reward the team for total business value shipped, but weight this with an aggressive quality factor. No tests? Lose 50%! Tech debt / needs further refactoring? Lose 50%... and so on. Code review would take on a new meaning ; )

Broke the build? Give me $5!

April 4, 2011 | Unregistered CommenterKen McCormack

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>