Supporting complex work by promoting the team's autonomy
Why does Scrum require Self-Managing Teams?
When teams are faced with complex problems (where more is unknown than known), or given the responsibility to create an innovative product, they are rarely able to succeed by following someone’s specific instructions. After all, by its very nature there is no clear way to solve the problem, there are no recipes to follow. The team can only arrive at the solution by experimenting their way to it. They must create hypotheses, determine how to test their hypothesis and act on the insights they uncovered through their experimentation.
The best way to support a team working this way is to give them the space to determine how to do their work, rather than directing them. This space and empowerment is the essence of self-management.
What are Self-Managing Teams?
Self-managing teams are those who are given the autonomy to manage their own work. They determine what to do, who should do it and when it should be done. Agile leaders recognize that their role is not to “manage” the team, but to create the conditions that enable or support their team’s ability to manage itself… and then get out of their way!
For self-management to thrive, there must be:
- Clear goals - The Scrum framework includes two important goals: the Product Goal and Sprint Goal. But, these aren’t the only goals we’re talking about here. In order for a Scrum Team to understand what to do, they must be clear on why they are doing it. Why has the team been formed? What problem are they being asked to solve?
- Clear boundaries - Teams are provided the autonomy to make their own decisions. Understanding which decisions the team can make on their own and which they cannot is key for self-management. Some decisions may have already been made and are out of the team’s hands. For example, there may be organizational constraints such as the budget set aside to support the effort, privacy regulations such as GDPR, security protocols and compliance constraints set by governmental regulations.
- Clear accountabilities - Every member of the team has a role to play achieving the team’s objectives. Understanding who is accountable for achieving various outcomes helps the team focus on the work.
It’s also important for a self-managing team to be cross-functional and have the skills necessary to perform their day-to-day work without constantly relying on colleagues outside of the team. Not having the necessary skills on the team reduces the team’s autonomy and ability to optimally manage their own work.This may require training Scrum Team members in new skills, so that team members can jump in to pick up work at any given time.
The Scrum framework provides guidance to enable self-management. For example, it describes:
- Goals such as the Product Goal and Sprint Goal
- Boundaries around how to organize the work, such as making the work transparent (the Product and Sprint Backlogs) and providing Events to enhance communication and collaboration
- Accountabilities within Scrum supported by the Scrum Master, Product Owner and Developers
Characteristics of Self-Managing Scrum Teams
As we mentioned previously, self-managing teams determine what to do, when and how the work should be done and who does it. This provides a nice framework to recognize if your team is actually self-managing, or is getting undue direction from outside the team:
- The team manages their work by deciding what they should be doing on a day to day basis:
- Are you operating toward clear goals; does your team use the Product Goal and Sprint Goal to guide their decisions?
- Does your team focus on the value being delivered?
- Does your team determine how best to fulfill the PBIs; does the team decide what they should be doing without direction from outside the team?
- The team manages their work by deciding when they should do certain activities. They do this without outside direction:
- Does the team select a realistic and challenging amount of work for the Sprint and does the team get the work to Done?
- Does the team choose what and when to release?
- How the members of the team interact with each other gives clues to whether it is a self-managing team:
- Do the developers decide who picks up the work?
- Is the team collaborating to solve problems?
- Does everyone on the team have a voice?
- Do they trust each other?
- Do team members work with and help each other?
- How the the team manages their work practices is a good indicator of whether the team is self-managing:
- Do they define and improve their quality practices?
- Do they continually improve their adoption/implementation of Scrum?
- Is the work that’s being done transparent?
- Are they dedicated to doing the work well?
- Do they “live” the Scrum Values?
Myths and Misunderstandings about Self-Management
Few things in Scrum are as misunderstood and misinterpreted as much as a Scrum Team’s need for self-management. At the highest level, it’s not a very difficult concept, but the nuances tend to throw things into question.
Simply said: the team needs the autonomy to get its work done. However, the phrase “self-management” has led some to believe that Scrum is anti-management or anti-manager. This is simply not true. In fact, there are several myths that we’d like to debunk:
Myth: Self-management means that no managers are needed and all of the traditional work of “managers” is done by people on the team. This could include compensation, hiring, firing, promotions and career development. This also suggests that Scrum requires flat organizational structures, no titles or individual bonuses.
Reality: Self-management on the Scrum Team doesn’t mean “no managers” in the organization. It’s true that no managers are required to constitute a Scrum Team, but that doesn’t mean that no managers are required in the organization.
In organizations that are using Scrum well, the manager’s role switches away from directing the team, toward supporting the team. They are often the right people in the organization to make sure that the Scrum Teams have everything they need to be successful, such as the necessary equipment, budget and cooperation from personnel outside the Scrum Team.
Myth: Self-management means that the team isn’t required to follow rules from outside the team. If they are empowered to make their own decisions, this means that they can choose to ignore managers and stakeholders and are unaccountable to them.
Reality: Scrum takes accountability very seriously. The team as a whole is accountable for creating valuable work and each of the members of the team have clear accountabilities. There is nothing in self-management that encourages chaos and suggests the suspension of rules from outside the team. Scrum Teams are actually very disciplined in their work and commitments.
Myth: Teams are completely self-contained, have all the skills necessary to do all the work and should not need to go outside of their teams for help.
Reality: It’s true that in order to effectively manage their work, the team needs to have the necessary skills to get the work done. However, complex work often requires the temporary assistance of individuals with specialist skills. Often, there are too few of these specialists for them to be full-time members on individual Scrum Teams and they must be shared across many teams. Self-managing teams may not have all the skills necessary, but they are effective collaborators with colleagues outside their team and together they determine how the work will be done.
Myth: When self-managing teams encounter challenges it’s always best to let them work it out themselves.
Reality: Self-managing teams work hard to remove their own impediments, but this is not a license to ignore challenges that they cannot overcome. We’ve heard horror stories of “busy” stakeholders who do not provide adequate guidance on high-level goals or adequate feedback on the work being done, claiming that they are allowing the team to “self-manage.” Similarly, we’ve heard of Scrum Masters who, upon identifying unhealthy conflict among team members, ignore the growing team dysfunction and claim that they are allowing the team to “self-manage” their way to a solution.
Neither of these examples are supporting the team’s self-management, they are examples of abandoning their responsibilities to the team.