A SCRUMMASTER'S BEST DEFENSE: VISIBILITY

As you know, one of the primary roles of the ScrumMaster is to keep the delivery team focused on accomplishing their sprint goal.  There are many distractions that can prevent a delivery team from meeting their commitment to the sprint, the ScrumMaster’s best defense? Complete visibility.

Something is visible if it is easily observed and visibility provides a clear, unobstructed view.  Visibility is one of the three legs of empirical process control used in Scrum (transparency, followed by inspection, and then adaptation).

This clear view can be the ScrumMaster’s best weapon in protecting the delivery team from all types of interruptions. One of the most common distractions from an original sprint plan is new functionality requests during the sprint.

It almost seems like a universal truth for Scrum teams, inevitably someone in a senior position of authority or even the team Product Owner will present a new opportunity mid-sprint. The scenario you hear most commonly is that of a senior vice president approaching a member of the scrum team with an urgent and exciting feature request that represents real value. That team member takes on the work and then in the next daily stand up discusses what has delayed progress on his original sprint tasks. You can’t really blame either the requestor or the team member response; they are both feeling pressure to meet either an internal or external customer need. But the ScrumMaster has to take action, so what to do?

The only real defense to this kind of interruption is to make all the work occurring in the sprint completely visible to the requestor.This sounds obvious I know, but a ScrumMaster may have difficulty standing up to this kind of interruption especially if the opportunity is strong and the interrupter contributes to or even gives his performance review.   

Ideally the ScrumMaster would walk the interrupter over to a visual task board showing the state of the all the work planned for that sprint, highlight the work that would stop or be delayed to handle the interruption, and allow the requestor to make a value decision (in collaboration with the Product Owner). Is this new request truly a higher priority? The answer, more often than not, is ‘no’. The requestor can then work with the Product Owner to add the request to the Product Backlog in the right order. But if the answer is actually ‘yes’ the team can adapt. One option is to abnormally terminate the sprint in progress, kick off a new sprint planning session, and then start a new sprint to implement the request. This option is costly and rare. The most likely option is to complete the current sprint as planned and then start on the new priority request in the next sprint. The requestor should have no longer than a palatable 1-4 weeks to wait for this work to begin.   Overall if the delivery team is continually fielding new requests each sprint, they may want to discuss as a team shortening the length of their sprints for increased flexibility to incoming requests.

ScrumMaster I just coached approached me with this all too common scenario and served as the inspiration for this article. In his case, the delivery team just accepts the requests. They put in overtime to add new requests along with their originally committed work, into the sprint. As a result they often do not meet their 'Definition of Done' for the user stories in their sprint, their deliverable quality suffers, and they are burned out. They are not reaping the benefits of using Agile processes and are not maintaining a sustainable pace.

This team would be better served if he would facilitate a conversation (preferably face-to-face) with the requestor and the product owner using visible information radiators on the status of the work in progress. Sticking to the facts about the work that would be delayed keeps the emotion and the need-to-please pressure out of the decision-making process and makes it simply a business decision. If a face-to-face conversation is impossible, setting up video conferencing and web sharing to have a collaborative session is an alternative.  The sprint backlog, sprint burndown charts, and task boards are all useful information radiators to help communicate the status of the sprint so that the requestor and the Product Owner can make an informed decision about how to handle the incoming feature request.   Ultimately a ScrumMaster may need to get their reporting manager involved if the requestor is uncooperative in the discussion.  

Suggested References: 

Training for Scrum Task Board Use

Building a Taskboard in 10 Steps