Stages of team developmentsigns, questions, and next steps for each stage

The five stages of team development are Forming, Storming, Norming, Performing, and Adjourning. The model gives teams shared language. Teams can combine stages or revisit earlier ones.

In 1965, Bruce Tuckman proposed the four stages that shaped the original model. Jensen and Tuckman added Adjourning in 1977. Their model grew from a review of earlier small-group studies, decades before today's product, engineering, hybrid, and cross-functional teams.

How useful is the Tuckman model today?

The model works best as a conversation starter. Treating it as a maturity score gives the labels authority beyond the research. Use them to name what the team needs from its work right now: clarity, open disagreement, shared expectations, autonomy, or closure.

Later research paints a messier picture. Connie Gersick's study of project teams found that deadlines and project midpoints often triggered major changes. A 2018 review describes teamwork as situation-dependent. The 2026 review of 110 articles and 116 studies connects team development to membership, leadership, team dynamics, and results, which supports watching team changes over time.

Start with a stage as a working guess. Check that guess against the team's recent choices, handoffs, and conversations. Smooth collaboration in one area can sit beside muddled decisions in another, and a new member, deadline, reorganization, or goal can change the pattern quickly.

1. Forming: clarify the work and how people can contribute

In Forming, people are figuring out why the team exists, who decides what, and how candid they can be. Meetings can feel polite and cautious. Many questions still go to the leader because ownership and working relationships remain hazy.

What the facilitator can do: explain what the team owns, how decisions will be made, and where people can ask for help. Make room for basic questions. A new team needs the rules before it can organize its work around them.

Retrospective questions for Forming

• What do we need to understand to do this work well together?
• Where is decision authority unclear?
• What would make it easier to ask for help this week?

Try this retrospective: run a simple Classic Sprint retrospective or follow the first retrospective guide. Agree on one way of working first. The rest of the team process can take shape over the next few retrospectives as people gain context and see where coordination still catches.

2. Storming: make disagreement useful

Storming describes the point when real differences become visible. People may disagree about priorities, quality, pace, roles, or influence. Some teams argue openly. Others get stuck in repeated handoff problems, side conversations, silence, or decisions that keep reopening.

What the facilitator can do: bring the conversation back to a recent example and ask what happened. Invite quieter voices and examine the assumptions behind each view. Handle conduct concerns separately. Give useful disagreement enough time before the team settles on an agreement.

Retrospective questions for Storming

• Where did different assumptions shape a decision or handoff this week?
• Which handoff keeps causing friction?
• What do we need to disagree about more directly and safely?

Try this retrospective: use a Safety Check retrospective when people are holding back, or Mad Sad Glad when the team needs a simple way to talk about how recent work affected them.

3. Norming: agree on habits that help

In Norming, teammates start coordinating directly and routines become more predictable. People know how work usually moves and can recover from small mistakes while taking fewer questions to the leader.

What the facilitator can do: name the habits that help and ask how they work for quieter or newer members. Agree when an exception makes sense. Fewer arguments can hide weak alignment, so keep testing routines as the work changes.

Retrospective questions for Norming

• Which new habit is making collaboration easier for the team?
• Which agreement is fuzzy?
• What should we standardize, and where do we need flexibility?

Try this retrospective: use Start Stop Continue to choose one practice to add, one to stop, and one to keep.

4. Performing: protect strengths and keep learning

A team in Performing can shift ownership, disagree constructively, and make progress with little direction from a manager. The work still takes effort. The team needs time to spot risks and learn from whatever is changing.

What the facilitator can do: ask about workload, knowledge held by too few people, and risks that disappear behind strong delivery. Protect the team's autonomy, then invite harder questions about the work. Success can mask fragility.

Retrospective questions for Performing

• Which capability lets us respond quickly while keeping quality high?
• Where is success hiding fragility?
• What small experiment could improve the system while protecting a strength?

Try this retrospective: choose a Starfish retrospective to fine-tune how the team works, or a 4Ls retrospective to capture learning the team can use again.

5. Adjourning: close well and hand over what matters

Adjourning begins when a project ends, a temporary team disbands, or membership changes enough to close the current chapter. People may feel proud, relieved, uncertain, or disappointed. At the same time, useful context can easily disappear.

What the facilitator can do: recognize people's contributions, capture what the team learned, and give unfinished work a clear owner. Store important context where the next team can find it. A farewell covers recognition, while clear ownership keeps the work moving after the group disbands.

Retrospective questions for Adjourning

• What learning must survive?
• Which unfinished decision, risk, or relationship needs a continuing owner?
• What contribution or turning point should we recognize?

Try this retrospective: use Mountain Climber to look back on the journey, then follow the project retrospective guide to hand over actions and knowledge.

Example: how an engineering team moves between stages

1. Forming: a newly assembled product squad clarifies its goal, decision owners, and release boundary.
2. Storming: design and engineering disagree about when discovery is complete, which sends work back to refinement several times before the team names the gap.
3. Norming: the team tests a shared readiness check and a weekly design-engineering review for risky work.
4. Performing: teammates adjust ownership around bottlenecks and improve the check based on what they learn.
5. Forming again: a new product area and two new members make the old ownership map obsolete, so the team renews its context and working agreements.
6. Adjourning: after launch, the temporary squad transfers support ownership, records the key decisions, and recognizes the work before disbanding.

The model helps this team choose its next conversation. A stage describes the team's current need, while progress can shift again as the work changes.

Limits of the five-stage model

• Teams follow different sequences. A team may skip a clear Storming period, develop useful habits while conflict continues, or change suddenly near a deadline.
• The same behavior can mean different things. Silence may come from early uncertainty, unresolved conflict, low trust, disengagement, or a team that simply prefers focused discussion.
• Outside conditions matter. Leadership changes, incentives, dependencies, workload, reorganizations, and new members can change how people work together.
• Good performance can hide problems. Strong delivery in one area can sit alongside overload, fragile knowledge, or poor decisions elsewhere.

Use a stage label to frame your questions, then check it against evidence from the team.

Check the stage against the team's context

Use three checks:

1. What seems to be missing? Does the team need clarity, a more open disagreement, stronger working agreements, more autonomy, or a proper ending?
2. What changed recently? Think about deadlines, new members, reorganizations, leadership changes, and new goals.
3. What can you point to? Bring examples from decisions, handoffs, meetings, workload, requests for help, and the way the team responds to mistakes.

When the need, context, and examples line up, try a small change in the next retrospective. If they conflict, ask the team where your read drifted.

Use the model while leaving labels off the team

1. Choose a recent event or period and leave the team's whole history out of the judgment.
2. Bring two or three examples from decisions, handoffs, participation, ownership, or mistakes.
3. Ask what the examples share.
4. Choose one retrospective question and one change that fit the need people describe.
5. Check the result later and change your interpretation when the evidence changes.

Use the retrospective meeting guide to plan the session, then choose from the retrospective question library or the template library. Let the model focus the conversation, then listen to what the team tells you.