Tuckman Model of Group Development

The Model Everyone Learns First

If you’ve taken any kind of team leadership course, management seminar, or agile coaching certification in the last forty years, you’ve seen this model. Forming, storming, norming, performing. Four words, arranged in a sequence so tidy it practically begs to be printed on a coffee mug.

Bruce Tuckman published “Developmental Sequence in Small Groups” in 1965 while working at the Naval Medical Research Institute in Bethesda, Maryland. He reviewed fifty existing studies on group development - therapy groups, training groups, natural groups, laboratory groups - and synthesized their findings into a single four-stage model. The result was so intuitive that it became the default mental model for team development across disciplines, from organizational psychology to software engineering.

Here’s the thing about Tuckman: the model is genuinely useful as a normalizer. When a team is in the middle of conflict and people are wondering whether something is broken, knowing that storming is a predictable and necessary stage can be the difference between panic and patience. That alone earns it a permanent spot in the coaching toolkit.

But I’ll be honest with you - and this will come up again later - I think there are better tools for actually coaching teams through these stages. The Tuckman model tells you the weather exists. Other models hand you the umbrella. More on that shortly.

Twenty years after the original paper, Tuckman and doctoral student Mary Ann Jensen revisited the research and added a fifth stage - adjourning - to account for what happens when a team’s work is done and the group dissolves. Some people call this stage “mourning,” which tells you everything about how it feels when a high-performing team breaks apart.

The Five Stages (and What Actually Happens in Each)

The model describes a developmental sequence. Teams don’t skip stages, though they can regress to earlier ones when conditions change. A new team member joins, a critical deadline shifts, a reorg scrambles the reporting structure - and a performing team can find itself back in storming before anyone quite realizes what happened.

Forming

Forming is the polite stage. Everyone is on their best behavior. People are figuring out who the other humans are, what the goals might be, and whether this group is going to be a reasonable place to spend their working hours.

There’s a lot of looking to the leader (or the Scrum Master, or whoever seems to be in charge) for direction. Questions are cautious. Disagreements are rare - not because everyone agrees, but because nobody wants to be the first one to rock the boat.

Productivity is low, but that’s not a failure. It’s the cost of orientation. The team is mapping the social landscape - who knows what, who cares about what, who tends to dominate, who tends to withdraw. This mapping is necessary work even though it doesn’t show up on a burndown chart.

The coaching move here is to provide structure and clarity. Clear goals. Defined roles (even if they’ll shift later). Explicit working agreements. The team doesn’t need autonomy yet - they need enough safety to start being honest with each other. That honesty is what opens the door to the next stage.

Storming

Storming is where it gets real. The politeness evaporates. People start pushing back on ideas, challenging the leader, competing for influence, and expressing frustration when their expectations don’t match reality.

This is the stage that scares new Scrum Masters. A team that seemed perfectly fine two weeks ago is now arguing in refinement, going silent in standups, and sending passive-aggressive messages in Slack. The natural instinct is to fix it - to smooth things over, to mediate every conflict, to restore the harmony of forming.

Resist that instinct.

Storming is not a problem to solve. It’s a developmental stage to move through. The conflict, uncomfortable as it is, serves a purpose. It’s how team members negotiate real expectations, establish authentic roles (as opposed to the polite placeholders from forming), and surface the tensions that would poison the team later if left underground.

Not every team storms with the same intensity. Some teams barely ripple. Others go through weeks of genuine friction. The intensity depends on personality mix, organizational culture, the stakes of the work, and whether the team has psychological safety or is performing conflict theater - fighting about technical details because the real issues feel too dangerous to name.

(That last one is more common than most people think.)

The coaching move during storming is to normalize it, name it, and facilitate through it rather than around it. Acknowledge that disagreement is healthy. Help the team develop conflict resolution habits. Watch for the difference between productive tension - where people are wrestling with ideas - and destructive patterns where people are attacking each other. The first one you encourage. The second one you interrupt.

Norming

If the team makes it through storming (and most do, given reasonable conditions), norming is the payoff. The team starts establishing shared expectations, communication norms, and working rhythms that actually reflect who they are - not who they were pretending to be in forming.

This is where working agreements start to mean something. In forming, a working agreement is aspirational. In norming, it’s descriptive. “We don’t interrupt each other in refinement” shifts from a rule people are trying to follow to a behavior people actually practice.

