Management experts have long been trying to study the behaviours of high performance teams, hoping to distill their insights into a magical recipe for leadership success. One of the most famous studies is Tuckman’s Model of Team Development, which identifies a set of stages (Forming, Storming, Norming, and Performing) that teams need to pass on the way to optimal performance – and some of the barriers to progression.
The Tuckman Model of Team Development
The Tuckman Model of Team Development was introduced by Bruce Tuckman in the 1960s and refers to the stages that teams commonly go through as they learn to work with each other and ultimately deliver. Before getting started, I’ll take a brief moment to explain what each stage means.
Forming is the initial stage where the team is brought together. It’s probably the first time that the team has worked with each other, so they will tend to tread lightly and aim to be accepted by everyone.
Once pleasantries are out of the way, the team will attempt to learn how to work together, referred to as the Storming stage. Often they will express conflicting views. It can be a period of tension and against for the team, particularly those individuals averse to conflict. Some teams may never progress past this stage, unless they resolve their differences and learn how to interact with each other.
If the team is able to progress past this phase and start working towards a common goal, then this is referred to as Norming. There may still be some issues to resolve during this stage which certain members may be avoiding. Until the team works through these issues, they will not be able to perform.
A Performing team works well together, discusses their issues and concerns, and delivers above expectations1/2/3.
Forming stage – Hi, my Name is…
In traditional project methodologies, the planning or inception is usually done with a select group of people (e.g. a project manager/scheduler, senior technical resources and the sponsor). The project uses a phased approach and teams are scaled up and down depending on the SDLC phase. Project leadership dictates the way in which the teams should be organised and resources are added or removed depending on schedule/budget adherence. As per Tuckman’s model, each change to the team returns the team to ‘Norming’ mode and there are no traditional measures to determine how well the team is performing and how well the schedule is being adhered to.
In Agile methodologies, planning or inception involves the whole team. When a new Agile project kicks off, it is common to come together to define what the project is about, what the team aims to deliver, and by when they think they can achieve it. The project kickoff (also known as Inception or Initiation) allows the team to get to know each other in a very short amount of time due to being in close proximity for a number of days. Teams are allowed to self-organise in the way that they feel will best deliver and team velocity is a great measure of team performance.
Our team entered the forming stage when we were brought together to deliver a new product. A number of us had only just met. Some of us only met each other on the first day of the project. We kicked off the project together by going into an Inception workshop, allowing us to introduce each other and work out personalities and group dynamics. Unfortunately, we were all playing it safe, not bringing up any issues and subsequently not progressing effectively.
Our newly formed team left the workshop being introduced to each other and working out the personalities among the team, but we were all playing it safe and not bringing up any issues. We also left believing that we could achieve a certain Velocity for each Iteration, and would be able to do this from day one. We were wrong…
Forming through to Storming – Brought forward through visibility of issues
We got into our first Iteration and did not deliver anything. You can see this in the picture above that we delivered zero Story Points in Iteration 1 and we were already behind the eight ball. There were a number of reasons for this, however, one that really stood out was the fact that the team was not co-located and this lead to poor communication. We also started to lose the pleasantries and raised our issues with each other (early signs of the storming stage), which was probably brought on by the fact that we had not delivered anything. This is where Agile help in that it makes issues visible very early on in the piece. If we didn’t change anything, we too could have ended up as one of those teams that never progresses past the storming stage.
Co-location and working on communication are two key aspects for building a new Agile team (or really any team)4/5. There is a reason that they are included in the Agile Manifesto and it is for this very reason 6. The main area of concern that the team identified from our first Retrospective (another practice within Agile that I believe accelerates development as it provides an avenue to discuss how the team is going) was that we needed to be sitting together. We were spread out across the floor and we had to walk to each other in order to discuss anything with the team. We already knew that if we weren’t co-located together it would slow us down. It would also meant that we spent less time together and would be more likely to have conflicting opinions that may not be resolved. These discussions brought on a dramatic change. To co-locate together in a meeting room and to value the Agile principles that co-locates helps team development.
Storming stage – Conflict arises
We reached the fully fledged storming stage during the second, third, and fourth iterations as we made some progress and learnt how to work with each other. During this time we had a number of differences in opinion. A key example of this was highlighted during one of our Retrospectives when one of our Testers passionately shared that he felt our Acceptance Criteria weren’t detailed enough. A number of team members disagreed and felt his ideas were unnecessary requirements.
We did, however, to manage each others’ expectations within the Retro and came up with a simpler solution. As we progressed, these passionate conflicts became less and less frequent as we learnt each others’ personalities and how to constructively deal with concerns and criticisms. This was during a point in time where we we learnt to self-organise as our Project Manager and Technical Lead were away on Annual Leave.
Self-organising teams is an aspect of Agile that prompts teams to develop more quickly as they are not being constantly guided by a leader. They have to either sink or swim by themselves. Additionally, being co-located in close proximity meant that we were able to have quick conversations. Both of these aspects are important when building a new Agile team4/5. The end result was that the team grew quite a bit during this time and learnt how to work together independently of formal leadership roles. We were reaching the norming stages of team development.
One of the challenges of traditional development methodologies is that when conflict arises it is usually aimed at teams that are up or down the line. If the QA team has a problem with the requirements, they blame the Business Analysts. If the Dev team is working late nights and weekends, they blame the Project Managers. If the customers are not happy with the outcome, they blame the whole team. A co-located, cross functional team that works together to deliver value has a far better chance of progressing past the Storming stage that one that is both geographically dispersed and ‘handing things over the fence’.
Norming stage – Everything’s OK?
By the start of our fifth Iteration, our Project Manager and Technical Lead returned from holidays. It was also decided that our team would expand to include two new team members. This was in order to take on additional scope that the team was asked to deliver. Although the team was starting to go through the norming stages of team development and regularly delivering new functionality in each Iteration there were some side effects to the change in the team structure.
It is common for teams to regress to the forming or storming stage of team development when the team structure changes. Depending on when the team members join the team this can actually affect the delivery of the project1/7. Fortunately it wasn’t too late for our team. What we found is that we stayed at roughly the same delivery rate for a month after the new team members joined, however, we continued to work in our small meeting room (it was getting squishy) and continued to make communication a priority. This lead to something extraordinary in what turned out to be our 7th and last Iteration prior to releasing our new product.
Performing stage – Here comes the BOOM
In this last Iteration we delivered more functionality and defect fixes in a two week period than we did in the first 4 Iterations of the project. Talk about a hockey stick effect! You can see this in the pile of cards from the first photo. In hindsight, this is where we reached the performing stage, and I believe there were a number of reasons for this, which can be related back to Agile practices and principles.
One reason was that we had set ourselves the target of being finished with development by the end of the 7th Iteration once we added the additional scope. We came to this target by reviewing our burn-up chart and predicted when we thought we would finish (based off actual/forecasted Velocity). Although this wasn’t a fixed date (and sometimes we thought we wouldn’t make it), we continually worked towards this date and put additional emphasis on the date during the last Iteration. You may be thinking that this would be discourage working at a sustainable pace, which would be anti-Agile. However, in actual fact this didn’t result in working additional hours, but was more the result of focused attention.
This brings me to the second change that we made in the last Iteration. We introduced “Walking the Wall” on every second day during our Daily Standup to go through each Story Card on the Story Wall and ensured everyone knew what was required of them. This was based off some discussions during a Retrospective, and so the team took it on board to continuously improve how we worked together. By incorporating the Agile practice of “Walk the Wall” we ensured that everyone had clear priorities when finishing the Daily Standup, were constantly focused in the last Iteration, and worked towards our goal.
We also reaped the rewards in the last Iteration of continually working to improve the team dynamics and communication, and co-locating the team within close proximity. The result was that we delivered the project in the timeframe that was originally expected (despite the initial set backs of ramping up the team) and built a performing team that was kept together for a second project at our organisation.
Reflections
Building a new project team comes with its challenges. However, by sticking to the Agile principles, practices, and values there are a number of areas that can be addressed as quickly as possible when a new team is formed to help them progress through the forming, storming, norming, and performing stages. These include regularly reflecting as a team using Retrospectives, co-locating the team together, allowing the team to self-organise, and encouraging communication within the team.
Additional factors can also contribute to developing a performing team. For our team, we found that setting ourselves a target to be completed by a certain date, and using “Walk the Walls” to increase our focus worked well for us. They may also work well for your team, or you may discover other approaches that work just as well, if not better! By focusing on these areas and continuously improving the team, you will have a greatly improved chance of building a performing team!
Further reading:
- Successful Team Building Is an Agile Process
- Tuckman’s stages of group development
- Tuckman’s Team Development Model
- Should BAs be co-located with their Development team? — Elabor8 – This reference includes further content that was used to write about the need for co-location within project teams.
- Top 10 Mistakes Made by New Agile Teams | Rally Help
- Agile Manifesto
- Brooks’s law – Wikipedia, the free encyclopedia
