In Scrum, approaches such as self-management and self-organization play a key role in team effectiveness. Though often used interchangeably, these two terms have different meanings and implications for team autonomy. Below, we will take a closer look at these concepts and their application in practice.
Self-Organizing Teams
What are Self-Organizing Teams?
Self-organizing teams can independently structure and organize their actions without external control. The structure, processes, and roles in such teams emerge organically based on the needs and interactions of the team members. Continuous and broad communication is necessary inside self-organizing teams, and creative solutions to complex problems emerge within such teams.
Features of Self-Organizing Teams
- Autonomous approach to work: Teams independently define their workflows and practices.
- Role dynamics: Roles and responsibilities may dynamically evolve depending on the team's needs.
- Internal decision-making: Decision-making processes often emerge from within the team.
- Adaptability: These teams are usually very flexible and capable of quickly adapting to changes.
- Creativity: Unique solutions emerge, often different from the original idea.
Self-Organization in Scrum
The concept of self-organizing teams does not originate from the Scrum framework. It can be found in the article "The New New Product Development Game" from 1986, which became the cornerstone of Scrum.
The self-organizing character of the team produces a unique dynamic or rhythm. [..] As a result, the team begins to work as a unit. At some point, the individual and the whole become inseparable.
The concept of self-organization in the Scrum Guide first appeared in the 2009 version. This version of the guide is more extensive than the latest and provides more explanations. Let’s see what it says about self-organization.
"A new Team often first realizes that it will either sink or swim as a Team, not individually, in this meeting. The Team realizes that it must rely on itself. As it realizes this, it starts to self-organize to take on the characteristics and behavior of a real Team."
— Scrum Guide 2009
"Sink or swim" means that the team will either learn to cooperate or fail as a team. The assumption that time pressure will lead to the development of processes within the team is one of the cornerstones of Scrum, drawn from the article The New New Product Development Game.
A team with a clear goal will go through phases of "someone will tell us what to do," "no one tells us what to do," and "we have to organize this ourselves." Of course, this assumes that the team has all the competencies needed to complete the work (cross-functional) and that the people are motivated to complete the work. The team begins to take responsibility for achieving the goal and will plan the work for the Sprint.
What distinguishes a group of individuals from a team is primarily the shared goal to be achieved. In the 2017 version of the Scrum Guide, it is clearly stated that the team focuses on the Sprint Goal.
"Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.." — Scrum Guide 2017
Developers organize themselves around the Sprint Goal
"The Team self-organizes to assign and undertake the work in the Sprint Backlog, either during the Sprint Planning meeting or just-in-time during the Sprint."
The team organizes its work on an ongoing basis during the Sprint. Just-in-time is an apparent reference to Lean Management.
"Teams are also self-organizing. No one – not even the ScrumMaster – tells the Team how to turn Product Backlog into increments of shippable functionality. The Team figures this out on its own. Each Team member applies his or her expertise to all of the problems. The synergy that results improves the entire Team’s overall efficiency and effectiveness."
Everyone is equally responsible for solving problems and completing work, regardless of their skills. Therefore, it is important that no additional role names or positions appear among developers in Scrum. This way of organizing improves effectiveness in achieving goals and process efficiency. No one imposes solutions or a work plan on the developers.
The Daily Scrum creates pressure and provides an opportunity to plan the next work day. Of course, you can talk and plan anytime outside of the required events.
Where did the Sprint Goal come from? It was established between the Developers and the Product Owner. However, the Product Owner is responsible for the idea for the Sprint Goal and the larger Product Goal, the plan for product development, and the necessary elements (scope). The Developers cannot decide on what they will work on on their own.
Where does self-organization come from?
Self-organization is a natural phenomenon. However, it is worth noting that certain conditions are needed for it to occur. As seen above, two factors are important. There is some pressure that creates a need for self-organization. There is a certain goal toward which the team is organizing itself.
Self-organization in the team
We experience self-organization daily, although we may not be aware of it. A good example is road traffic. Let’s say you want to pick up your child from kindergarten. You have to make it on time (pressure) and cover a certain route. You assume a certain time to complete the route and head out. Other road users want to achieve their own goals. It may turn out that the road is blocked, cyclists are on the road, or traffic is simply slowed. What now? You and other drivers plan how to proceed as efficiently as possible. So, will you drive on the sidewalk? Will you cross the intersection without stopping? Or maybe if you increase your speed in the city to 120 km/h, you'll make it on time? I assume you won’t do that. Why? Because traffic laws apply. We have imposed boundaries of behaviour.
Does a team working in Scrum also have imposed boundaries? Of course. The Scrum framework is essentially a set of boundaries. We must follow the rules described in the guide. Every organization also has specific standards and policies. We cannot ignore or break them, either. The Scrum Master ensures that the boundaries are adhered to.
Self-organization occurs when there are three factors: a goal, pressure, and boundaries.
Self-Managing Teams
What are Self-Managing Teams?
Self-managing teams operate with a high degree of autonomy, making decisions independently of traditional management hierarchy. Self-management is key to empowering teams, allowing them to act faster. Self-managing teams take full responsibility for the outcomes of their work.
Features of Self-Managing Teams
- Independent decision-making: Teams are empowered to make decisions about their work, schedules, and resources.
- Clear structure of responsibility: There is a clear structure of who is responsible for what, but these roles are managed by the team itself.
- Internal accountability: Teams are accountable to themselves for the results of their work. They are responsible to the rest of the organization for the outcomes of their work.
- Greater responsibility and autonomy: Self-management includes decisions on the team's goals.
Self-Management in Scrum
The concept of self-management appeared in the 2020 version of the Scrum Guide.
"Scrum Teams are interdisciplinary, meaning that their members have all the skills needed to create value every Sprint. They are also self-managing, meaning they make decisions independently about who will do what tasks, when, and how." — Scrum Guide 2020 (Polish)
Unfortunately, in the above passage, it is difficult to notice the difference between self-organization and self-management. You have to see that previously it was about self-organization in terms of how to perform the work (who and how), and now it is also about what to do (what?). What is more quickly noticeable is the reference to the Scrum Team instead of the Development Team. And that is a very important change. The Development Team has disappeared. The only team in the Scrum Guide is the Scrum Team.
The Scrum Team consists of the Product Owner, Scrum Master, and Developers. Previously, we talked about self-organization within the planning of work by the Developers. To this, we add ensuring adherence to the framework (Scrum Master) and the decision on what the team should focus on (Product Owner). Overall, the Scrum Team decides what to work on and the boundaries for their activities. Thus, it is a self-managing team. A self-managed team owns and manages its own conditions for self-organizing.
When the Product Owner is appropriately empowered within the organization and can take full responsibility for the development and maintenance of the product, the Scrum Team truly functions as an independent unit.
When the Scrum Master can remove obstacles in the organization or escalate them for resolution, and the team and the organization operate agilely with minimal support, the Scrum Team truly functions as an independent unit.
Benefits of Self-Managing Teams
- Engagement of People: Self-management empowers teams within the organization, which makes them feel more engaged and responsible for their work. The intrinsic motivation of team members is fully utilized.
- Utilization of people's potential: Team members' creativity is fully utilized. Creative solutions emerge that otherwise might not have arisen. The team rarely reports problems because most can be solved by themselves.
- Faster Action: Teams with full control over their actions are able to make quick decisions and act dynamically, which leads to faster product launches. Such teams do not have to wait for decisions or ask for permission. Self-managing teams are also closer to the customer.
Self-managing teams can switch to another topic, goal, or product faster. They do not need as much preparation or input to start work as traditional teams.
Can every organization implement self-managing teams?
Not every organization is ready for self-managing teams. They require a culture of trust, openness, and support for employee autonomy. Challenges include changing organizational culture, providing appropriate support and resources, and developing self-management skills among team members.
If an organization is currently hierarchical with a command-and-control management style, the management team must do a lot of work to transition to self-managing teams. Either the change must start from the top, or at most, we will achieve bubbles of such teams in an organization with a hybrid management model.
There must be a clear delegation of responsibility, not tasks. Servant leadership is needed. Someone must provide resources, remove obstacles, and care for the team's well-being (if the team itself does not do so). In such teams, there will be a fast pace of work and many problems to solve. Conflicts may, therefore, occur more frequently than in traditional teams. There may also be a tendency to avoid difficult decisions or a decision-making paralysis. Management must facilitate this.
Of course, we must remember that problems can also arise on the team side. We need people with internal motivation and strong discipline. Teams must take responsibility. Not every person and team will want to do this. Some people prefer when a manager takes responsibility and pushes the work forward.
Self-organizing teams in some companies may already be a big change, while in others, they may be a stepping stone on the path to self-management.
Conclusion
Understanding the differences between self-organizing and self-managing teams is key to creating effective and autonomous teams within Scrum. Properly utilizing these concepts will certainly allow organizations to reap more benefits from working in Scrum. Self-managing teams lead to greater flexibility, innovation, and productivity within organizations while shortening time-to-market. This is precisely the business agility that every organization strives for.
You can read the original article in Polish here: Samozarządzający się Zespół Scrum