One interesting change to the Scrum Guide for the 2020 release was the change of the term Self-Organizing to Self-Managing. In the 2017 version of the Scrum Guide Self-Organization is described as:
“Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside of the team.”
Another 3 references highlighted how self-organizing is important for the Development Team when planning work, and during the Daily Scrum.
In the 2020 version of the Guide, there is no longer a Development Team, but instead, a whole Scrum Team which includes accountabilities including those for Developers, and when talking about the Scrum Team self-managing is described as:
“They are also self-managing, meaning they internally decide who does what, when, and how.”
Other references include how the Scrum Master should support the team being self-managed, and the relationship with the Sprint Goal.
In common practice, the terms self-organizing and self-management are often used interchangeably. In fact, there are many definitions that describe each term in the same way. For example, see Steve Dennings definition vs the Business Process Incubators definition. The reality is that both terms come with baggage and history. For some self-organization only describes how the team is organized and how they organize the work. For others, it describes empowering the team to do whatever is required to deliver a valuable increment.
The opportunity that the change provides
Ignoring the history of the phrase and the opportunity for debate we can focus on the intent of this style of work. Scrum has always required teams to be able to do what it takes to deliver a valuable Increment. In the 2017 version of the Scrum Guide, this was described in two areas. First, when describing the Scrum Team they “choose how best to accomplish their work, rather than being directed by others outside the team.” And then when describing the Development Team, “Development Teams are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.” With the refactoring of the Development Team and the focus on one Scrum Team, the Scrum Guide has increased the clarity of the importance of empowered teams, focused on goals. With the Scrum Team being accountable for delivering a valuable Increment and the addition of a Product Goal, both of these changes highlight the importance of one Scrum Team focused on one Product Backlog in pursuit of a Product Goal. The change to self-managed seems a natural addition to this objective and highlights that the Scrum Team has the ability to not only organize the work but also decide who (is doing the work within the team), what, when, and how. Scrum always encouraged that approach and the new Scrum Guide provides extra clarity. In addition, the term management implies a level of discipline which makes sense as the Scrum Team responds to the opportunity.
This does not mean there are no managers
Scrum does not say if there are managers or no managers. The term self-management describes how the Scrum Team should work. Depending on the context this might require managers outside of the Scrum Team doing work in support of the Scrum Team. It might mean that people with the title manager are in the Scrum Team working on the Increment. Scrum is focused on delivering incremental value in pursuit of a Product Goal, it does not describe how outside of that context you should structure your organization and what job titles people should have. Scrum will, as it always has, encourage teams to challenge any management interference if it does not align to the Product Goal and help the team deliver value.
Does this mean that Scrum Teams do all the tasks traditionally owned by managers?
Again Scrum is silent on this because it does not know what tasks your manager, in your context does, or understand your organizational structure. Instead, it describes the idea that the Scrum Team, who is accountable for delivering useful, valuable increments, has the opportunity to do what it takes to deliver that value.
The bottom line is that what the Scrum Team does or what it doesn’t do to deliver value will vary depending on your context. The Scrum Guide highlights that if you want Scrum to succeed the Scrum Team needs to have the freedom to take ownership of how what, and when the work gets done.