In a recent class, a student asked, “What are the common difficulties teams face when starting with Agile?” To answer this question, I refer to the Tuckman Model of group development, shown below.
Tuckman. 1965.
The Tuckman model describes the phases that groups of individuals go through when they first begin working together as a team. In the first phase, Forming, teams are uncertain about the team goals and how to work together. In the second phase, Storming, teams challenge boundaries and get to know each other and how to work together. In the Norming phase, teams become more comfortable with each other and more familiar with their processes. And in the final phase, Performing, teams really begin to work together well, achieving an ever increasing level of peak performance.
Psychologist Bruce Tuckman discussed team performance in his 1965 paper, Developmental Sequence in Small Groups, introducing the four phases of team dynamics. He labelled these phases "forming, storming, norming, and performing.” He later added a fifth phase, “adjourning" (also known as "mourning"), to mark the end of a team's journey. I have not included this stage because Scrum Teams generally support products rather than short-term initiatives.
For Agile teams, the goal of the Scrum Master or Agile coach is to get teams through the first three phases (Forming, Storming and Norming) as quickly as possible so that the team can get to Performing. In this article, I will discuss the tools that are used at each phase of the Tuckman model to coach teams towards peak performance.
Forming
According to Tuckman, when new teams are in the Forming stage, members can be unsure of the team’s purpose, how they fit in, and how everyone will work together. The Scrum Master’s job is to get the team through the Forming stage as quickly as possible. The following tools can help teams to get through the Forming phase by helping to clarify team goals as well as helping to facilitate team conversations about how to approach their work and how to work together.
The Product Backlog
One of the three artifacts the Scrum framework identifies is The Product Backlog, an ordered to-do list of all work to complete on the product. The Product Owner is accountable for the Product Backlog and continually refines it in collaboration with the Scrum Team. The Product Backlog contains a commitment, called the Product Goal, which you can think of as the guiding star for the Scrum Team. All work on the Product Backlog should support the Product Goal, and each Sprint should be a step towards that Product Goal.
The Product Backlog and the Product Goal have a great deal of impact in helping teams move out of the forming stage faster because this artifact gives the Scrum Team a clear goal and steps on the path to achieving it. One of the main characteristics of teams in the forming phase is goal confusion, which the Product Backlog directly addresses.
Self-organization
Another characteristic of forming teams is their concern about how each member fits in. According to the Scrum Guide, Scrum Teams should be self-managing, meaning they internally decide who does what, when, and how. During forming, the Scrum Master might choose to facilitate a self-organization session. This session often happens when there are enough team members to potentially form more than one Scrum Team in support of the product. At the self-organization session, the Scrum Team determines how best to organize themselves to support the Product Goal and whether multiple cross-functional teams make sense.
Definition of Done
An increment is another of the three artifacts in Scrum, and it is essentially what the team delivers at the end of each Sprint. As the 2020 Scrum Guide puts it, “The moment a Product Backlog item meets the Definition of Done, an Increment is born.”
A Definition of Done is a common understanding of all the work the Developers need to complete for each Product Backlog item before being considered part of the product increment. A Definition of Done might include ensuring unit tests pass, code review is complete, code is merged into the main code branch, or that the codebase is integrated into any other systems. Because the Definition of Done creates transparency around what work the team needs to complete, it helps them transition from the forming stage faster by removing uncertainty.
Team agreements
Team agreements are a beneficial complementary practice to Scrum. The agreements are specific to each team and describe how team members work together. They might detail such things as how members agree to handle conflict as well as standards for managing the Product and Sprint Backlogs. For example, it might outline where to house the Product Backlog, how to know when each item is ready for development and to close. Team agreements help teams move out of the forming stage faster because they reduce role confusion and clarify responsibilities.
Storming
In the Storming stage, Scrum Team members might start to push against the established boundaries. Friction or overt conflict can arise between team members as individual personalities and preferred ways of working surface and clash.
At this stage, team members might question everything–role accountability, team agreements, even the Product Goal. Although this is a healthy process, the Scrum Master must ensure the team upholds the Scrum Values so that members can build trust in themselves and each other.
Scrum Values
Upholding the Scrum values can help ride the rocky waves of the Storming phase. The Scrum framework includes five values: commitment, focus, openness, respect, and courage. These values can help teams to deal positively with the conflict that can emerge during this time.
Sprint Retrospective
Another helpful tool for easing the Storming phase is the Sprint Retrospective. The Sprint Retrospective is the final event in a Sprint. It is an opportunity for the Scrum Team to discuss how the Sprint went regarding individuals, interactions, processes, tools, and the Definition of Done. At the Sprint Retrospective, the team might modify its team agreement or Definition of Done and should identify at least one actionable improvement to take into the next Sprint. The team can add this improvement to the Sprint Backlog for the upcoming Sprint, or they might track it in some other way. If the team does the Sprint Retrospective well, it will not recognize itself in six months because much will have changed.
Team agreements
During the storming phase, I expect the team to refer to their team agreements frequently and possibly update them based on conflicts that arise. For example, one team I worked with updated its team agreements so that all meetings would start five minutes late to reduce the annoyance of late arrivals. Another team agreed to turn off mobile phones during meetings.
Definition of Done
As team members learn to work together in the Storming phase, their ability to update the Definition of Done can help. They will learn what items would be beneficial to add for clarity. For example, teams might add testing steps at this phase or require including a certain amount of detail for each Product Backlog Item.
Norming
After the chaos of the storming phase, things start to settle down as the team moves into the Norming phase. During this phase, the Scrum team members begin to self-manage and resolve their differences and come to appreciate each other’s strengths. The Scrum Master, Product Owner and Developer roles become clearer, and Scrum Team members begin to understand how to interact with the Scrum events and artifacts. Team members might turn their attention to ensuring that they deliver a Done, usable increment more frequently. They may also take on more self-management activities (such as greater attention to the Sprint Backlog during the Sprint Planning meeting) and may look for ways to improve their skills.
Performing
In the performing phase, the Scrum Team is in flow and achieving its full potential. With hard work and structured processes, it is likely to achieve its goals efficiently.
As team members grow together, they might experiment with complementary practices such as pair programming or become more cross-functional. Team members should continue to focus on continuous improvement by becoming more efficient in their use of the Scrum events, more transparent in their use of the Scrum artifacts and by ensuring that they are practicing role clarity and living the Scrum values. Scrum teams should improve their ability to forecast by using complementary practices such as estimation with points, and Scrum teams should continue to evaluate how well they are meeting their Product Goal by evaluating metrics which evaluate their ability to deliver value to the customer, such as Customer Satisfaction, Sales, or other metrics which measure team performance against the Product Goal.
About Mary Iqbal
Mary has trained more than 1,000 people in Agile, Scrum and Kanban. She has guided the Agile transformation for organizations with more than 60 teams and has led the creation of new products from product definition through self-organization and launch. Mary is the founder of Rebel Scrum, a consulting company that helps teams transform to Agile and provides training and coaching services founded upon practical experience. Rebel Scrum has experience in large-scale agile transformations in a variety of environments including technology and business transformations. Signup for one of Rebel Scrum's upcoming public scrum training classes or contact us to discuss private Scrum training and consulting options for your organization.