Self-managing teams: who decides what

"We are a self-organising team" is a phrase that has been used to defend both excellent practice and plain chaos. The Scrum Guide uses a more careful word, self-managing, and defines it in one sentence. Once you read that sentence closely, a lot of arguments about autonomy get shorter.

What the Guide says

Scrum Teams, the Guide says, are cross-functional and self-managing, meaning they internally decide who does what, when and how. The fuller passage adds that the team is "structured and empowered by the organization to manage their own work", and that working in Sprints at a sustainable pace improves focus and consistency.

Three details are worth noticing. The word is self-managing, which the 2020 edition chose in place of the older self-organising, to stress that the team decides how its work is managed and not only how it is arranged. Second, the empowerment comes from the organisation. A team does not become self-managing by announcing it. Third, the four decisions named are who, what, when and how. The Product Owner's accountability for ordering the backlog is not on the list, and that matters later.

The SBOK® Guide arrives at a similar place by another route. It names self-organisation as one of its six principles, built on the belief that people are self-motivated and deliver greater value when self-organised. It prefers what it calls supporting leadership, and adds a caution that self-organisation does not mean team members may act in any manner they want.

Who decides what

A simple split removes most confusion. These are the decisions that belong to each party in the Guide's model.

The last row is the one teams forget. A self-managing team works inside constraints that someone else sets. If the organisation's standard for security reviews says every release needs a sign-off, the Definition of Done must include it, and the team cannot declare itself exempt. The Guide says that if the Definition of Done is part of the organisation's standards, all Scrum Teams must follow it as a minimum.

A worked example: choosing tasks on Monday morning

This is an illustrative case. A team of five has just finished Sprint Planning. The Sprint Backlog has four items and fourteen tasks. Under a directing manager, the manager would assign tasks by name that afternoon, and update a spreadsheet.

In a self-managing team, the Developers look at the board together. One person who knows the payment service takes the riskiest integration task first. Another, who has not touched that area, pairs with them to learn it. A third notices that two tasks depend on an unfinished decision and asks the Product Owner a question. By the first Daily Scrum the board shows who is doing what, and the plan has already adapted once.

Nobody outside the team was needed for any of that. If the first task proves harder than expected, the Developers re-plan at the next Daily Scrum without asking for permission. Their decisions are visible on the Sprint Backlog, so the Product Owner and the Scrum Master can see what is happening and step in where their accountabilities apply.

The SBOK describes the same picture in its own terms: team members are responsible for determining what work they will do during task identification and estimation, and they resolve problems together at the Daily Standup.

Why the Guide cares

The reason is not fashion. The Guide ties self-management to adaptation: adaptation becomes more difficult when the people involved are not empowered or self-managing, and a Scrum Team is expected to adapt the moment it learns anything new through inspection. If every change to the plan must travel up a chain of approvals, the team learns on Tuesday and adapts on the following Monday, and the inspection has lost most of its value. Self-management is what keeps the loop short enough to matter.

What it takes to work

Self-management is not a switch. It depends on conditions the team and the organisation must create.

First, clarity of goals. A team that does not know the Sprint Goal has no basis for choosing between tasks. Second, skills and information: the team needs enough breadth to act without waiting for outsiders. See cross-functional teams. Third, trust from managers, who must stop assigning work and start asking about obstacles. Fourth, feedback that is fast enough to correct mistakes. The Agile Manifesto states the underlying belief: the best architectures, requirements and designs emerge from self-organising teams, and projects should be built around motivated individuals who are given the environment and support they need and trusted to get the job done.

The Scrum Master's job here is to coach the team in self-management, as the Guide says, and to work on the organisational conditions. That includes explaining to managers why they should not assign tasks. See the Scrum Master role.

Common mistakes

• Taking autonomy as the absence of rules. The framework's rules, the Definition of Done and the Sprint Goal bind the team as much as anyone.
• Letting the strongest voice decide. Self-managing teams still need a way to reach decisions. Some use consent, some vote. The Guide does not prescribe one.
• Having a hidden manager. If a technical lead assigns every task, the team is not self-managing even if the title is different.
• Putting everything to a vote. The Product Owner is one person. Voting on the order of the backlog removes the accountability the Guide establishes.
• Expecting it to work from day one. Teams usually need several Sprints to build the habits.

How to practise it

Look at your last Sprint and list five decisions the team made about its own work and five it did not. If the second list is full of items the team could easily have made, there is room to widen the circle. In the simulator the Developers' choices are yours to make, and you see the effect when you decide too little or too much.