Empowerment: The Missing Ingredient for Scrum Teams

7 May 2012

Jerry Rajamoney
EMC Corporation

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.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (1 ratings)

Comments

SenthilVel Marimuthu, CSP,CSM, 5/8/2012 12:25:19 AM
Jerry, Good Article on Team Empowerment!
One of the basic goals of the Scrum team is to have the SELF MANAGED TEAM who can take decisions , and Own the Product, where in the teams become hyper productive for the business.This point is well mentioned in your article!
Some years back when i was the Scrum Master for a critial product ,the Goal for my team was to come up with a Product ASAP which can beat the Business race in minimum time and with great features! The only way in which i was successfull in creating a product for DEMO to my sales team in very short time was through the TEAM EMPOWEREMENT- without which we would not have CREAFTED a new product!
When it comes to SCcum Master roles the TEAM EMPOWEREMENT is one of the biggest goal which the SM needs to promote in his teams.
Jim Evans, CSPO, 6/15/2012 8:46:26 AM
As Someone who has a dual role as a traditional manager and a product owner I continue to remind the team that they are empowered but they still see me more as a manager instead of a PO. We are only seven months into scrum and have not come up with a solution yet, but I am prepared to give up one of the roles if it helps. If anyone has any additional tips pleas pass them along.
Michael Wollin, CSP,CSM,CSPO, 7/2/2012 3:26:33 PM
Excellent article. I'm not clear though on what exactly you mean by empowerment. I see it as the safety to say and do what's necessary (usually by team consensus), the power to say no, or "those acceptance criteria are untestable," and the power to decide HOW to fulfill on the sprint commitment (freedom from micromanagement).

You must Login or Signup to comment.