Tuckman model of team development

I was once called in to help a team, six months into a three month project. Yes, you read that correctly. It was supposed to be a three month project and after six months they had lots of code but nothing that actually worked, and no end in sight.

While there were certainly many problems in this situation, the largest by far was that this team had never left the storming phase, as described in the Tuckman Model (below).

Six months after starting, they still couldn’t work together. There was almost constant conflict and this affected everything they did. Two members of the “team” wouldn’t even work on the same floor as the the other people.

As individuals, each was a decent person who wanted to do good work. As a “team” however, they just couldn’t function together and it was constant conflict.

This could have been resolved fairly easily, had it been done early enough. By the time they’d lived through six months of this, the trauma was deep, and the damage had already been done.

Storming is a normal part of the team development, but in a healthy team they’ll move through this stage relatively quickly and will start to become productive.

Let’s look at the whole model. There are five stages and we’ll walk through each one.

Stage	Description
Forming	Coming together for the first time
Storming	Working through our differences and establishing boundaries and working agreements
Norming	Settling into patterns and starting to become productive
Performing	Achieving high productivity
Adjourning	Disbanding the team

The first four were proposed by Dr Bruce Tuckman in a paper¹ he wrote in 1965. Twelve years later, he added the fifth stage to capture what happens as a team disbands. Within an agile context, we tend to only talk about the original four as our goal is to build effective teams, not to disband them.

While these are written as if it were a sequence that we have to pass through linearly, teams are not guaranteed to pass out of one phase to the next and sometimes they will fall backwards after making some progress.

Forming is when we come together initially. At the beginning, everyone tends to be on their best behaviour and at their most open to compromise. We don’t tend to stay long in the forming stage.

Soon enough though, the feeling that we’re going to be working together for a while sinks in and everyone starts to establish their own boundaries. This is where we enter the storming phase, and we start to advocate for all of those things that are important to us.

• “The code should be written in this way.”
• “I want to do this part.”
• “I hate doing this thing.”

At the beginning, this is usually fairly civil although if it goes on for too long, it can become heated and as with the example at the top, sometimes we just don’t leave this stage.

This is always our least productive stage in the whole model and so we want to get out of it quickly. Good facilitation can really help here.

While some teams will figure out how to get through storming on their own, others will struggle and require assistance.

Norming is when we settle into some agreed patterns and we start to see productivity climb.

Performing is when we start to reach a level of team productivity that exceeds what the individuals could have done on their own. We’re now starting to truly collaborate and get the benefits of that collaboration.

Teams that remain siloed and choose not to actively collaborate, will rarely achieve the level of performing.

Adjourning is that point where the team is being taken apart. Unfortunately teams in most corporate environments do get pulled apart earlier than they should. If we have a performing team, we should keep them together and just pass more work to them.

A couple of parting thoughts:

1. At any point throughout this, if we add or remove team members, we throw everyone back into first forming and then storming again. It’s a common pattern for management to want to pull people off a team that has become successful so that they can replicate that success elsewhere and yet counter-intuitively, that throws both teams back into storming and loses any productivity gain we might have had.
2. We can’t just assume that any given team will progress through storming, onto forming, and then performing. Some teams will do that on their own but many won’t. We need to be explicit about working together and starting to collaborate.
3. I find that when I do explicit ensemble work (also called mob programming) with a team, we’re able to get through forming and storming in a day or two. The way I facilitate it, we tend to have people in heavy storming on the first day; talking over each other and disagreeing on many things. By the second day, they’re beginning to already settle into the patterns of norming and if they continue to do ensemble work daily, it isn’t long before they start to enter performing.