ScrumMaster Dilemmas

A few weeks ago, during a Product Owner class I was teaching, the lone practicing ScrumMaster in the room raised his hand after I had finished the section of the course reviewing Scrum roles. His question was basically this: "So, you just said one of the ScrumMaster's functions is to be a bulldozer, but when I solved a problem for my team last week, they accused me of 'throwing them under the bus' and now they won't talk about impediments anymore. What am I supposed to do?"

After learning more about the situation, I understood what had happened. At the last Retrospective, the team had raised an issue they were having with their Product Owner and, seeing himself as the fullback, snowplow, bulldozer, problem-solver, the ScrumMaster had simply taken the team's concerns to the Product Owner and worked out a solution. When he (the ScrumMaster) reported back to the team during a Daily Scrum his progress in resolving the issue with the Product Owner, the team reacted very negatively, as the ScrumMaster had described in his original question.

His confusion and genuine sense of hurt were palpable. He thought his role was to clear the road for the team so that they could get their work done as efficiently and effectively as possible. His point is entirely valid, but his experience demonstrates one of the many dilemmas that face ScrumMasters.

Take it to the team!

In her excellent book*, Lyssa Adkins gives this advice again and again. Self-organizing teams need to be empowered to solve their own problems -- or at least to devise prospective solutions to the problems they face. The ScrumMaster in my class did not realize that self-organizing teams, even those that have only been practicing for a few months, do not want to be presented with solutions to problems. Instead, as Lyssa points out, self-organizing teams want, and need, to be presented with problems. The team is then empowered to devise solutions -- and the team's solution will be the best one for that team. It may not be the solution the ScrumMaster would have chosen, but that does not change this essential fact.

Despite the best of intentions, ScrumMasters run into difficulties with their teams when they take on problems and solve them without team involvement. The team may ask their ScrumMaster to implement the solution to a problem, but the team itself needs to solve the problem. Many ScrumMasters came from backgrounds where individual problem solving was a major part of their job descriptions. Perhaps they were even evaluated on the basis of their individual problem-solving prowess. In a Scrum (or other agile framework) team environment, the equation changes. Problem solving abilities are still valuable, but within the context of of the self-organizing team.

ScrumMasters must engage in a delicate balancing act, being the bulldozer, fullback, or snowplow for their team, yet not imposing solutions on the team. It is more difficult to achieve this balance when a ScrumMaster is responsible for more than one team. Under pressure to help their teams succeed and with a severely limited amount of time and attention to offer to each team, such ScrumMasters are naturally inclined to gather lists of problems and run with them, handing solutions to their teams in rapid succession. This situation is bad for the teams, stunting their growth and inviting resentment against their ScrumMaster; it is also bad for the ScrumMaster who never really has time to get to know each team and the various individuals at the depth necessary to achieve the highest degree of effectiveness.

So what's a ScrumMaster to do? "Take it to the team," let the team solve problems, and keep the wolves at bay.

All for now....

...-.-

*Lyssa Adkins, Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition. Upper Saddle River, NJ: Addison-Wesley, 2010.