Scrum Teams are self-managing, so they decide internally who does what, when and how. The decision sits with the people doing the work rather than with anyone outside them, and the Product Owner and Scrum Master are inside the team rather than above it.
Self-organising became self-managing
Earlier editions said 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 says self-managing, and applies it to the whole Scrum Team.
The change is about the scope of the decision rather than the amount of freedom. Self-organising describes how a group arranges itself around work it has been handed, while self-management includes deciding what the work of the Sprint will be, within the objective the team has agreed. Applying the word to the whole Scrum Team also removes 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, so a team that has grown an internal tier of leads who distribute work is not the thing the Guide describes, however Scrum shaped its events look.
The boundaries it 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.
Read together, those say a Scrum Team owns how and largely who, and shares what with the Product Owner. A team deciding to skip the Definition of Done for one Sprint is not exercising self-management. It is discarding a commitment, and the distinction is what scenario questions here usually turn on.
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 manager outside the team, because assigning tasks moves the decision about how work gets done away from the people doing it.
The reason is practical rather than ideological. The person closest to the work knows most about it, so an assignment made from outside is made with less information, is more often wrong, and removes the local ability to correct it. Teams handed their work also stop volunteering for it, since responsibility for the choice has moved elsewhere.
None of this means work goes unassigned. It means the assignment happens inside the team, often at the Daily Scrum, and can be revised the next day by the people it affects.
The Scrum Master's part in it
The Scrum Master serves the Scrum Team by coaching it in self-management and cross-functionality, helping it focus on high value Increments, and causing the removal of impediments. Every one of those verbs is indirect on purpose. Assigning tasks, running the Daily Scrum as a status meeting, or reporting on individuals all sit outside them.
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 lasts only as long as the supervision. The slower route is coaching, making the impediment visible, and removing what the team cannot remove 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 for it to be real.
- Assigning individuals to tasks from outside, including through a plan that names who does what.
- Requiring approval before the team may change how it works.
- Measuring individuals on personal output rather than the team on its outcomes.
- 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 whose job is the system the team works in rather than the distribution of its work, which is a real job and a different one. 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.