Trust increases. People start asking for help without feeling like it signals incompetence. Feedback becomes more direct and less defensive. The team develops inside jokes - which is a weirdly reliable indicator that norming is taking hold.

Roles crystallize, but not rigidly. The team figures out that Nina is the one who catches edge cases in refinement, that Jorge’s instinct about architecture is usually right, that Lisa asks the hard questions nobody else wants to ask. These aren’t assigned roles - they’re emergent ones.

The coaching move in norming is to get out of the way - mostly. Reinforce the healthy patterns you see forming. Help the team articulate the norms they’re already living so they become conscious and durable rather than accidental and fragile. But don’t over-manage. The team is finding its own shape, and that process works better when the coach provides scaffolding, not architecture.

Performing

Performing is the stage every team aspires to and not every team reaches. The team operates with high autonomy, high trust, and a shared sense of purpose. Members focus on the work rather than on interpersonal dynamics. The team self-organizes around challenges without needing someone to assign tasks or mediate conflicts.

This is the team that makes Scrum look easy. Standups are crisp. Retros generate genuine insights. Sprint goals get met. Management stops micromanaging because the results speak for themselves.

It’s worth noting what performing is not. It’s not the absence of conflict - high-performing teams still disagree, they just handle it constructively and fast. It’s not permanent either. Significant change can push a performing team back to storming. That’s normal, not failure.

The coaching move in performing is to protect the team’s environment. Shield them from unnecessary organizational noise. Challenge them with stretch goals that keep them growing rather than coasting. Resist the temptation to declare victory and move your attention elsewhere - performing teams still benefit from a coach, just in a lighter-touch way.

Adjourning

Tuckman and Jensen added adjourning in 1977, and it matters more than most summaries suggest. Teams end. Projects ship. People get reassigned, promoted, or move on. The bonds that made performing possible don’t just evaporate - they need closure.

In agile contexts, adjourning happens frequently. Teams get reorganized. A product reaches end-of-life. A contractor’s engagement ends. A reorg creates new teams from the fragments of old ones.

The coaching move is to make adjourning conscious. A final retrospective that celebrates what worked and names what was learned. This isn’t soft-skills theater - teams that adjourn well carry their lessons into the next team. Teams that just dissolve without reflection lose those lessons.

(The people who call this stage “mourning” aren’t being dramatic. When a genuinely high-performing team breaks apart, the grief is real. I’ve watched senior engineers tear up in a final retro. Respect that.)

The Model’s Strengths - and Its Honest Limitations

Tuckman’s model endures for good reasons. It’s memorable. It’s intuitive. It maps to what people actually observe in teams. When you tell a Scrum Master who’s watching their team fall apart that storming is a normal and necessary stage, you can see the relief in their face. The descriptive power of the model is real.

It’s also a useful normalizer for the team itself. When a team understands that the conflict they’re experiencing has a name and a place in a predictable sequence, it reframes the situation from “we’re dysfunctional” to “we’re developing.” That cognitive shift matters.

Where It Falls Short

Here’s where I give you my honest take, and it’s one I share in every A-CSM class I teach.

Tuckman tells you that stages exist. It describes what they look like. But it gives you very little guidance on what to actually do as a coach to help the team move through them. “You’re in storming” is useful information. “Here are the specific activities that help a team navigate storming” is more useful. Tuckman gives you the first. It doesn’t really give you the second.

This is why I consistently point people toward the Drexler-Sibbet Team Performance Model as a more actionable coaching tool. Drexler-Sibbet describes seven stages of team development (Orientation, Trust Building, Goal Clarification, Commitment, Implementation, High Performance, and Renewal) and - this is the key difference - provides specific facilitation activities and diagnostic questions for each stage. It tells you not just where the team is, but what to do about it.

If Tuckman is the weather report (“it’s going to storm”), Drexler-Sibbet is the storm preparation guide (“board the windows, stock the supplies, here’s where the shelter is”). Both are valuable. But when I’m standing in front of a room of coaches, I want to hand them the tool that helps them take action, not just name the condition.

None of this means Tuckman is wrong or useless. It means it’s foundational rather than sufficient. Learn it. Know it. Use it as shared vocabulary. And then add more detailed models to your toolkit for the hands-on coaching work.

The Linearity Problem

The other criticism worth addressing is the implied linearity. The model presents stages in a sequence - forming through performing - which can create the impression that team development is a one-way journey. Real teams are messier than that.

