Developers and Self-Management in Scrum

The 2020 Scrum Guide defines Developers as the people committed to creating any aspect of a usable Increment each Sprint. Often, people misunderstand what 'self-managing' means for them. It is not about doing whatever they want, but about deciding the best way to achieve the Sprint Goal. This distinction is crucial for understanding how effective Scrum Teams operate.

What Self-Management Means

Self-managing means the Developers decide who does what, when, and how. They decide how to turn Product Backlog items into an Increment during the Sprint. The Product Owner decides what to build, and the Scrum Master ensures the process is understood and enacted. But the how of the work, the day to day execution, rests with the Developers. They are not directed by the Product Owner or Scrum Master on specific tasks. They collaborate to find the best path.

Accountabilities, Not Roles

The Scrum Guide eliminated the concept of 'development team' as a sub-team. Now, 'Developers' are one of three accountabilities within the single Scrum Team. This change emphasizes collective responsibility. There are no individual titles like 'tester' or 'architect' within the Scrum Team structure. Everyone with the Developer accountability works towards the Sprint Goal. This fosters a shared ownership of the Increment and encourages cross-functional collaboration.

Daily Scrum and Self-Organization

The Daily Scrum is the primary event for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as needed. It is their meeting. They decide the structure and techniques, as long as it focuses on progress toward the Sprint Goal. This event is a prime example of their self-management in action. They are not reporting to anyone, but coordinating with each other.

During the Daily Scrum, Developers might ask themselves questions like:

• What work do we need to do today to meet the Sprint Goal?
• Who is best placed to tackle which Product Backlog Item or task?
• Are there any impediments preventing us from moving forward?
• Do we need to adjust our plan for the rest of the Sprint?

Impediment Resolution

Self-managing Developers do not wait for permission to solve problems. When they encounter an impediment, they first try to resolve it themselves. If they cannot, they look for help, often from the Scrum Master. The Scrum Master's role here is to remove impediments that are beyond the Developers' self-managing abilities. This does not mean the Scrum Master solves every problem, but rather facilitates their removal.

Impact on Performance

Empowering Developers to self-manage leads to higher engagement, better problem-solving, and ultimately, more effective delivery. When people have autonomy over their work, they are more invested in the outcomes. They make faster decisions, adapt more quickly to change, and often find more innovative solutions than if they were being micromanaged. This trust in their ability to organize their own work is a cornerstone of Scrum's effectiveness.

Start with the Foundations module →

Or take the full Scrum Master track →

Responsibilities of self-managing developers

The single most searched question about this topic is what the responsibilities of self-managing developers actually are. The 2020 Scrum Guide is short on the answer, so here it is in plain terms. Self-managing developers are responsible for creating a plan for the Sprint (the Sprint Backlog), for adapting that plan every day, for instilling quality by adhering to a Definition of Done, for holding each other accountable as professionals, and for making the internal decisions about who does what, when, and how.

Notice what is not on that list. Developers are not responsible for deciding what to build (that is the Product Owner) and are not responsible for enforcing the process (that is the Scrum Master). Self-management is a bounded autonomy, not a free-for-all.

Common misconceptions about self-management

• Self-management does not mean no manager. Line managers still exist for hiring, growth, and compensation. They just do not assign day-to-day tasks inside the Sprint.
• Self-management does not mean consensus. The team can and should make fast decisions. Voting on every ticket kills flow.
• Self-management does not mean chaos. Working agreements, a strong Definition of Done, and a clear Sprint Goal are what make autonomy safe.
• Self-management does not mean the Scrum Master is idle. The Scrum Master coaches the team into self-management and protects it from outside interference.

How to build self-management on a new team

New teams rarely walk in self-managing. They are usually a mix of people used to being assigned work by a project manager. Getting to real self-management is a coaching journey that takes a handful of Sprints.

• Start with a clear Sprint Goal every Sprint. Autonomy without a goal is just improvisation.
• Write down team working agreements and revisit them every retrospective.
• Ban single-assignee tickets for the first month; force pairing so knowledge spreads.
• Let the team run the Daily Scrum without the Scrum Master in the room once trust exists.
• Track how many decisions the team made this Sprint without escalation. That number is the real self-management metric.

By Sprint five or six, most teams that go through this pattern stop asking permission and start owning outcomes. That is the shift you are trying to unlock.