Tuckman was Wrong

Tuckman's Theory

Tuckman's Theory of Group Development was first published by Bruce Tuckman in 1965. In Tuckman's original explanation, groups and teams go through four stages as they become a cohesive, high-performing unit; Forming, Storming, Norming, and Performing.

Forming - When a team first forms, members are often cordial with one another. People are getting to know one another and are on their "best" behavior. Productivity is reasonable, but not impressive. This is usually a stage of average performance.

Storming - As a team moves into storming, subtle differences in people's perceptions and expectations lead to opinions about the character and integrity of other team members. Annoyances as a result of unresolved differences in expectations become impediments as members start to clash with one another. Productivity is seriously low and the team is at risk of disbanding.

Norming - If and when a spirit of cooperation emerges, the team moves into norming. Here, differences are discussed and resolved through creation of new shared norms. The team starts to come together as a cohesive unit and productivity increases with each new improvement.

Performing - The team now has a shared set of norms and has learned how to work well together, capitalizing on individual strengths. Productivity is high.

Tuckman's Stages and Productivity

Tuckman's Stages and Productivity

According to Tuckman's Theory, all teams pass through these stages in this order. It is possible to regress say from Performing to Storming or from Norming to Storming, but if a team does regress, then they must pass once again through the stages in order. A team that was Performing, but has a significant change whereby many members leave or are replaced, might regress all the way to Forming and would need to pass once again through Storming and Norming to get back to Performing.

Stable Teams. Because Tuckman's.

Within the agile community especially, this has become common knowledge. We've long talked about the need to keep teams stable in order to get to and maintain high performance. If we keep changing up the teams, they are forced to regress to Storming and will need to recover with productivity taking a critical hit while the team passes through the stages back to Performing.

We can see that stable teams is a boon for many an organization which previously assembled and disassembled teams on a regular basis or companies that moved resources around based on ever shifting priorities.

Clearly, Tuckman was right.

Except Tuckman was Wrong

Yes. Tuckman was wrong.

Tuckman's theory was based on a small number of personal narratives where people were asked to share their experiences forming teams. Based on these limited anecdotes, Tuckman formulated the theory of four mandatory sequential stages that are universally applicable to all team formation.

In the over 50 years since the theory was published, there have been dozens of scientific studies run in efforts to prove or even extend upon Tuckman's Theory. All instances of a scientifically executed peer reviewed study failed to prove Tuckman's Theory and several of them conclusively disproved it.

If you're a Tuckmanite, right now you're probably searching your mental reserves for a way to accept this new information AND hold onto your belief that Tuckman's is correct or at least correct enough to still be useful. That's cool. Rationalization is one of our brain's defense mechanisms for when our truth comes into question. I certainly had a moment of rationalization when I stumbled across the first set of studies, but I decided maybe I should keep digging.

The Science

Of all the studies done over the past 50+ years, one in particular stands out for me. The US Military ran an extensive study of team formation across a large population for an extended period of time seeking to better map out Tuckman's Theory and when/how teams moved through the various stages. What they discovered was quite intriguing.

Extremely few teams had an experience that mapped to Tuckman's stages. Many teams skipped stages entirely or even passed through stages in a different sequence. Almost universally, they found it was difficult to say for sure that a team was squarely in a specific stage, rather the activities and behavior associated with a particular stage were more or less pronounced. It was hard to say any of the stages Tuckman identified were in fact stages at all. Storming, they concluded, is not a stage at all, but a consistent occurrence. And this for me, was key.

Storming is not a stage, but a consistent occurrence.
Tuckman's "Stages" as they actually occur

Tuckman's "Stages" as they actually occur

Our conclusion that teams need to be kept stable is based on the premise that when teams change, they regress into storming. We now know that teams cannot regress into stroming as it is always happening. Therefore, the argument is not valid.

Now let's be careful here. I am not saying that stable teams aren't beneficial. We've clearly seen cases where making teams stable improves performance. What I'm saying is that using Tuckman's as an argument for keeping teams stable is invalid because Tuckman's Theory is wrong.

So why stable teams?

I think stable teams help in a lot of environments because it reduces the waste generated by many companies who try to fully utilize their resources. In many companies, people report into functional units and their time is apportioned out to multiple projects in an effort to get as many things done as possible. This often results in people's time being more than 100% allocated across multiple projects. Our ability to get work done diminishes almost exponentially once we are over 80% allocated and for every project over one that we are assigned, we lose 20% of our time to context switching.

When we move people from functional units to whole teams and we make the teams stable, we're causing a drastic reduction in time lost to context switch and we're moving allocation toward healthier levels. Performance will go up even if the team doesn't sit together or communicate with one another very often.

Stable teams creates a constraint that limits the bad behavior of over allocation and multiple assignments. If we don't have this bad behavior, we don't need the constraint of stable teams.

Fluidity is Powerful

These days, more and more organizations are moving away from the model of stable teams. They're mature enough to know better than to manage from the top in a complex environment. They don't utilize people's time at 100% and they manage their work in progress at all levels; enterprise, division, department, product, and team.

These companies are discovering that allowing people the autonomy to move from assignment to assignment and from team to team, is not only increasing productivity, it is accelerating learning, and improving retention.

If you find that stable teams are better in your environment, step back and take a look at how you on-board, share knowledge, and establish standards. Consider if and how you truly foster Autonomy, Connection, Excellence, and Diversity. And start running small experiments around swapping team members or putting people on rotations. See what happens. You're likely to be surprised.