Latest information from Radtac

See all topics

Subscribe to the Radtac blog

Connect with us

Recent Posts

Latest information from Radtac

How To Create High-Performing Teams

High-performing teams

Often we talk about creating high-performing teams. What do we need to consider when creating a high-performing team, and how exactly do we do it? This blog article will answer your questions.

Can a High Performing Team be created just like that?

If you're in a project, and you're creating a new team, typically you get people from different parts of the organisation together into what you call a team. At the end of the project (which by definition is a temporary structure), that team gets crashed or abandoned.

Before we talk about the end of the project, let’s first look at how a group develops.

Tuckman's group development model: Forming - Storming - Norming - Performing

The model proposed by Bruce Tuckman for the first time in 1965 is mentioning the phases or stages that are vital and unavoidable in the development of a group: forming, storming, norming, and performing.

Forming-Storming-Norming-Performing Tuckman Model


When we initially create the team, team members will have different thoughts, such as: ‘Who's on our team?’, ‘What are we working on?’, ‘How are we going to do this?’. It is likely going to take them a few days, or a few weeks, to get through this initial forming stage.


In the next stage, the team have been together a little while, so they're going to be looking at resolving initial conflicts between different members of the team. They will also deal with resolving difficulties in establishing everyone's understanding, and make an attempt at coordinating work between people, their roles and their processes, but it's going to be a little bit fragile at this stage.  


After a bit more time spent beside each other, team members will move out of the Storming phase into the Norming stage, into what starts to look more like a ‘normal’ functioning group. The team will now establish different agreements between people, and different agreements regarding roles and responsibilities. It starts to become a little bit more like a team. Individuals have adapted to the way everybody works, feeling comfortable with their processes and starting to work at a good rate.


It’s not until the team members have worked together for some time, that their process roles and responsibilities have become the norm and they are a ‘tool’ for the job. The team is now working as a solid machine, delivering and performing.


An additional stage of the Tuckman group development model is Mourning, which happens at the end of a project when a team is crashed - a sad time.

Through Tuckman’s Group Development model we can see that regularly creating and crashing teams is quite a wasteful process. It would be far more productive to keep teams together for a longer time.

In Agile, what we try to achieve are long-lived teams. These stay together for a long time, learning how each member works, learning how to do the work, and hopefully becoming high-performing teams. We change the logic of moving people to the work (normally projects), to moving the work (normally products) to the people.

What is a high-performing team?

A high-performing team is a team which is self-organising, has removed any dysfunctions, is cross-functional, collaborates, and is focusing on outcomes. Let's look at these traits one by one.

Before we do so, something worth mentioning is that creating an environment for a team to become performing is often the responsibility of a team’s ScrumMaster or Agile coach.


A self-organising team is one that can take initiative for its own actions, where members work together focusing on team contributions, rather than working as individuals. The self-organising team concentrates on delivering an integrated solution, rather than just focusing on the low level objectives that have been set. In a self-organising team, members cooperate with one another and work together to deliver the solution rather than being competitive against each other within the team. The self-organising team is one that continuously looks to improve what it is doing, rather than stopping when it got to the point that's been initially set. Finally, the team will take necessary steps to prevent emergencies. It will make sure the system is resilient, that it won't crash in a live environment, rather than reacting to emergencies later on.

Removing the dysfunctions of a team

In his book, ‘The Five Dysfunctions Of A Team’, Patrick Lencioni has identified how we can try to eliminate dysfunctions within a team. The five dysfunctions identified by him are:

  1. Absence of trust
  2. Fear of conflict
  3. Lack of commitment
  4. Avoidance of accountability
  5. Inattention to results.  

Five dysfunctions of a team Patrick Lencioni

First, we need to build trust between team members- this will need to be earned by the Agile Coach / Scrummaster. Then, we need to remove conflicts between team members. The Agile Coach will need to seek out any conflicts in the team and resolve them. After this we can start to get the team to commit to delivering, and then become accountable for their work. A team will plan their own work, commit to delivering it and become accountable for their success. Finally, the team can focus on delivering results. Getting the right customer outcomes should be foremost in a team's mind.


It is important for the team to have strong collaboration not only between different team members, but also between the team and different other teams.  Where weak collaboration exists, it can often lead to poor quality, poor performance, technical debt, poor knowledge sharing, too much work in progress, unnecessary rework, misunderstood acceptance criteria, and ultimately a low team velocity or throughput. A technique you can use here is setting team working agreements. Working agreements help resolve or avoid conflict, and create a collaborative culture in the team.


What do we mean by ‘cross-functional’? We meen team members that are capable of delivering more than one skill. For example, it might be that you're a developer, but we would also want you to have the skills to be able to do some analysis, or do some testing, or do some user design.

We don't expect everybody in the team to be able to do everything (although that could be desirable, it is unlikely to ever happen). But we do expect people in the team to be able to take on more than one skill. We like to call these people T-shaped.  They may have a strong skill in one area, but they're able of taking on some skills in other areas.

T-shaped people

The most important thing is that there's a good balance of people and skill sets throughout the team, so that there are no single points of failure within the team.


Another aspect we need to consider when starting to create high-performing teams is how we will measure the success. We need to be wary that the way we measure a team’s success can influence members’ behaviours.

We should not be measuring things like story points, velocity, or defects. By measuring these, we would drive unwanted behaviours, such as a team trying to deliver as many story points as they can in a sprint.

We should be taking this opportunity to measure the performance of a team by looking at how much value they have the added to the business, how quickly have they added this value, and whether customers are happy.

There you go - these are a few things you need to consider before you start creating your high-performing teams - from the stages of team development, to the characteristics of a high-performing team and what each of team actually means, and up to considering how you will measure your team’s success.

My conclusion is you cannot just create a high-performing team overnight. A high-performing team has to be built and nurtured. Hopefully, with the skills of a good ScrumMaster or Agile coach you will achieve a high-performing team. And once you’ve got it, keep it together for as long as you possibly can.

Did you miss the 'Why Agile' white paper? Download your copy below.

Get the 'Why Agile' white paper


Images source: Radtac


Alex Gray

Alex Gray

Alex is a professional, versatile and enthusiastic Lean & Agile Trainer/Coach with 20 year’s experience in varied IT projects and roles. A member of the BCS Agile Expert Panel, and an author of the BCS Foundation in Agile Practices syllabus, examination and course materials. Read more