The Elastic Leadership Book



        RSS Feed

Latest Entries

First time here?


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.


The Bus Factor - Why your ‘best’ developer is your biggest problem

From wikipedia, a “Bus Factor” is:

an irreverent measurement of concentration of information in a single person, or very few people. The bus factor is the total number of key developers who would need to be incapacitated, as by getting hit by a bus, to send the project into such disarray that it would not be able to proceed


From my personal experience, I'd say that more than 70% of projects suffer from a bus factor of 1. It only takes one specific person in those teams to not be able to be there for the project to halt or slowly die in painful agony as people try to makeup for lost knowledge.

How do you recognize the bus factor?

in your mind, go through each person in your team and ask yourself if

the project could go on pretty much as usual if they were fired tomorrow. (fired is important because people who leave in good terms can still play ball and get you through tough stuff they worked on through phone conversations).

If you say “no” or even hesitate about the answer, you’ve found the bus factor in your team.

How do you get rid of the bus factor?

Most of the collaboration techniques you’ll find in many agile methodologies like XP try to solve the idea of the bus factor, but you don’t have to be agile to use those techniques.


  • Use daily standups to share critical information
  • program in pairs every once in a while, or at least on key components of the system
  • do code reviews on every piece of code that gets checked in
  • do weekly half hour or one hour presentations by team members about interesting stuff they did this week
  • Ask the bus factor carrier to teach someone else from the team to do their work and vice versa. Tell them that next week they will be working alone on that material so they should get ready for that by working together on it.

The biggest bus factor is you

As a team leader, you might just be the biggest bus factor carrier of them all. What happens if you get fired tomorrow? can the team go on without you?

Your biggest challenge as a team lead, over a long period of time would be to make yourself dispensable – to make the team mature enough to continue on day to day things without needing you. Removing yourself as a bottleneck is one of the best things you can do for yourself and your team.


My team keeps breaking their promises. What can I do?

Execution – actually having the team get things done– requires people to :

  1. Say what they will do 
  2. Mean it (be committed)
  3. Do it

Everyone likes to do #1. Only some do #2. Great teams also do #3.

This post is about #2.

There is a vast difference between people being committed to something, and people saying something.

For example, you can start looking for words that are not committing to execution:

  • I’ll try to get that to you by Monday”
  • “Someone should get that thing fixed”
  • “I hope to get to that later”
  • “I think I can make it”

spot these things and see if you can ask people to actually commit to the thing they need to do:

  • “I will do this by Monday”
  • “I commit to getting this done by Monday”
  • “It will be done by Monday”

If someone can’t commit to that – that’s good. Maybe they are not sure they can – maybe there is something stopping them. But you won’t know until you can either get them to commit, or get them to say why they cannot commit to it.

Also notice how there is a specific end date. Committing to something with an end date make things more real, and also prevents whoever is depending on that thing from bothering the doer. “Is it done yet?” “How about now?” .

No need to ask. They committed to do this by Monday.

Don’t under estimate peer pressure.

Doing all this talking in an open daily standup makes the commitment more important. it’s not just you and someone else. now it’s you telling the whole team you will get something.

If your team members don’t know how to verbally commit to something, you can teach them. You can actually ask them to say things differently:

“Can you say you will do it by date so and so? Is that something you can commit to? Why not? “

I can’t commit to something I don’t have control over

Of course, the biggest hurdle is that sometimes people really can’t commit to something if they don’t have full control of it. Expecting people to commit to something that depends on other people is less realistic.

If that happens, see what things that person can have control over. For example, if the task is about getting a bug fix to a client and making sure it’s closed by Monday – the dev might have control over actually sending the email to the client, but they have little control over when the client responds back. In such a case they can commit to sending the fix to the client .

Failing commitments

There should be no such thing is a failed commitments. the moment one sees that they will not make the deadline, they should notify whoever they committed to, that they will no make it in time – this allows the team to see if something can be done to maybe still get that thing in time by reorganizing or changing priorities.

A failed commitment means you won’t live up to what you promised and you didn’t notify anyone beforehand that you will not make it in time. that is something that is fully under your control and should not happen.


Kevlin Henney – 3 things every programmer should know

During the ACCU 2010 conference in London, I got to get on audio, several of the interesting people who attended and spoke at the conference.

One of them was Kevlin Henney. I first got to see him speaking during NDC 2009 in Norway. He was fascinating in the way he approached sophisticated architecture topics, and his lively and funny way of making everything more understandable.

Kevlin is also the main character behind the book 97 things every developer should know and several other books.

In this 20 minute audio mp3, we start off with a simple question: what are the three things every programmer should know? (you can watch Kevlin on this years NDC in Norway as well. I highly recommend it! (he’s also on twitter)

Download the mp3 – 20 min.


Interview: Patrick Kua : Agile Coach

This time, I talk with Patrick Kua, an Agile Coach living in the UK, about various subjects. Among them – the various types of tests, what is “Done”?, The difference between Team Leader and Team Manager and more.

Download mp3 – 29 minutes.