Only one out of every seven Scrum teams is self-organising, according to the State of Scrum survey. That is a shockingly low number as it means a lot of organisations miss out on a significant part of the benefits of agile!
“The best architectures, requirements, and designs emerge from self-organizing teams”.
So says the Agile Manifesto. In this blog post, I will look at what this “self-organisation” is about and how to get it going.
Different degrees of self-organisation
Self-organising teams is a fairly wide term and comes in different degrees:
- Traditional manager-led teams, where a manager assigns tasks and manage the work process are not normally considered to be self-organising. Still, they tend to have a slight degree of self-organisation to them. If only when it comes to how the individuals execute their given tasks.
- Self-managing teams are not only responsible for completing their tasks but also coordinating between themselves who does what. They are also responsible for monitoring their progress and re-organise the work and adjust their process as necessary, based on that progress or lack thereof.
- Self-designing teams take the self-organisation to the next level. They choose not only who does what but who is on the team as well. Typically, this starts with a self-selection workshop where the people involved agree what teams are needed, what roles and skills are needed for each team and then choose themselves which team they want to be in. As the work progresses and they learn more, they can later adjust the make-up of the teams as they see fit.
- Self-governing teams is the highest degree of self-organisation and basically gets rid of all levels of management. No one tells anyone else what to do. Anyone can come up with an idea and invite others to join a new team to deliver it. The vision of the company does not come from a founder or CEO but from the employees themselves. So far, very few companies operate in this way but the Swedish software consultancy company Crisp is one example.
In this article, I will be focusing on self-managing teams. This is the most common form of self-organisation practiced by Scrum teams and is a starting point for any further degree of self-organisation.
Autonomy leads to increased efficiency
Putting the team in charge of their process empowers them to find the ways of working that suits them. After all, they are the people closest to the work. Therefore, they are best positioned to judge what works or not.
However, with power comes also responsibility. It’s no longer good enough to say “I did what I was told, so it’s not my fault” or to blame the process when something fails. If the process isn’t perfect (and it never is!), it is up to the team to improve it.
- Autonomy creates more motivated team members. Take yourself as an example. What do you prefer? Being told exactly what to do or deciding yourself how to tackle something? Autonomy is one of the most important factors for motivating people, according to Dan Pink in his book Drive – The Surprising Truth About What Motivates Us and the corresponding Ted talk.
- Motivated team members generate better results. When someone cares about the outcome, they will deliver the work to a higher standard.
- Better collaboration, learning faster and responding quicker. Again, the team are closest to the action. Having to wait for a manager to generate insights and make decisions will slow them down.
How to establish self-managing teams
We can’t force self-management upon the team. Ordering someone to be self-managing would be self-contradicting to say the least! Instead, we need to create an environment where self-management can happen.
We need several ingredients to create such an environment:
- Small, stable teams
- Talented team members
- A shared goal
- Appropriate constraints
- Embracing continuous improvement
Let’s look at each of these in more detail!
Small, stable teams
To make the right decisions, people need to have the relevant information. The members of self-managing teams are no different. They need to know what the others on the team are up to. That’s the only way they can organise the work between them in the most effective way.
A self-managing team will fail or succeed based on how well the communication between the team members is working. The bigger the team is, the harder the communication will get. If you work on a team with three other people, you need 15 minutes to talk to each one of your team mates for five minutes. If I work on a team with 20 people, I will need more than an hour and a half to do the same. Just imagine how much harder it would be for me to keep track of what the others are up to!
Similarly, people need to get a chance to get to know each other well enough. When they learn what skills and little quirks the others have is when they will know who, how and when to ask for – or offer – help.
Talented team members
A team made up of very inexperienced team members or people with limited skills will struggle to self-manage. Without the appropriate skills and experience, it is very hard to know what is likely to work and what isn’t.
When the team members don’t have sufficient experience or skills, they need appropriate training and support before they can become self-managing.
However, let me just make very clear that this doesn’t mean that everyone in the team must be highly experienced. We all have a responsibility to make sure those who are new to the industry get a chance to get that valuable experience. A mix of skills and experience can even be beneficial to the team, as those who have been doing something for a long time may be stuck in their tracks and someone with less experience can bring a new perspective.
A shared goal
Self-managing teams are responsible for making many of the tactical decisions. This makes it more important than ever that the product owner has a clear vision for the product and can communicate that vision to the team. It’s simply not good enough for a product owner to keep the vision to themselves and drip-feed requirements to the team. Otherwise, people will end up pulling in different directions.
After all, self-management doesn’t mean that everyone can do whatever they feel like. They still serve a greater purpose. Only through understanding that purpose can team members ensure that their decisions get them closer to the goal.
The team needs clarity which decisions they can or cannot make. A team without clear boundaries can easily overstep their responsibilities without realising. This could easily move them out of sync with the rest of the organisation and the bigger vision. However, perhaps even more likely, a team not knowing what they are allowed to do can end up taking an over-cautious approach, out of fear of making decisions they shouldn’t.
Another important constraint is for the product owner to clarify the boundaries of the self-management. Which decisions can the team make themselves about the product and which will the product owner make?
Self-managing teams must be responsible for their own success. For self-management to not just being a pointless buzzword, the teams need to be allowed to fail. A team will never become truly self-managing if someone steps in and solves problems for the team whenever they arise. It doesn’t matter whether it is a traditional manager, a scrum master or a product owner. Why should the team bother organising themselves if someone overrules their decisions as soon as there is a potential problem?
The thought of failure may scare both managers and the team itself but luckily, Scrum provides several safety mechanisms:
- The team monitor their progress towards the sprint goal. In the daily scrum, they can adjust their plan based on how things are going.
- The product owner should be available to answer questions throughout the sprint and to clarify misunderstandings about the requirements.
- In the sprint review, the product owner and customer inspect the resulting working software. Even if it is hopelessly wrong, the team should never end up wasting much more than a sprint’s worth of effort.
- In the sprint retrospective, the team looks at what went well and what didn’t. This way, they improve their way of working and learn from mistakes ahead of the next sprint.
Rome wasn’t built in a day. It would be quite a shock for any team to suddenly be left to their own devices. Just stepping away could create a management vacuum. That could either lead to chaos or to someone like as a senior developer stepping in and taking the role as manager. Neither would result in good self-management.
When the team members are not used to working in self-managing teams, they will need support to get going. This would typically be provided by the Scrum Master (or even an agile coach). However, as we saw above, they mustn’t make decisions for the team. Instead, the scrum master should help the team realise when a decision is needed and help them make the decision themselves.
I have also seen how some people like being told what to do. It makes them feel safe. No longer getting the steer they need can make them feel fear and uncertainty. Consequently, these people will need extra support to find their place in the self-managing team. Ultimately, it may even turn out that they may not be the right people to work in such a team.
Finally, a self-organising team will never come up with the perfect solution straight from the start. Neither would a traditional manager! That’s not the point.
Sometimes the team will implement fantastic solutions. Sometimes they will do things that don’t work very well at all. Most likely, the solutions will be somewhere in-between; not a disaster but they could be better.
That’s why self-managing teams need continuous improvement to reach their potential. Self-management is not just something that happens once and we’re done. It takes hard work to get going and to keep it going.