Empowerment: The Missing Ingredient for Scrum

Synopsis:   It is said clearly in many scrum articles and we all understood that the scrum teams are expected to be self-managed and self-organized. Also, the articles mentioned that the scrum teams are “empowered” as without empowerment it is difficult to have self-management and self-organization to happen.

Background: I am working and have worked with many teams who are trying or tried to adapt scrum as their development framework. Sometimes this adaptation is pure because of the decision made by the management (top-down approach) or sometimes it is purely the decision by the team (bottom-up approach). My role was either work as the dedicated Scrum Master for one of the team or work as an internal Coach for multiple Scrum teams. In both cases, I worked very closely with the teams and Scrum Master. I am seeing some of the common problems which are falling under the same pattern and I have detailed the same below.

Team Details: The scrum teams are formed in small numbers (8 people per scrum team). The team has a dedicated Scrum Master and a dedicated local product owner. The team is well versed in all the ceremonies and sticks to the timing for those ceremonies recommended. The team has allocated 10% of their time for preplanning meetings, a two-hour sprint planning meeting, 15 minutes daily standup meeting, a one-hour review meeting, and a one-hour retrospective meeting. The team has a 2-week sprint cadence.

Problem Areas: In both cases, the key issue or the high priority impediment item I have faced and struggled to solve is “empowering the team”. The team is well versed with the ceremonies, artefacts to follow. To an extent they are aware and exhibiting the roles are responsibilities expected from each role within the Scrum framework. The team claims that they are self-organizing and self-managing and there are evident proofs that they do those (with some constraints and clauses attached). But a closer look at the way of work shows that the team is not “empowered” and the timeboxing way of working within the Scrum framework creates an illusion that they are (as a team) managing and organizing themselves.

Symptoms: While working with these teams, I have observed the following behaviours exhibited by the team members, product owner, Scrum Master in different situations. I have summarized some of the key points and given a high-level overview of those below:

• In the sprint planning meeting, the team negotiates for the scope and agree on the scope at the end of the sprint planning meeting. But the team finds it very difficult for scope negotiation again during the middle of the sprint based on actual data. The product owners want the team to stick to the initial scope agreement as otherwise, it will affect their projection
• In the daily standup meeting when the team brings up some issues and wanted to make some changes to the existing architecture or already delivered piece of code they take it to the Scrum Master or Product Owner as they need approval for the same
• Whenever the team has regular meetings with their managers there is a lot of emphasis on self-management & self-organization. But the empowerment is not talked either knowingly or unknowingly. It is not that they are don’t want to talk about it but what I observed is managers missed to understood that self-management and self-organization can happen only if the teams are empowered and that can only happen if the managers support that.
• In the sprint retrospective meetings, the team talks about the things went well, but reluctant to say areas of improvement. Also from the improvement list, the Product Owner or the Scrum Master picks up the items and come up with the action items. The same will be assigned to the team members.
• In the sprint retrospective meeting from the improvement list, the Product Owner or the Scrum Master tries to solve the problem and provides a solution so that the team can follow the same from the next sprint.

Dual Role is against empowerment:

This put even more confusion and conflict for both the managers and the Scrum Team. It creates a lot of issues in the team empowerment as we can see the roles and responsibilities of these two roles are completely different.

It is not easy to be a manager in an organization and also work as a Scrum Master as both roles have a completely different management style (traditional management style Vs. servant leadership style). One of the roles supports a lot of empowerment and the other one is completely against it.

EndNote: If the managers and management want to have their team move towards the hyper-productive state (as scrum is designed for this), this can only be achieved only if the team can manage themselves and this can only happen if they are “empowered”.

But without the support from the managers and management empowerment cannot happen. So, if you are a Scrum Master the most important (top priority) item in your impediment list should be “Team empowerment”.