June 15, 2020

People are called a team in Scrum, but are they really a team?

In this blog series I would like to address topics that relate to professional team coaching as well as Professional Scrum. In the course of becoming a Team Coach, I noticed a lot of interesting topics for Scrum Masters who want to improve their coaching stance. 

First of all, I'd like to note that models and terms I am using and discuss are not mine. They come from training and coaching sessions belonging to Vroemen from Teamchange. The connection I make to Scrum is my interpretation. 

Scrum and teams

When organizations start out with Scrum, the first thing they do is form teams. Scrum Teams with Development Teams. Sometimes in one big bang, sometimes from small incremental organizational changes, but it all starts with teams. Teams are the foundation of Scrum. Without this fundamental structure, there is no Scrum. 

But what is a team exactly? When is a group of people a team? What makes them a team? And when a team is put together, what is it based on? Do they even want to be a team? And why might that be important?

Stages of team development

When you put a group of people together in a room, it is not a team yet. There is more to it. They need a shared goal, a common purpose. Whether this is something they work on themselves or get told to do. Even when they have this common goal, does that make them a team? What if these different individuals worked separately on the same goals, is that team work? I can hear you think: "No...". 

This is what is being forced unto a lot of people in organizations. Others decide that a group of people need to work together and they are put together: a Scrum Team is born! Technically you can call this a team. The question is: “Will the sum of the work of these people lead to more value, productivity and synergy than when they would be individuals working on these goals?”

I'm talking about goals and purpose here. However, I've seen a lot of Scrum teams that started out with no goals and no purpose. Just a pile of work. 

This is our starting point.

When we look at teams, we can recognize a couple of different stages. I use Vroemens model of team development stages. He based his model on the work of Katzenbach & Smith. You can read more on his interpretation of his work here.

The purpose of this blog is not to completely go through and explain the model, although I think that could be valuable for a lot of reasons. The reason I want to show this model is to get you thinking about Scrum Teams that are created but are not really a team at all. 

Maybe they don't even have to be. Maybe they are an Allotment Garden Team as Vroemen calls this. They all have their own turf on which they work. They have their own specialism. They work independently of each, they don't need the others in the team in order to finish their work. If a team member didn't finish their work, it might bother them, but equally it may not. It would bother them if someone didn't take care of their weeds which then blows over to another turf - more work for them to do... Maybe they use the same water but to water their plants? But no more.

In a Task Team people are really dependent on each other to be able to do their work and reach their goals. They seek connections, working together, helping each other out more. People in a team can be instructed to work together, but only if they decide for themselves they will actually do so. 

When people at this point are forced from the outside to become a Task Team, chances are they will become a problem team.  

This is an important aspect to realize when you are working within or alongside Scrum Teams, especially if you are the Scrum Master Is it OK for people NOT to be a team? Do they WANT to be part of a team? Do they have a say? 

When we think about a great team, there is something mysterious about it. There is synergy and cohesiveness. Trust. The work of two is more than the sum of their individual work. This is what we look for when we coach a team or when we work in a team. 

Scrum Master and the (team)coaching stance

A lot has been written about the different stances of the Scrum Master. I want to specifically talk about the Scrum Master as a Team Coach. 

By realizing how the team came to be a team can help you as a Scrum Master to guide the team towards more cohesiveness and synergy. This makes the team a safe and joyful place to work. Be aware that by evaluating this, that the team could never have been a Scrum Team, or that there isn't a need for a Scrum Team at all?

I will dedicate a separate article on the Scrum Master as a teamcoach and what pillars are important to guide the team towards more cohesiveness and synergy.

Summary

Not all Scrum Teams start off as a team. This might be because:

1. They do not share a common goal or purpose

and/or

2. They have no dependencies in achieving their goals or doing their work

and/or

3. They had no say in being part of a team

The role of a Scrum Master can be to make these issues transparent and help the team decide what to do next. 

Let's be respectful and talk with people about their needs and abilities. Let's not just bluntly drop everyone in a team and expect the Scrum Master to fix their impediments as they are on their way to become a topteam. Let's not enforce a team onto people, but let all potential team members participate in the choices to be made. It's the first step to a great Scrum Team! 

Thanks to Sjoerd Kranendonk, Mascha Gieling and Steve Trapps for helping me improve this article. And of course Vroemen for the inspiration and knowledge on team coaching.