A Week-One Checklist for a Self-Managing Developer Team
The 2020 Scrum Guide dropped the word "self-organizing" in favour of "self-managing," and the change was not cosmetic. A self-managing Scrum Team decides who does the work, how it gets done, and how to improve along the way. For the Developers specifically, that means owning the Sprint Backlog and the daily plan to meet the Sprint Goal. Two years into pandemic recovery, with many teams still split across home offices and time zones, that ownership matters more than ever: you cannot lean over a desk to unblock a colleague, so the team has to manage itself by design rather than by proximity.
Self-management is not the absence of accountability. The Scrum Team is still accountable for a usable Increment every Sprint. The point is that authority sits with the people doing the work, not with a manager assigning tasks from outside. Below is a concrete checklist a Developer team can run this week to see how close it actually is to self-managing.
The week-one checklist
Pull, don't receive. Confirm that Developers select work from the Sprint Backlog themselves rather than having items handed out. If a lead is still allocating tasks, that is the first habit to retire.
Make the Sprint Goal visible. Write the single Sprint Goal where everyone sees it daily. Self-management without a shared objective just produces busy people moving in different directions.
Run the Daily Scrum for the Developers. It is a 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the plan — not a status report to a manager. If it has become a check-in for someone else, reclaim it.
Surface blockers within a day. Agree that any impediment is raised the same day it appears, in writing in your shared channel. Remote teams lose days to silent blockers that a co-located team would have spotted in an hour.
Decide your Definition of Done together. If quality criteria live only in one person's head, the team is not managing quality collectively. Write the Definition of Done down and apply it to every item.
Rotate the awkward work. Deployment, code review, on-call, documentation — share these deliberately so knowledge does not pool in one person who becomes a single point of failure.
Protect a real Retrospective. End the Sprint by choosing one improvement the Developers will actually try next Sprint. One acted-on change beats ten logged and forgotten.
What gets in the way
Two patterns quietly undermine self-management. The first is a manager or senior Developer who keeps making decisions the team is meant to own; the cure is to ask, every time, "could the Developers decide this themselves?" and to step back when the answer is yes. The second is a hybrid setup where the people in the room make the calls and remote colleagues hear about them later. Decide the rule once: if a decision affects the team, it happens in a channel everyone can see, or it does not happen.
Run the checklist as a Sprint experiment, not a mandate. Pick two or three items that feel weakest, try them for one Sprint, and inspect the result in your Retrospective. Self-management is built one honest adjustment at a time, and the teams that practise it are far steadier when the work — or the world — gets disrupted.
When a delivery team needs help turning these habits into dependable outcomes across a wider program, XNM's program & project delivery advisory can help you set it up and make it stick.