Empowerment: The Missing Ingredient for Scrum Teams

We all understand that Scrum teams should be self-managed and self-organized. Empowered is the commonly used term, because without empowerment it's difficult for self-management and self-organization to happen.

I've worked with many teams that are trying to adapt Scrum as their developmental framework. Sometimes this adaptation is happening purely because management has made the decision (the top-down approach), and sometimes the change is a decision made by the team (the bottom-up approach). My role is usually either to work as the dedicated ScrumMaster for the team or to work as an internal coach for multiple Scrum teams. In either case, I work closely with the teams and, as needed, the ScrumMaster. I regularly see problems of specific types that I will explain below.

Team details

First, though, a little detail: The Scrum teams I work with are usually small — eight people per team. Each team has a dedicated ScrumMaster and a dedicated local product owner. The team is well versed in the ceremonies and sticks to the recommended timings. Thus the team allocates 10 percent of its time to the preplanning meeting, has a two-hour sprint planning meeting, takes 15 minutes for the daily stand-up meeting, and has a one-hour review meeting and a one-hour retrospective meeting. The team also adheres to a two-week sprint cadence.

Problem areas

The key issue, or the high-priority impediment item, that I have repeatedly faced and struggled to solve is empowering the team. As noted, the team is well versed in the ceremonies. Team members are reasonably aware of and exhibit their expected roles and responsibilities within the Scrum framework. The team members claim the team is self-organizing and self-managing, and there are apparent proofs that they're right (with some constraints and clauses attached). But a closer look shows that the team is not truly empowered, although the time-boxing way of working within the Scrum framework creates the illusion that the team is managing and organizing itself.

Symptoms

Over the years I've observed certain behaviors, exhibited by the team members, product owner, and ScrumMaster, that indicate a lack of true empowerment. Here are the examples I see most often:

• In the sprint planning meeting, the team negotiates for the scope and comes to an agreement on it by the end of the meeting. But during the middle of the sprint, the team finds it difficult to negotiate for a change in scope if needed based on actual data. The product owner wants the team to stick to the initial scope agreement, as otherwise it will affect his or her projection.
• In the daily stand-up meeting, when the team brings up issues and wants to make changes to the existing architecture or a previously delivered piece of code, it goes to the ScrumMaster or product owner for approval.
• Whenever the team has its regular meetings with managers, there's a lot of emphasis on self-management and self-organization. But empowerment isn't discussed. It's not that people don't want to talk about it, but what I've observed is that managers don't understand that self-management and self-organization can happen only if the teams are empowered, and that can only happen if the managers support the idea with actions as well as words.
• In sprint retrospective meetings, team members talk about the things that went well but are reluctant to discuss areas needing improvement. Instead, the product owner or the ScrumMaster tries to solve the problems and provide solutions that the team should follow during the next sprint.

Apart from the above observations, I have also noted the dual role played by existing managers (as designated by their job title). Managers are often asked to play the role of product owner or ScrumMaster. This causes confusion and conflict for both the managers themselves and the for the Scrum teams. It tends to hinder team empowerment, because the roles and responsibilities of these two job types are completely different. It isn't easy to be a manager in an organization and also to work as a ScrumMaster. The first role tends to follow a traditional management style; the second follows more of a servant-leadership style. One role tends to oppose team empowerment while the other supports it.

One solution that worked for us

I've found a way to work around the problems of team empowerment in at least some situations. Let's take, for example, the first case explained in the Symptoms section: The team wants to redefine the scope during the sprint, while the product owner opposes such a move. I've requested that the ScrumMaster assess the team's comfort level with the initial sprint scope it agreed upon by running a "fist-to-five" meeting (as explained by Jean Tabaka, wherein members "vote" using a fist to signal opposition to the idea and increasing numbers of fingers held up to indicate increasing levels of approval). We then share the resulting data from the team with the product owner. I discuss the situation with the product owner, helping him or her understand that if the team has indicated a certain level of reservation about the scope, then there is a possibility of mid-sprint scope renegotiation. This gives an early warning to the product owners, and, perhaps surprisingly, it has worked well for us.

Conclusion

Based on my experience, I believe that a lack of true team empowerment is a more common problem than many would like to acknowledge. And I would be interested in further discussion of solutions other ScrumMasters have come up with. But the basic point is this: If managers and management want their teams to move toward a hyperproductive state (which Scrum is designed to achieve), the team must be able to manage itself. That can only happen if the team is empowered. And without more than lip service — that is, without real support from managers and management — empowerment cannot truly happen.

So if you are a ScrumMaster, take a look at this article's examples of symptoms of lack of empowerment (or step back and assess your team in your own way). If any of these problems apply, the top-priority item on your impediment list should be team empowerment.