The Scrum Team is Self-Managing
The more Scrum Teams are empowered to make and own decisions about their work, the more benefits they will realize.
The Scrum Guide gets an update
The 2017 version of the Scrum Guide said the following about the Scrum Team:
"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 the team."
The 2020 Scrum Guide was updated to say:
"Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how."
In effect, little has changed. Scrum Teams have always had the most opportunity for success when they are treated as professionals to make choices about their work, rather than have choices made for them. It is the empowerment of Scrum Teams to manage their work towards a common goal that gives organizations more agility when solving complex problems and producing high-quality results. Scrum Teams need to know they get to make decisions about their work - what that work is, when it is done, and how it is accomplished - and will be held to account for those decisions.
The 2020 update explicitly states the Scrum Team decides "what" and "when" work gets done. To be honest, this was always the case in Scrum. A combination of the Product Owner's ordering of the Product Backlog along with the team's forecast of work each Sprint established these "what" and "when" criteria. I am happy to see this more specifically called out. I believe it will help more people and organizations who adopt Scrum understand the scope of responsibility we ask Scrum Teams to take on and what environmental considerations we have to help them be successful.
What's in a word
If little has changed in practice, then what's so important about the change from "self-organization" to "self-management?" For one, it's more clear what is expected of the Scrum Team.
Whether the word "manager" is in your job title or not, everybody manages something in their work. People often think about management as the direction one person has over another person. Yet, people also manage schedules, time, finances, adherence to standards, production and process flows, resources (actual resources, not people), product releases, and more. In Scrum, the Product Owner manages the Product Backlog, Scrum Masters manage Scrum's effectiveness, and Developers manage how Increments are created. There are many product-related activities Scrum Teams take on, and they collectively manage all of the work required to do it. This has been the case in Scrum for some time. By explicitly calling out that the Scrum Team must take responsibility for this management, we are clear with what to expect of them and what must be given to be successful.
What about the self-management of people-related managerial topics, things like time off, professional development, conflict management, salaries, job titles and organizational structure, and so on? I would say these topics fall under self-governance instead of self-management. Scrum does not require the Scrum Team to be self-governing, nor does it forbid it. Each organization has a different appetite for what it gives and retains control over for the governance of its people, and that's okay. Sometimes a Scrum Team is hired and assembled fully by an organization without any input from the Scrum Team members, and there's nothing in Scrum preventing that. Likewise, there is nothing in Scrum that prevents a group of people from forming their own Scrum Team and organizing themselves into a structure that gives them their best shot at achieving the organization's goals. Often, the people closest to the problem will know the most about it and how to work it, though they sometimes get stuck and need a little reflection or guidance from an outside observer. Ken Schwaber wrote about these nudges and the power of letting teams form on their own, and Management 3.0 reflects on delegation and empowerment to set up explicit constraints and boundaries for systems like teams to be effective.
Let's come back around to the term "self-organization," sometimes also referred to as "self-designing." The term "self-organization" has uses in philosophy, cybernetics, biology, chemistry, systems theory, and more. The agile space co-opted this term for its means and added further definition to it. As with the concepts of people-related management above, some took "self-organization" to mean that a Scrum Team must be allowed to run the organization. In a 2010 blog post, Esther Derby noted this confusion of terms and the considerations organizations need to take when empowering teams. Again, Scrum does not require this, nor does Scrum forbid it. There can be power letting the people who are part of the organization help make decisions about their organization. After all, they were selected/hired and trusted to help the organization be successful in its objectives.
If "organizing" is the arrangement of elements into a whole, then "self-organization" is the act of this arrangement without external guidance. Applying that to people, we're talking about allowing people to form a structure that works for them. Simply put, when you have a big, complex problem - the kind Scrum is designed for - and a bunch of people capable of working a solution to that problem, one of the best things you can do is get out of their way and let the professionals get to work. The more you impose structure on work from the outside, the more you're getting in the way.
Scrum still supports self-organization
Gunther Verheyen, a fellow Professional Scrum Trainer, defines self-organization as, "The process of people forming organized groups around problems or challenges without external work plans or instructions being imposed on them."
When I look at that definition, I see organization ("...people forming organized groups...") and self-management ("...without external work plans or instructions being imposed on them..."), and yet there is one more part that stands out to me. When I read "...around problems or challenges," I think of both the constraints upon these groups and the purpose that binds them. While the Scrum Team is self-managing, the timeboxes, elements, etc., of the framework (providing constraints) and the Sprint Goal and Product Goal (providing purpose) help fulfill the definition of self-organization. The definition of self-organization in The New New Product Development Game seems to support this as well. In effect, self-organization was not removed from Scrum. The 2020 Scrum Guide just made the Scrum Team's properties clearer and provided a framework for self-organization to occur.
Self-management is the minimum bar. Scrum Teams can still be self-organizing, self-designing, or even self-governing if the situation allows, and supporting such constructs can provide immense benefit. Remember, Scrum is a framework. It gives the scaffolding for people, teams, and organizations to generate value through adaptive solutions to complex problems. The Scrum Guide only states what is required for Scrum, and ideally, nothing else.
Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.
Go and help your people unleash their collective intelligence.