Empowering Teams: The ScrumMaster's Role

11 June 2007

John Hill
IconATG

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:

  1. Organizational command and control behavior
  2. 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.
  • 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

  1. 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.
  2. Ensure that dysfunctional meeting participants are controlled, even if by a third-party facilitator.
  3. Ensure that barriers between team members are removed, even if by a third-party facilitator.
  4. Effectively work with the team to remove impediments, proving a level of true commitment to the team.
  5. 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.

     


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: 0 (0 ratings)

Comments

Mike Lowery, CSP,CSM,CSPO, 6/12/2007 3:10:15 AM
Very clear consise and informative, liked this a lot. My only disagreement would be "Directing the order in which tasks should be completed during a sprint", I think that in many cases it is important for the ScrumMaster to stress the relative importance of the Product Backlog items within a sprint, especially if the team is not brilliant at estimating.
Aldo Cauchi Savona, CSM, 6/12/2007 7:13:52 AM
IMHO, the amount a team knows or is convinced about agile determines quite a bit on the involvement of the scrum master in the team. Teams that have worked in agile know what needs to be done to get something 'done' while a new team might not.
John P. Puopolo, CSM, 6/13/2007 9:49:34 AM
Well done. Two points struck me - that Scrum is all about trust, and that the power of Scrum emanates from the team, not from the hierarchy.
John Hill, CSP,CSM,CSPO, 6/13/2007 11:50:11 AM
Hi Mike:
Thanks for the great feedback on my article. I would, however, like to clarify one point.
Although I do strongly agree with you that the ScrumMaster should keep the
team working on the stories selected for the sprint backlog. When it comes to the
lower-level tasks required to implement those stories, however, the team should determine
the sequencing of tasks. Some ScrumMasters don't understand this and irritate teams by
"helping" them to sequence tasks (as well as "helping" teams to determine task assignments),
which clearly does not work. Thanks again, John H.
John Hill, CSP,CSM,CSPO, 6/13/2007 11:55:54 AM
Hi Aldo: You are absolutely correct in that teams with less exposure to Scrum (or
"Agile" environments generally) will struggle until they really understand the
dynamics of Scrum. Thanks for adding this point that I should have made in the
article. John H.
Nicholas Cancelliere, CSM, 6/14/2007 4:24:52 PM
While it is important for the ScrumMaster to protect the team from outside influences, they also sometimes need to protect the team from themselves. It's a gray area though where many ScrumMasters go wrong. You have to be sure to not let your team degenerate into a chaotic mass without any accountability or slip into old habits. At the same time you have to sometimes not help them to provide them opportunities to learn, improve and prove to themselves they can self-manage. It's probably one of the biggest challenges a ScrumMaster faces, next to culture.
Mike Lowery, CSP,CSM,CSPO, 6/19/2007 9:35:50 AM
John,
That's exactly what i meant but articulated badly, I only try to give direction at the product backlog level.
Mike Lowery, CSP,CSM,CSPO, 6/19/2007 9:39:17 AM
I also think Nicholas has a good point, A scrum master should try to remove impediments in a timely manner, we always seem to focus on the external for this and rarely internall. I try to "actively" facilitate rather then passivle listen and react. Especiailly if team members go off piste or start to behave badly.
Adam Wernig, CSM,CSPO, 6/20/2007 3:59:47 PM
My company just started using scrum. What is the best way to conduct a sprint planning meeting when you have 3 teams and a bunch of product backlog items without estimates or complexity levels? Do you just have all of them sit and break down each item and have teams leave once their purse is filled up for the month? My fear in doing that is wasting peoples time because they will not be working on everything discussed.
Mike Lowery, CSP,CSM,CSPO, 6/21/2007 3:02:34 AM
Adam,
can you split the backlogs into one per team? That would help, you can then put some integration items into all the backlogs (just in case they don't think of it).
Adam Wernig, CSM,CSPO, 6/21/2007 3:39:43 PM
Mike, if I take that approach do you have any input as to who should be the one to determine which specific backlog items are will be reviewed by the teams? Scrum master, product owner, the actual teams themselves?
John Hill, CSP,CSM,CSPO, 6/27/2007 5:52:06 PM
Adam: I haven't been on the SA website for a while and just now saw your question about planning imprecise backlogs for three teams, etc. I would strongly recommend that the Product Owner(s) engage in "Release Planning" prior to you doing any "Sprint Planning". The intent of this activity would be minimally two-fold: 1. Determine high-level "story points" for each story/feaure. I would recommend that you use Mike Cohn's story-pointing methods, including "triangulation" between/across all of the stories being planned for every user story in the backlog. This activity provides relative sizing for every user story, which is a lot better than having no notion of story "size". 2. Prioritize all of the stories for the release. If you go into a sprint planning session with a story-pointed, prioritized backlog your life will already be very much improved over your current environment. Once you begin to track "velocity" (again ala Mike Cohn, equating to a team's ability to determine the average number of story points burned during a sprint), you will be in better shape to know how much backlog specific teams can consume during a sprint of a given length. With this knowledge, you could have a sprint "pre-planning" session (almost immediately following the Release Planning activities) and determine which teams should work on specific stories based on the size of the backlog and the team's capacity and velocity. Your three teams could even perform sprint planning together, with each team emerging with an appropriate backlog for the sprints being planned. When performing your story-pointing exercise as part of the release planning process, however, please remember that story-pointing should not be labored over. Always remember that tasks will be estimated (in hours) during the actual sprint planning sessions. Spending too much time on estimates up-front is wasteful, especially when some of the stories being pointed will never be developed. Hope this helps. John H.
John Hill, CSP,CSM,CSPO, 6/13/2009 10:07:07 PM
Someone just made me aware of the fact that the link in this article to another article referenced above (by Stacia Broderick titled "Daily Standup Withdrawal (DSW) in Scrum Teams") no longer works and has been changed to this url: http://www.scrumalliance.org/articles/32-daily-standup-withdrawal-in-scrum-teams).

John H.
Anonymous, 4/12/2013 5:01:00 AM
I work with a IT division of a charity organisation in London..I am currently suspended from work for refusing a task assigned and estimated by scrum master. Task was pretty useless. This is example of how to misuse scrum for settling personal scores.

You must Login or Signup to comment.