1

In Scrum, the Scrum master's duty is to "remove impediments". I think I understand what this means in terms of organizational and coaching issues. I understand that the SM watches the devs' backs and keeps disturbances from outside the team away.

But, similar to this question, I don't fully understand what it means with respect to internal and (development) process related issues.

Is it or can it be a Scrum Master's responsibility to:

  • setup/improve a code review software system?
  • setup/improve the continuous integration process?
  • provide scripts/macros/helper tools to make the development process easier/more efficient ?

1 Answer 1

3

TL;DR

Is it or can it be a Scrum Master's responsibility to:

  • setup/improve a code review software system?
  • setup/improve the continuous integration process?
  • provide scripts/macros/helper tools to make the development process easier/more efficient ?

No, no, and no. These responsibilities rest with the self-organizing development team. If you turn the Scrum Master into a DevOps engineer, that person will no longer be able to focus on the core responsibilities of the Scrum Master role.

The Scrum Master Role

The Scrum Master is the shepherd and evangelist of the Scrum process. In other words, the SM acts as a process referee, and "removing impediments" generally refers to working with the team, management, and the stakeholders to raise the visibility of process-impeding issues and providing a constructive framework for all parties to cooperatively develop an organizationally-appropriate solution.

The Team's Responsibilities

If a Sprint Retrospective identifies code review as a process issue, then the Scrum Master should capture that issue and provide guidance to the team and the Product Owner on how the framework allows them to improve that part of the process. This may include:

  • changing the "definition of done" to incorporate code review processes,
  • the Product Owner adding a new user story to Product Backlog that prioritizes the installation and configuration of a code review system, or
  • anything else that everyone agrees fixes the issue for the team and the project.

The same is true for continuous integration and tool chains. Whether driven by technical debt or a desire to continuously improve the process, the Sprint Retrospective is the place to raise such issues.

Ultimately, it is the Product Owner's responsibility to prioritize the work related to process improvement (by manipulating the Product Backlog), and the team's responsibility to implement a solution once that work has been prioritized by the PO.

The Scrum Master's job is just to make sure that the Scrum framework is properly leveraged to give everyone involved the process tools that they need to do these things within the context of Scrum. If you take your Scrum Master off-task by assigning implementation work, then that person is no longer fully-dedicated to performing the tasks that are essential to the Scrum Master role. Don't do that.

Intra-team process and technical implementation are responsibilities that rest within the self-organizing development team. Neither the Scrum Master nor the Product Owner should be sticking their thumbs in those particular pies.

3
  • So this could make up a Product Backlog item although it does not directly provide visible value to the customer? Or is this (if I understand your last paragraph correctlcy) totally up to the team? But wouldn't it (temporarily) affect team velocity if this work is not accounted for in the backlog and thus, sprint planning? Commented Feb 7, 2014 at 15:32
  • 1
    @JohannesS. The Product Backlog is for prioritizing all work related to the project, not just work that has visible value to the customer. Velocity is a tracking/forecasting tool, not a management target. So, yes, it may affect velocity...but you want those costs to be visible in a properly-run Scrum project.
    – Todd A. Jacobs
    Commented Feb 7, 2014 at 15:39
  • I love how scrum types say "self organizing" and then, immediately follow it with "but not like that way you just organically came up with". Scrum Master is not necessarily a full time role. If your organically developed team happens to have someone who both is interested & capable with managing those tools, and being scrum master, then it works. Or it doesn't. Commented Feb 8, 2014 at 15:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.