Hector Correa

Team Dynamics

A few years ago during my ScrumMaster certification our instructor talked about the different development stages that teams go through. He used Tuckman's development model which includes four stages: Form, Storm, Norm, and Perform.

In this model teams start at the Form stage when they are first put together. This is the honeymoon period of new teams in which spirits are high, everybody is optimistic, but the work is just about to begin. Storm is the period after the honeymoon in which, once the work has commenced, team members try to find their place in the team. After the storm phase, teams go into the Norm stage as members start to find their place on the team and the team starts working as a cohesive unit. Finally, some teams reach another stage called Perform in which they become high performance teams.

I've always found this knowledge of incredible valuable. Knowing that teams go through these stages and that this is normal behavior is very important. As a team leader is also important to recognize that teams need different leadership styles as they go through these stages.

Blanchard et al. have a very nice chart where they explain the four stages and the kind of leadership recommended on each of them:

Leadership styles

In the first stage (Form) the team needs a significant amount of direction (as the team is newly formed) but little support since they are typically excited just by being part of the new team.

As the team moves into the second stage (Storm) and tension among team members start to raise the leader need to act as a coach and provide both, direction and support for the team to get through the rough period of recognizing each other talents and trust one another.

The Storm stage is commonly misunderstood as a "bad stage" since during this phase team members tend to start feeling down as the discrepancies between the initial hopes and reality kicks [4], the initial politeness fade, people start to get more into the work and their roles and so start to argue about things that were left unsaid or not realized when they first met [3]. However as Blanchard, et al. indicates calling Storm stage a bad stage is like calling adolescence a bad period. Storm is a process that teams go through as they develop. As a leader you should be careful to help teams grow out of this stage instead trying to prevent this stage altogether or letting the team perpetuate this stage. The article in ChangeMinds.org [3] provides some guidelines on how to manage a team during this stage including:

"The manager here needs to assert their role and help draw out and resolve differences that might otherwise bubble along under the surface, causing continuing team cohesion problems."

and

"Storming can also be reduced by clarifying work goals and individual role and objectives. When people know what individual success means, they become more focused."

When teams start moving into the third stage (Norm) performance increases and the role of the leader is to keep supporting the team to make sure the trust among team members is kept. At this point the team has a clear idea of the task at hand and need little direction. The team is already making decisions and the leader should step back to let the team flourish.

Finally, as the team reaches the fourth phase (Perform) the leader's role shift into delegation which means letting the team make their own decisions and support itself. Teams that reach this stage are called high performing teams.

Beside Tuckman's group development stages other authors have proposed different stages but the main idea is the same. Teams go through phases through their lifetime.

An important thing to note is that teams can step back to a previous stage. For example, a team that has reached the Perform stage might go back to the Norm or Storm phase. This can be caused by changes in team members or changes in the team's goals. In software development teams this could be the result of adding new developers to a team or changing the goal of the team as a result of new market pressures. In a small team just adding a few more developers (say going from four to six developers) might be enough to disrupt the roles already established by the team. As a team leader you should be aware of this and act accordingly.

An unfortunately common occurrence in software teams is adding QA resources to a development team after the team has formed and bonded. Not only it is a bad practice to push the testing of the system towards the end of a cycle but adding a new role (that will find bugs in the code and "slow down" the development!) to a team already formed exacerbates the impact of this new role and increases the likelihood of taking a team from a norm or perform stage to a less productive stage like storm. A better approach in this case would be to include QA from the beginning and make it part of the development effort. If you don't have that luxury and have to add this role towards the end make sure you address both, functional and behavior changes that the new role will bring to the team.

The take away from this post is twofold. On one hand remember that all teams go through these development stages and that this is a normal process. On the other hand is important that you as a leader recognize the stage that your team is at and manage it accordingly.

There is a lot of material regarding the stages of a team and team productivity. A good reading is Alasdair White paper From Comfort Zone to Performance Management [5].

References