A team that’s been performing for six months gets a new product owner and slides back to norming as the group renegotiates dynamics. A team that seemed to skip storming entirely might hit a delayed storm when the first real disagreement surfaces three months in. A reorg can reset a team to forming overnight.

Tuckman himself acknowledged this. The model describes a general developmental pattern, not a deterministic pipeline. Coaches should hold it loosely enough to recognize that real team development involves loops, setbacks, and the occasional unexpected detour.

Still Earns Its Place

Despite these limitations, Tuckman remains in my coaching deck for one simple reason: it works as a shared language. When a Scrum Master says “we’re storming,” everyone in the conversation knows what that means without further explanation. That kind of shorthand is valuable.

It’s also the right model to reach for when you need to quickly normalize team conflict for a group that’s never thought about team development stages before. Not everyone needs the depth of Drexler-Sibbet on day one. Sometimes the most helpful thing you can say is: “This is storming. It’s normal. Let’s talk about what comes next.”

What This Changes About Your Coaching

Reading the Room

The most immediate application of Tuckman is diagnostic. When you walk into a team’s standup or refinement, ask yourself: what stage is this team in?

Forming looks like people reading from scripts - careful language, deference to the lead, nobody pushing back. Storming looks like people who’ve stopped being polite - cross-talk, side conversations after standups, tension when someone says “that’s not how we should be doing this.” Norming looks like shorthand, laughter, efficient meetings where disagreement doesn’t derail. Performing looks like a team that’s stopped thinking about process and started thinking about outcomes.

Once you can read the stage, you can calibrate your coaching. You don’t challenge a forming team the way you challenge a performing one. The model adjusts your approach, even if it doesn’t specify the exact activities.

Protecting Storming

This is the coaching move that separates experienced coaches from new ones. New coaches try to prevent or shortcut storming. Experienced coaches protect it.

If a manager watches a team argue in a retro and says “I need you to get them aligned,” the instinct is to smooth things over. An experienced coach says: “They are getting aligned. This is what alignment looks like before it’s done.”

Storming is the forge. The team that doesn’t storm doesn’t build the trust muscles it needs for performing. They stay in a permanently polite forming state - functional, but never high-performing.

The coach’s job isn’t to prevent conflict. It’s to make conflict safe, productive, and time-bounded. Set ground rules. Facilitate difficult conversations. Intervene when things turn personal. But let the team do the hard work of figuring out how to disagree well.

New Member Resets

When a new person joins a performing team, the team doesn’t stay in performing. It resets - usually to somewhere between forming and norming, depending on the team’s maturity and the new member’s role.

Name it in advance. Before the new person starts, tell the team: “We’re going to re-form a bit. We’ll need to renegotiate some norms. That’s normal and temporary.” Teams that don’t get this framing tend to blame the new person for “breaking” the dynamic. The new person senses the blame and withdraws. A predictable cycle becomes a destructive one - all because nobody named the stage transition.

Sprint Zero as Intentional Forming

In agile contexts, the concept of Sprint Zero (or an inception sprint, or whatever your organization calls it) maps directly to intentional forming. Instead of letting the team stumble through orientation accidentally, you design activities that accelerate it.

Team chartering. Working agreements. Skills matrices. Social contracts. “How we want to work together” conversations. All of these are forming-stage activities that, when done deliberately, compress the time the team spends in the ambiguity of early forming and accelerate their path toward productive storming.

(Note: I said “toward productive storming,” not “past storming.” You can’t skip it. You can only make the entry smoother.)

What It Looks Like in the Room

Keiko had been coaching agile teams for about five years, mostly at mid-sized fintech companies where teams formed fast and shipped faster. When she moved to a healthcare technology firm, the pace was different - more regulatory oversight, longer planning horizons, more stakeholders with conflicting priorities.

Her first assignment was a newly formed team building a clinical data integration platform. Eight people pulled from three different departments. Two had been at the company for a decade. Three were recent hires. One was a contractor with deep domain expertise who made it clear on day one that he’d be gone in six months.

The first two weeks were textbook forming. Everyone was pleasant. Standups were efficient but hollow - status updates recited from Jira tickets, no real conversation. Refinement sessions were quiet. People nodded at estimates without challenging them. Keiko noticed that the most experienced engineer, Dev, would occasionally start to say something and then stop himself.

