← All articles

Developers as a Self-Managing Team: What Good Looks Like vs What Bad Looks Like

By XNM Technologies · March 30, 2022 · 3 min read
Developers as a Self-Managing Team: What Good Looks Like vs What Bad Looks Like

The 2020 Scrum Guide is unambiguous: Developers are accountable for creating a plan for the Sprint (the Sprint Backlog), instilling quality by adhering to a Definition of Done, adapting their plan each day toward the Sprint Goal, and holding each other accountable as professionals. In other words, self-management is not a nice-to-have feature of a mature Scrum Team — it is the baseline expectation. In practice, many teams called Scrum Teams are closer to task-assignment groups: they wait to be told what to do, divide work by individual ownership, and hand problems upward rather than solving them. The contrasts below identify the signals that distinguish a self-managing team from one that only performs the rituals.

What Good Looks Like

  • The Sprint Goal is understood by every Developer and drives daily decision-making. When a Developer faces a trade-off during the Sprint, they ask which option best serves the Sprint Goal — not which option covers their assigned task.

  • The team pulls work from the Sprint Backlog rather than receiving assignments. No one owns a story in isolation; the team owns the Sprint. Developers pick up work based on current capacity and where they can best contribute, not based on their functional specialty alone.

  • Impediments are raised in the Daily Scrum and owned immediately. A self-managing team does not wait for the Scrum Master to notice a blocker and fix it. The team identifies the problem, assigns ownership of resolution within the team, and escalates to the Scrum Master only when the impediment is beyond the team's authority to remove.

  • The team pushes back on unrealistic Sprint scope during planning. A self-managing team uses Sprint Planning to build a realistic Sprint Backlog and commits to what it can actually deliver. It does not accept a Sprint scope it cannot achieve and then under-deliver silently.

  • Quality is enforced collectively. When a Developer notices that an item does not meet the Definition of Done, they raise it — regardless of who built it. Collective ownership of quality is one of the most visible markers of team self-management.

What Bad Looks Like

  • The Scrum Master or Product Owner assigns tasks to specific Developers at Sprint Planning or during the Sprint. This is the single clearest sign that a team is not self-managing.

  • Developers report their status to the Scrum Master at the Daily Scrum rather than coordinating with each other. The Daily Scrum becomes a standup report to a superior instead of a planning meeting among peers.

  • The team waits for guidance when it hits an unexpected situation. A self-managing team adapts. A team waiting to be managed pauses and escalates immediately, even for decisions it could make itself.

  • Cross-functional work is avoided. "That is not my area" is a phrase that does not belong in a self-managing Scrum Team. A Scrum Team must contain the skills needed to deliver, and those skills are applied collectively based on need, not assigned by specialty.

  • The Sprint Goal is not mentioned after Sprint Planning. If the Sprint Goal disappears from the conversation until the Sprint Review, the team is managing tasks, not outcomes.

The Transition Is a Coaching Problem

Moving a team from task-assignment mode to genuine self-management takes deliberate coaching. The Scrum Master's role is to create the conditions for self-management — which means, among other things, resisting the impulse to answer every question the team could answer themselves, escalating organisational impediments rather than absorbing them quietly, and ensuring that the Product Owner provides clear goals rather than detailed instructions. A team that has never been allowed to self-manage will not do so simply because the process is called Scrum.

XNM helps public-sector and capital-project organisations build effective agile delivery teams, including coaching toward genuine self-management and Scrum implementation. Connect with XNM's program & project delivery advisory team to discuss how structured Scrum coaching could strengthen your team.