Tuckam Model: understanding the stages of team development-EN

As an agile instructor, one of the primary aspects of my work is working with people, and specifically people on agile teams. 

According to the Scrum guide, a development team “consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. A “Done” increment is required at the Sprint Review. Only members of the Development Team create the Increment.”

Also, Scrum tells us that a team should be cross-functional… meaning that a team needs to have all the necessary roles and skills to make the product or idea become reality.

While these dynamics seem easy to achieve, I almost always experience resistance – especially when it comes to structural changes. Consider the AS IS of an analysis team, a development team, a testing team, an integration team, etc. working in silos. The TO BE version would have multiple teams with members from each of the previous departments.

It is essential that the change made to the new paradigm is made with minimum risk, provided the market situation allows. A good practice would be to have a pilot – create a cross-functional team for testing before rolling out the practice to an entire organization.

Scrum also tells us that teams should be self-organized. Following the previous example, I’ve seen organizations take people from different departments, put them together in a room together, and tell them, “you are an Agile team, self-organize”. Not surprisingly, this “experiment” is likely to fail and team members will be of the mindset that “Agile does not work here.”

I encourage these ‘failed’ teams and other new teams to follow Tuckman Model.

Bruce Tuckman developed what has become known as the Tuckman Model. After observing small groups from various perspectives, he was able to determine four phases of development that all groups/teams must go through to achieve maximum effectiveness:

1. Forming
2. Storming
3. Norming
4. Performing

Agile Team I. Forming: Start the Trip.

According to Tuckman’s Model, a team like the one described above would be in the Forming phase. The new team is getting to know the rest of the people who form the group – what are each other’s tasks and interests, what drives them? At this point, people tend to behave in an individualistic way and are also try to avoid conflict.

At this stage, it is important to have the support of a good mentor – this could be an Agile Lead, Scrum Master, etc. Whatever the title of the person, their role should be to help the team obtain good results. If you consider a soccer team, this person is the Coach.

It is common that the habits of a previous organizational structure (which are often still coexisting) are dragged into the team – each member focuses only on their work and considers the rest of the team as independent of their work.

Continuing with the soccer analogy, defensive players only care about defending, strikers who only care about scoring goals. Consider match that the team loses where a forward scores 2 goals and the defenders got 3 goals. In the Forming sate, it is common that the forwards are happy because they have done their job very well and point the finger at the defense for doing their job wrong – even though they scored goals.

At this point, the Coach needs to make them see that the important thing is that they lost the game and help them find ways to improve for the next iteration. Teams need to understand that despite their specialty, if it is necessary, “they all go down to defend” or “promote some to finish off, if the occasion requires it.”

The evolution of a team is a long and challenging process for both the team and the coach. The goal is to have teams that win matches by realizing it is the team as a whole that solves problems.

Agile Team II. Storming: Navigate the Conflict.

As teams spend more time together, individuals interact with each other, get to know each other, and establish interpersonal relationships. Difficult situations (or problems) will inevitably arise as a team evolves. How a team navigates and responds that conflict is Stage II – Storming.

NOTE: The definition of a problem is something that alters the peace, balance, and harmony of a team. In more mundane terms, it’s a circumstance that makes it difficult to achieve an end.

Even though trust has been established at this stage of team development, members begin to express their differences regarding the actions and opinions of the other team members.

People from different departments that are now a “team” are facing high-pressure situations. It is very common at this stage that conflicts occur. Several comments that indicate a team is in the Storming phase can be, “We have not finished the US because QA isn’t done”, “The Developers do not do the unit tests and therefore we do not arrive”, etc.

Despite being labeled as a team, they are really just a group of individuals.

If we were on a soccer team – the comments could be, “If everyone had my level, we would be first,” or “I give the team a 9 but I am a 10.” Players put their personal good before the group.

This stage is necessary. If you want to reach the level of a “high-performance” team, it is necessary for the team members to show their differences.

Unfortunately, this is the natural state of many teams – it is always the fault of the other members or silos with whom they interact in the value chain. It is very difficult to see since rivalries between traditional departments have always existed; this conflict is nothing new. They don’t see how all their work collectively influences the final result.

