By John Hill
The number of “unempowered” teams alleging to be doing Scrum is appalling! Two significant factors often prevent Scrum teams from becoming empowered, ultimately leading to their failure:
- Organizational command and control behavior
- Specific ScrumMaster failings
Both of these factors are something a ScrumMaster can (and should) address.
Symptoms
You can tell a team knows they are powerless when you observe them going through various Scrum "motions." These motions include the following dysfunctional sprint meetings:
- Sprint Planning Sessions. Symptoms include managers or ScrumMasters:
- Questioning (or influencing) team task estimates.
- Directing the order in which tasks should be completed during a sprint.
- Directing which team members should be assigned to specific tasks.
- Daily Scrums. Symptoms include:
- Providing status to the ScrumMaster instead of providing status to the team.
- Zombie-like monotone responses, such as "I did this. I will do that. I have no impediments." Daily Scrums of this nature rarely lead to the collaborative post-Scrum discussions where decisions are made and impediments are circumvented.
- For a great discussion on how to get your daily Scrum back on track, see Stacia L. Broderick’s “Daily Standup Withdrawal (DSW) in Scrum Teams.”
- Sprint Reviews/Demonstrations and Retrospectives. Symptoms include:
- Managers and/or ScrumMasters who take charge of the session and state their observations first. This often influences the team to stifle their best observations for fear of contradicting the manager.
- Little meaningful feedback from the team. The result is that no “go-forward” improvements result from the sessions.
- General Meetings. Symptoms include team members that:
- Ramble aimlessly.
- Hijack meetings and won’t relinquish control back to the team.
- Do not participate.
- Get up and leave meetings.
- Force their “expert” opinion on the team inflexibly.
- Argue about everything.
- For great techniques to handle these team meeting dysfunctions, see Jean Tabaka’s Collaboration Explained: Facilitation Skills for Software Project Leaders, Upper Saddle River, NJ: Addison-Wesley, 2006: 242-251.
Causes
"Command and Control" Style Managers (including ScrumMasters)
All of the problems described under “Dysfunctional Sprint Meetings” are caused directly by managers (including ScrumMasters) who usually come to Scrum armed with years of ingrained, directive behaviors. The ScrumMaster needs to work with these managers to get them to let go. It’s the ScrumMaster’s responsibility to educate management and help them understand that the process is all about trust. If team members cannot be trusted to determine their work, teams will never properly “commit” to completing a sprint goal, nor will they ever feel the desire to make the key decisions that they should be responsible for.
The ScrumMaster also needs to work with managers to help them to allow others to provide feedback during sessions before they chime-in. If the manager cannot be controlled in this area, they may need to be removed from the process.
If the ScrumMaster is the problem, then an agile coach needs to be brought-in to educate the ScrumMaster (or have the ScrumMaster removed and replaced if necessary).
I would also like to add another cautionary note. Converting line managers into ScrumMasters sometimes will not work. The team behaves as though the ScrumMaster is "the boss" and looks to that individual for guidance while doing Scrum. Teams thus feel that their power comes from the ScrumMaster, and not from the team. Converting "strong" project managers into ScrumMasters can be problematic for the same reasons.
In both instances, the team will likely provide status to the ScrumMaster during the daily Scrum, instead of using the session for its intended purpose of sharing status with the team. Fortunately, there are numerous exceptions where former line managers and project managers are now successful ScrumMasters (although this transformation can take a while).
General ScrumMaster Failings
I strongly recommend that ScrumMasters refer to the book by Jean Tabaka referenced above and make use of its wisdom. If a ScrumMaster is unable to resolve these issues, a professional facilitator should be consulted. In my experience, teams will never feel in control if members do not properly participate together in meetings as a cohesive unit. I therefore believe that it remains the ScrumMaster’s responsibility to ensure that these issues are resolved, even if by a third party.
Cure
To ensure team empowerment, the Scrum Master must work diligently on all of his or her responsibilities.
Resolve Conflicts: The ScrumMaster is responsible for removing certain barriers, including barriers:
* Between individual developers (or between any individual team members)
* Between developers and test engineers (especially when first working together cross-functionally)
* Between the development team and the product owner.
If the ScrumMaster does not have the skills to deal with team conflict, a professional facilitator should be consulted. A team will never be fully-empowered with even one dysfunctional relationship within the team.
Handling Impediments: A ScrumMaster must actually work to help remove impediments reported during the daily Scrum. If it looks like an impediment cannot be removed for some reason, it becomes a condition of reality. For these conditions, the ScrumMaster must work with the team to circumvent the impediment. If an impediment requires more than one day for removal, the ScrumMaster must communicate this information back to the team so that they know the ScrumMaster is making an effort on the team's behalf.
Protecting the Team: The ScrumMaster must protect the team from disruptive outside influences. (Examples include salespeople directly requesting estimates from team members for prospective clients, support staff directly contacting team members for help with customer bugs, consultants at client sites calling team members with installation, conversion, or configuration problems for a new installation, etc.) Even if a team member is truly needed in these situations, the ScrumMaster must provide a filter. The ScrumMaster must also protect the team from attending unnecessary meetings. Most meeting owners will be able to tell if a team member really needs to attend a meeting. If so, the ScrumMaster should still be the filter.
Conclusion
Scrum teams feel truly empowered when they understand that the ScrumMaster is actually looking out for the team and will protect the team from outside influences that can rob the team of its power. More specifically, the ScrumMaster needs to
- Eliminate (or sufficiently reduce) “command and control" management practices so that teams can run their own sprint planning sessions in the areas of task estimates, task sequencing, and task assignments, as well as run sprint reviews and retrospectives openly and honestly so that they actually make a difference going forward.
- Ensure that dysfunctional meeting participants are controlled, even if by a third-party facilitator.
- Ensure that barriers between team members are removed, even if by a third-party facilitator.
- Effectively work with the team to remove impediments, proving a level of true commitment to the team.
- Protect the team from stressful outside influences and unnecessary meetings, enabling the team to work together with reduced interruption.
The bottom line is that teams will not feel truly empowered until they realize that the ScrumMaster is serious about the ScrumMaster role. This is most of the battle (and the toughest part of the battle, requiring a ScrumMaster that “gets it”). Until this commitment by the ScrumMaster is proven to the team, teams will rarely understand the nature of a "commitment driven sprint" themselves, and backlog items will continue to slide from sprint to sprint.
