What Are the Stages of Team Evolution?

Almost half a century ago, the American psychologist Bruce Tuckman published a theory of team evolution.[i] Agile software development teams did not exist at the time, but Tuckman’s Group Development model applies well to them. According to the model, a team has to proceed through a certain sequence of stages on the way to the desirable stage, performing.

In the initial stage, forming, members learn what the team is supposed to accomplish. They get to know each other and their first-draft idea of roles and responsibilities. In this stage, most of the work is still individual, and some members try extra hard to look good. The forming stage is generally short-lived, overshadowed by the realities of the next stage.

In the second stage, storming, the team experiences conflict and difference of opinion. Some of the decisions they need to make draw out tensions and emotions. There might be some jockeying for influence and leadership. In a new Agile team, the first several iteration planning sessions tend to include disagreements about estimation approaches, the extent of detail in user stories, and task assignments.

If the team can pull itself out of storming, whether on its own or with your guidance as the Agile team leader (ATL), it reaches the third stage, norming. Members understand the rules of engagement. They establish, follow, and adapt agreements. Everyone understands the team’s goals the same way and cooperates to achieve them. They know and follow their process.
The fourth stage, performing, is the big deal. A performing team doesn’t just hum along — it buzzes. Its members are motivated and delighted to be there. They don’t have to speak with the same voice, but they don’t let conflict turn into confrontation. Consensus and self-organization are easy for them. They don’t worry about making their team work anymore; that has been taken care of, and now they focus on results. They don’t merely cooperate, they collaborate.

The following diagram[ii] shows the change in the team’s effectiveness in the various stages. Note that the qualitative effectiveness level in norming is similar to that of forming. In forming, they are a group of individuals who apply themselves; in norming, the added value of their teamwork may still not compensate for the energy they spend on being a team.

This model has several important implications for you. The team is at risk of never reaching norming. Team growth is evolutionary, and success is not inevitable. Even with the most suitable people using the best methods with good support, there is no guarantee they will graduate from the storming stage. Some teams may appear to have normed, but in reality they put on a happy face, stifle all conflict and differences, and defer to their product owner and managers.

Three teams were working on a single program. To be cross-functional, each team had been formed with half of the Batch Team (back-end) specialists and half of the Online Team specialists, in line with the main technological divide. Each half was further divided into programmers and testers, working in handoff fashion. Iteration planning sessions were muted and ineffective; retrospectives were louder but resulted in little traction. After a year of using Scrum, they struggled mightily to figure out roles and collective ownership — self-organization was all but moot. Few people seemed happy.

Expect conflict. If you put intelligent, capable people together and ask them to share responsibility for a goal, how likely are they to agree on the means to get there? How likely are they to exhibit a healthy balance of leadership and followership? Conflict is necessary for the elaborate dance of team growth. It is not inherently detrimental, unless it is allowed to devolve into confrontation and one-upmanship.

The road to low performance is paved with good intentions. Whenever you add people to a team, even temporarily (such as contractors), you knock the team down a stage or two as they adjust to their new composition. New permanent members require an investment of time, energy, and goodwill from veteran members. If you redeploy a valued member to seed or help another team, the remaining members will restorm to fill the void and adjust their leader-follower patterns. (You can mitigate the effect by seeking their agreement to the move.) If you remove a noncontributing member, the team will have to adjust the norms they had established to accommodate that person. All these changes in team composition spell a drop in performance, which might last longer than you intend, even indefinitely.

“Our team was originally bolstered with several contractors, who stayed for differing periods. Only once the last contractor had left and we had settled into a stable team — well over a year after the team was first created — did I feel the team really started to jell.”

— Ian, software ATL in a hardware company

About the book

The excerpt above is from the book The Human Side of Agile: How to Help Your Team Deliver which will be available September the 12th. The human side of Agile is tricky. It’s the least manageable, understood, and appreciated asset in an Agile environment. Even if your customers are reasonably happy and your developers seem to be doing okay, you know your team is capable of more: delivering great products and staying ahead of ever-changing demands. You want to feel good about using Agile and to create the conditions for great results, but the skills you honed in traditional environments don’t always apply to the role of Agile team leader. The Human Side of Agile fills this gap, guiding you to:

• Establish yourself as a confident and capable leader who adds value
• Build and lead an engaged team that can handle almost any challenge
• Cultivate collaboration and a continuous improvement mind-set
• Reap the full benefits of Agile in the real world with real people