It is very important during this stage that the team, and especially the Scrum Master or Coach, is able to keep the conflicts that arise under control. To move forward as a team, they must create an environment of trust and collaboration so that they can communicate and learn to work together. Members must be able to share their opinions and move forward as a team to identify and resolve conflicts.

Agile Team III. Norming: Collaboration Mechanisms.

According to Tuckman’s model, the next evolutionary stage is the stage known as Norming or normalization.

Based on my experience, the move from Storming to Norming is not trivial. I have seen many organizations and teams stall in the Storming stage for years or even decades. In fact, this might even be a part of the company’s culture, and evolution beyond this isn’t expected. These teams live in constant conflict and believe that conflict is something negative and inevitable. However, we can make a positive reading of the conflict – it is necessary to move forward!

Conflict can be constructive. The key here though is that the team needs to understand that they have to have a common goal. At this point in the evolution, team members feel that they are part of a discipline and cohesive team – and they have higher aspirations. They will work for the success of the team, putting it even before their own individual needs. Although they do not fully share all their tasks, they are aligned to a common cause.

This is where the soccer team understands that apart from the sub-goals of “scoring many goals” and “avoiding many goals,” there is an overall goal “to win the match.”

Perhaps none of the team’s sub- goals are met, but its members are doing what they know best and helping the rest of the team with whatever is necessary to achieve the common goal. Norming teams have a definite goal to achieve; their members are able to understand each other’s point of view, appreciate their skills and experiences, and even be willing to change for the common interest.

The team members will define how to collaborate with each other in the face of challenges presented to them by always keeping their objective in mind.

Depending on the maturity of the teams (and the relationships between their members), a team will move between the Storming and Norming states as new situations arise that test them. New or revised mechanisms of communication might need to be practiced.

In team management (or self-management), retrospectives are a very powerful and useful tool to overcome these challenges. According to the Scrum guide, a retrospective “is an opportunity for the Scrum Team to inspect itself and create an improvement plan that will be addressed during the next Sprint”. Dedicate a workshop on retrospectives with the goal of highlighting two aspects:

1. The team is inspected
2. The team creates an improvement plan

While both aspects are equally important, the first step is often overlooked. When I found that teams stopped doing retrospectives, the story was always the same:

“We met every 2 weeks and each time we got the same points of things to improve. Each sprint were the same points, and so on for months. Until someone in the end someone suggests, ‘What if we stop doing retrospectives?’”

Agile Team IV. Performing: The Team on a Roll.

When the team is established in the “normalization” stage, its maturation capacity increases exponentially. The team understands how to learn from new situations that arise and establish collaboration mechanisms to overcome these challenges.

According to Tuckman’s model, the team now moves to the next evolutionary stage: Performing, or Performance.

Needless to say, in the same way as with the previous step, not all teams reach this stage. All who reach this point will do so after overcoming many varied difficulties.

At this stage the team members know each other well, are able to manage the conflict properly, and above all they are well motivated and prepared to work together as a team. Normally, teams in this stage stand out for their autonomy and lack of supervision, since they have proven themselves worthy of trust throughout their trajectory.

The teams that reach this stage have in common their ability to learn or continuously improve. Throughout their evolution, they have been identifying the improvement points, bottlenecks in their processes or other impediments, and they have established ways to collaborate to overcome them.

The soccer team would have analyzed its weaknesses, and as a team, would have looked for options to solve or mitigate these problems.

In the beginning of this article, I referred to the development team. The development team is part of a larger entity: the Scrum team. The Scrum team consists of the development team, a Product Owner, and a Scrum Master. By definition,  “Scrum Teams are self-organized and cross-functional. Self-organized teams choose the best way to carry out their work and are not directed by people outside the team. Cross-functional teams have all the necessary skills to carry out the work without relying on people who are not part of the team.”

When we start using agile as a framework, it is unrealistic to think that the team will automatically become “self-organized”. This is only achievable over a period of time. The team must be allowed to  face different challenges and acquire the experience to truly become “self-organized”.

Gracias,

Victor