Development teams are often expected to be effective “right out of the box.”
Management: “After all, our they are all experts (and well-paid ones at that)!”
It is often overlooked that development teams do not achieve working synergy overnight; rather, it is a gradual process that takes time and is also quite sensitive to disruptive influences.
Tuckman’s team development model describes the stages a team must go through after formation to become effective. This model, which is nearly 60 years old, remains the most popular due to its simplicity and clarity. This model is not the direct foundation of Agile frameworks, but it aligns very well with them. Long-lasting, self-organizing teams often exhibit the behavioral patterns described by the model. It could be said that Tuckman’s model is implicitly “embedded” in modern Agile frameworks.
Over the years, quite a few competing models have been introduced that are intended to address the “shortcomings” of Tuckman’s model. Unfortunately, these models often view Tuckman’s model as too static and focus on addressing a single perceived shortcoming. As a result, these models are either impractically complicated or too narrowly focused to be useful in practice (for example, focusing on individual development rather than the team as a whole).
This does not mean that alternative models are wrong; it just means that the Agile frameworks we use every day, are not based on them.
Some of the better-known competing models:
- Punctuated-Equilibrium Model (1988)
- Salmon’s e-tivities model (2002)
- Wheelan’s integrated model of group development (1990, 2003)
- The Team Evolution and Maturation (TEAM) Model (1994)
You will notice that most of the models competing with Tuckman’s were developed before or shortly after 2001, when the Agile Manifesto was created. It served as the basis for the development (or at least the formalization) of many Agile frameworks. As mentioned, due to its simplicity and intuitive clarity, these frameworks have largely followed Tuckman’s model in their practical implementation. For this reason, the “enthusiasm” for developing new, revolutionary models following the publication of the Agile Manifesto has waned. The chances of such models being accepted by the professional community have, in fact, decreased dramatically.
However, if anyone today is still trying to grab attention quickly, they can still do so with sensational headlines such as “TUCKMAN WAS WRONG!”
MODEL
After a team is formed, its members need time to get to know one another, build mutual trust, learn to collaborate, and complement each other’s strengths. Tuckman identified five* stages of team development.
*The final phase is known as “Mourning” (Adjourning), or the disbandment phase, which is not relevant to our topic and is often omitted from diagrams. Tuckman added it later, in 1977. This phase is characterized by celebrating successes, an increased need for empathy, rewarding achievements, and the gradual disbandment of the team.
The basic premise of Tuckman’s model: A team’s effectiveness depends on the stage it is in.
PHASES
Tuckman’s stages are described in the context of the Scrum framework, but if we replace that term with Kanban, Lean Startup, or Agile, the meaning and relevance remain the same.
1 - Forming
The development team is taking shape. Members are uncertain about the purpose of the initiative, their expertise, their own roles within the team, and the way they will work. Driven by a desire to be accepted into the group, they avoid conflict. Optimism prevails. They turn to the Scrum Master for guidance. His role at this stage is often to provide direct assistance with activities and to establish a clear tactical picture of what needs to be done. In addition, the Scrum Master focuses during this phase on building trust among team members.
Key milestones, artifacts, and activities in this phase include:
- A specific product objective (alignment of the product with the organization’s strategy)
- Product Backlog (a list of what needs to be done to achieve the product goal)
- Organizational support for team self-organization (voluntary team formation, task assignment, and independent decision-making regarding how and when we will work)
- Definition of Done (Code Quality Standards)
- Agreements on working methods (Daily Scrum format, conflict resolution, rules for meetings and interactions)
2 - Storming
The different personality traits of the team members begin to cause conflicts. Members start to question the purpose of the initiative, their role on the team, the way they work, and the architecture of the solution. Communication among team members becomes more tense.
The Scrum Master helps team members move past this phase as quickly as possible by offering advice and providing unobtrusive guidance. Studies have shown that, in addition to the Scrum Master it also helps to have smaller teams (4–6 members), shorter tasks or user stories (up to 20 hours, with an average of 4 hours), and an “academic atmosphere” (enthusiasm for exploring different solutions). In addition, during this phase, the Scrum Master focuses on building relationships and trust among team members.
Key milestones, artifacts, and activities in this phase include:
- Emphasizing Scrum values (commitment, focus, openness, respect, courage)
- Sprint Retrospective (an opportunity to improve work methods, collaboration, and processes)
- Ongoing agreements on working methods (reached by consensus among all members of the development team and posted in a visible location)
- “Definition of Done” as a Decision-Making Guideline
3 - Norming
Team members who have learned to collaborate with one another during the storming phase move on to the norming phase. This alignment is often facilitated by a well-developed “Definition of Done.”
During the norming phase, the team becomes productive and self-organizing. Members have found their place in the group, resolve interpersonal issues on their own, and trust one another. Team roles have been established. Members have become more confident in their professional expertise and in their interactions with external stakeholders.
Scrum Master supports this phase primarily by providing advice, guiding the team in resolving conflicts, and removing organizational obstacles on team’s path.
Key milestones, artifacts, and activities in this phase include:
- Conducting Scrum ceremonies (Daily Scrum, Sprint Review, Sprint Retrospective, Sprint Planning)
- Taking team roles into account (developers, Scrum Master, Product Owner, external stakeholders)
- Focusing on creating a product increment in each Sprint
4 - Performing
During performing phase, the team reaches its full potential. Responsibility for the outcome becomes a shared responsibility, the Work In Progress (WIP) is low, and the flow of functionality through the development process is constant and predictable.
Teams begin experimenting with complementary practices such as pair programming, Test-Driven Development, XP, or scaling.
At this stage, the Scrum Master motivates team members, fosters a positive atmosphere, provides information about alternative tools (when developers grow tired of a particular tool), and removes (primarily external) obstacles to the team’s work.
Key milestones, artifacts, and activities in this phase include:
- Conducting Scrum Ceremonies
- Continuous improvement
- Metrics and Improving Forecasts for the Release
Many teams never reach the “performing” stage, yet they still function successfully. Usually, the reason for not reaching the “performing” stage is an excessive number of changes imposed on the team by the organization. Most often, this is a result of staff turnover. Every time a team gains a new member, it “resets” to the bottom of Tuckman’s model and must work its way through the forming and storming phases again. This, of course, affects productivity.
In practice, this means that adding team members with the aim of increasing productivity will, in the short term, have exactly the opposite effect (the Ringelmann effect and Brooks’s*The Mythical Man-Month*).
Another obstacle to reaching the “performing” phase is team members multitasking between working on a development initiative and their “regular” work responsibilities. This kind of division of time is strongly discouraged (On-Product Index). Developers should be 100% dedicated to a single development initiative. Any parallel task we attempt to carry out reduces our productivity by as much as 20%.
CRITICISMS OF TUCKMAN'S MODEL
There is no shortage of criticism and expressed reservations regarding Tuckman’s model. These are often reasonable and well-founded from a professional standpoint. The fact is, however, that despite its shortcomings, the model has worked well in practice for decades, whereas other, perhaps more academically grounded models rarely have.
Let’s take a look at some criticisms and respond to them.
1. Criticism
Studies intended to scientifically prove Tuckman’s model have failed to do so.
Answer:
In practice, the model functions as part of the most popular Agile practices and frameworks.
It is also not true that no study supports it. One of the more significant studies was conducted for the Defense Acquisition University in Huntsville, Alabama. The result of that study was the creation of a complementary DAU model, which assesses agility at the organizational level.
2. Criticism
The model was developed to assist group facilitators, not group leaders.
Answer:
Agile methodologies tend toward self-organizing teams where leaders emerge on their own initiative depending on the problem the team is solving (emergent leadership). This means that anyone can be a potential leader. For this type of leader, the model does not offer any particular added value, so in my opinion, there is no need to devote much attention to it.
Familiarity with Tuckman’s model will be particularly useful to a Scrum Master, who is essentially a team coordinator (facilitator, servant-leader). And it was with coordinators in mind that the model was developed.
3. Criticism
In practice, team development is not a linear process that follows the stages of forming ⇒ storming ⇒ norming ⇒ performing.
Answer:
Tuckman never claimed that.
With regard to the “linearity” of the phases, the Scrum Master should be aware of the following:
- Some team members may already be in the norming phase, while others are still in the storming phase. Depending on the maturity level of individual members, the Scrum Master must adapt their approach (adaptive leadership) and help members who are lagging behind to progress to a higher phase.
- Changes in team membership always “reset” the team back to the forming stage.
- Teams can skip a particular phase. In practice, this doesn’t happen, but a phase can be so short that the transition seems almost imperceptible for most team members.
- Multiple phases can manifest simultaneously with varying degrees of intensity. If we view every conflict as a “storming” phase, we can consider that, at a lower intensity, it may also persist through the “norming” and “performing” phases. However, such nitpicking does not add value for the team or the Scrum Master. Conflicts will always exist; it is the team’s capability in resolving them on their own that will grow as they progress through the phases.
OPINION
Tuckman’s model is not a comprehensive sociological framework, but for the purpose it serves, this is not even necessary.
If we want to achieve a highly effective development process, it is important to focus not only on team development but also on individual development. To this end, as a complement to Tuckman’s model, I would suggest the simple Shu-Ha-Ri model by Alistair Cockburn, one of the co-authors of the Agile Manifesto.
To understand team members’ motivations and the necessary organizational changes, a simplified version of Maslow’s hierarchy of needs is also helpful.
In my opinion, from a psychological and sociological perspective, these three models are sufficient for successfully understanding and guiding development teams toward cohesion and high effectiveness.
Of course, a team that’s in the performing phase can also look for alternatives to this claim. 😊
We explore Tuckman’s model in the context of Adaptive Leadership in more detail in the Scrum Master course.