In week three, the Product Owner - a sharp, fast-talking former clinician named Reena - brought stories to refinement that required integrating with a legacy system nobody had touched. Dev finally didn’t stop himself. He said the proposed approach wouldn’t work, that the legacy system had undocumented behaviors that would break the integration, and that the team was being set up to fail.

The room went quiet.

Derek, one of the recent hires, pushed back. He’d done similar integrations at his previous company and thought Dev was being overly cautious. The contractor, Jay, sided with Dev but for different reasons - he’d seen the legacy system’s documentation and called it “optimistic at best.” Reena felt caught between timelines from leadership and technical concerns she couldn’t fully evaluate.

The next three standups were tense. People were short with each other. Derek and Dev barely spoke outside of meetings. Jay started working from home more often (which, given that he was already remote three days a week, meant he essentially disappeared). Two people separately messaged Keiko asking if the team was going to be okay.

Keiko recognized storming. She’d seen it dozens of times. But she also noticed something specific: the conflict wasn’t about egos or personalities. It was about genuinely different assessments of technical risk, informed by genuinely different experiences. This was the productive kind.

She asked for thirty minutes in the next retro. She put the Tuckman stages on the screen and asked the team to guess where they were. Every single person said “storming.” That got a laugh - the first one in a week.

Then she asked a follow-up: “What would it take to move to norming?” The answers came fast. Dev wanted a spike to investigate the legacy system before committing to an approach. Derek wanted the team to evaluate his integration pattern rather than dismiss it. Jay wanted clearer expectations about when he needed to be available for synchronous work. Reena wanted a way to communicate realistic timelines to leadership without it sounding like the team was already behind.

None of these were unreasonable. All of them had been sitting unspoken under the surface tension.

Over the next sprint, the team ran Dev’s spike. It confirmed some of his concerns and disproved others. Derek’s integration pattern turned out to work for two of the three data sources - a partial win that both he and Dev could build on. Jay proposed a communication protocol for synchronous availability. Reena drafted a stakeholder update that framed the spike as risk reduction rather than delay.

By sprint four, the team had developed a rhythm. Refinement got louder - in a good way. Dev and Derek started pair-programming on the integration work, combining institutional knowledge with fresh perspective. Jay, who’d initially seemed disengaged, turned out to be the team’s best documentation writer - he just needed to know the team valued that contribution.

At the end of the quarter, Keiko ran a team health check. When she got to the question about psychological safety, Reena said something that stuck: “We’re not polite anymore. We’re honest. That’s better.”

Keiko knew the team would cycle again. Jay’s contract would end in three months, and they’d need to re-form around whoever replaced him - or absorb his responsibilities. A performing team today could be a forming team tomorrow. But that’s not a problem when the team understands the cycle. It’s just the next iteration.

That’s the fundamental gift of the Tuckman model. It doesn’t make team development painless. It makes it legible. And a team that can read its own development - that can say “we’re storming right now, and here’s how we move forward” - is a team that’s already halfway to performing.

Go Deeper

• Tuckman, B.W. (1965). “Developmental Sequence in Small Groups.” Psychological Bulletin, 63(6), 384-399. The original paper. Tuckman’s synthesis of fifty group development studies into the four-stage model. Surprisingly readable for a 1960s academic paper.

• Tuckman, B.W. & Jensen, M.A.C. (1977). “Stages of Small-Group Development Revisited.” Group & Organization Studies, 2(4), 419-427. The follow-up that added adjourning as the fifth stage, based on a review of studies published after the original 1965 paper.

• Wheelan, S.A. (2009). “Group Size, Group Development, and Group Productivity.” Small Group Research, 40(2), 247-262. Empirical research on how group size affects developmental stages - useful context for coaches working with teams of different sizes.

• Drexler, A.B., Sibbet, D., & Forrester, R.H. (1988). “The Team Performance Model.” In Team Building: Blueprints for Productivity and Satisfaction. The Drexler-Sibbet model I keep recommending. Seven stages with specific diagnostic questions and facilitation activities for each. If you want the actionable companion to Tuckman, start here.

• Lencioni, P. (2002). The Five Dysfunctions of a Team. Not a direct extension of Tuckman, but a complementary model that diagnoses why teams get stuck - particularly relevant when a team seems trapped in storming. See also the Five Dysfunctions card in this deck.