Teams hold a special status in agile. Teams are at the heart of all agile frameworks and much of the focus of the agile community is on growing and supporting teams. Not just any teams, agile teams stress things like self organisation and cross functionality. There is no denying that a really good agile team is an awesome sight to behold. The amount of stuff they can get done is nothing short of remarkable. But there are also an awful lot of agile teams that have the same properties but their performance isn't anywhere near as good. So what is wrong with those teams? Is it the people? Is it the environment? Is it the nature of the work? What stops some teams from performing where others with the same characteristics flourish?

In an effort to understand why, I have been thinking deeply about the concept of the team; why they are so effective and why we insist on certain characteristics for our agile teams. The conclusion I have come to is that it's all about the ability to make decisions.

All knowledge work involves a constant stream of decisions. Very few of these decisions can be made by one person. A coder may decide line by line how to structure their code but they need the input of a tester to assess whether the chosen structure is testable, a peer review to see whether the code is solid, an architect to see if it matches the chosen design patterns and a business person to see if it delivers the value it is supposed to deliver.

The faster all these decisions can be made, the faster progress will be. The reason teams are so successful is that a small, co-located, cross-functional team is simply the fastest possible way to make the decisions. Small, because it limits the number of communication paths needed. Cross-functional because it prevents single person bottlenecks. Co-located because face to face communication is far more efficient, and therefore faster, at conveying information than anything else. This is the secret sauce behind a successful agile team.

A successful team has all the people needed to make decisions in one compact unit that communicates well. Yes, a single person could make decisions more quickly but only in their particular area of expertise. For any complex piece of work, a team is required.

As soon as a team needs to rely on outsiders to make decisions, that productivity will drop. This, I believe, is the key to those non-performing agile teams - they can't make the decisions they need to make in order to get things done. They are constrained by something and forced to go outside the team for decision making.

It could be a lack of skills. Maybe they need specialist advice on something. A DBA or other technical specialist. This happens all the time, even in really good teams. The difference is that in a well functioning team it's a rare event. In many teams this happens all the time. As soon as a decision needs to go outside the team it will result in a delay. One of the signs of a really good team is that they will flag these outside decisions as impediments and make sure they are followed up quickly. However many teams just view them as part of getting things done and live with the delays caused.

Most likely it's not a lack of skill though. Most of the time, the team has the skills needed to make the majority of its decisions. What they lack is the empowerment. The system prevents them from making decisions that they are perfectly capable of making. Can the product owner prioritise the backlog or do they need to constantly consult with stakeholders? Can the coder make design decisions or do they need to be ratified by architecture? Do they have the technical specialists they need on the team or are they locked away in organisational silos? Do they need information that isn't freely available? Are they perfectly capable of making the decision in-team but are bound by convention to defer to others? Is the team empowered to make the decision but doesn't feel confident enough to do so?

When you have an agile team that isn't performing as well as they could, take a look at the decisions they are making. How many of them need to go outside the team and why? This is a really good topic for the team's retrospective. Look for root causes and work out how to bring those decisions in-team.

Look at the most common decisions first and solve those. If they need skills, get them those skills. If they need information, make sure the information is available. If they need management support to change the process, get them that support.

Start to track outside decisions as impediments. Track how much time is consumed by them. This will help you build your case for change.

Unlock the power of your teams by unlocking their power to make decisions.