Scrum Teams are self-managing, meaning they internally decide who does what, when and how. The word internally is doing real work there, because the Product Owner and the Scrum Master are both inside the Scrum Team, while a functional manager holding a resource plan is outside it and has no part in the decision.
Self-organising became self-managing
Earlier editions used self-organising and applied it to the Development Team, whose members chose how best to accomplish their work rather than being directed by others outside the team. The 2020 Guide replaced that word with self-managing and applied it to the whole Scrum Team.
What changed is the scope of the decision. Self-organising describes how a group arranges itself around work it has been handed, while self-management reaches further and includes deciding what the work of the Sprint will be, inside the objective the team has agreed. Applying the word to the whole Scrum Team also closes off the old reading in which a Product Owner stood outside a development team and directed it.
The same edition describes one team focused on one objective, with no sub teams and no hierarchies. A team that has grown an internal tier of leads who distribute work has therefore stopped matching the Guide, however closely its events still follow the calendar.
The boundaries self-management works inside
Self-management is not unlimited freedom, and the boundaries are the parts of Scrum a team does not get to set aside.
- The Sprint Goal fixes what the Sprint is for, so the plan may change and the objective may not.
- The Definition of Done fixes the quality the Increment must reach, and the Developers are required to conform to it.
- The order of the Product Backlog belongs to the Product Owner, so reaching past the top of the list for more interesting work is not a decision the team owns.
Taken together, those three say that a Scrum Team owns how it does the work, owns most of who does which part, and shares what gets built with the Product Owner. A team deciding to skip the Definition of Done for one Sprint has discarded a commitment, and scenario questions on this subject usually turn on that distinction.
Nobody assigns work to the Developers
Only the Developers select Product Backlog items into the Sprint Backlog, and only they decide who picks up what. That holds for the Scrum Master and the Product Owner exactly as it holds for a delivery manager outside the team, because an assignment arriving from anywhere else moves the decision away from the people who will carry it out.
The reason for the rule is practical. The person closest to the work knows most about it, so a decision taken from outside rests on less information, goes wrong more often and leaves nobody nearby able to correct it. A team handed its work also stops volunteering for it, because the responsibility for the choice has moved somewhere else.
None of this leaves work unassigned. The assignment happens inside the team, often during the Daily Scrum, and the people it affects can change it the next day.
The Scrum Master's part in self-management
The Scrum Master serves the Scrum Team by coaching it in self-management and cross-functionality, by helping it focus on high value Increments and by causing the removal of impediments. Every one of those verbs is indirect on purpose, because a Scrum Master who acted directly would be taking the decisions the team exists to take. Assigning tasks, running the Daily Scrum as a status meeting and reporting on named people all sit outside the accountability.
A struggling team is the case that tests this. The tempting answer is supervision until performance recovers, which removes the mechanism the team would have used to recover and holds only for as long as the supervision lasts. The slower route is coaching the team, making the impediment visible and clearing whatever the team cannot clear for itself.
What the organisation has to stop doing
Self-management is a property of the environment as much as of the team, and it usually fails on the organisational side. Several habits have to go before a team can manage itself.
- Assigning people to tasks from outside, including through a plan that names who does what.
- Requiring approval before the team may change how it works.
- Measuring each person on personal output, which leaves the team's outcome unmeasured.
- Moving people between teams to fill a resource plan.
- Committing the team to scope and dates on its behalf.
What survives that list is a manager who owns the system the team works inside, which covers funding, dependencies, tooling and the standards the organisation sets. That is a real job, and distributing the team's work is no part of it. The Guide says nothing about where such managers sit or what they are called, because Scrum describes a team inside an organisation without redesigning the organisation around it.