Protecting the team against injection

Question

How does the Scrum Master protect the team against the business rapidly changing priorities/contexts.

Answer 1

The specifics depend on the nature of the changes and why they are happening, but it usually comes down to some kind of coaching.

If the reason is an incoming "high priority" request from a customer, there could be opportunities to work with the Product Owner. Why are there high priority requests that can't wait for the next Sprint? Does the Product Owner need coaching and help to elicit needs from stakeholders? Could the Product Owner and Scrum Master coach the customers about the impact of throwing these "high priority" requests at the team in the middle of the Sprint? Does the Product Owner have the ability to push back on these requests?

If the reason is a production issue, the Scrum Master can facilitate retrospectives and post-mortems to get to the root causes. Addressing the root causes can prevent similar failures in the future and the team will have fewer production issues to address. There are opportunities to teach stakeholders about the impact of these issues on the team's morale and ability to deliver valuable work, along with the value of ensuring there is a focus on quality and paying down any technical debt.

If there are other reasons, getting to the root causes of the problem, making sure everyone understands the costs and risks of not addressing the problem, and helping the team work through them are all well within the responsibilities of the Scrum Master.

Answer 2

Normally, Scrum - and Agile in general - is something you want to use in a context with rapidly changing priorities. So the team shouldn't need protecting from anything, because you want to move with agility and respond quickly to changes. So that's the context the team works in.

But the way you asked your question, and the details before the edit, seem to indicate that you are in a context where only the development team is supposed to be Agile. Everyone else stays the same and works with deadlines, due dates, and putting more work, priority changes, and pressure on people, expecting that things always go smoothly, expecting that the development team keeps things smoothly no matter what. And if they don't, it's the developers' fault.

I've said it before, and I will say it again. For a company to be Agile, the whole company needs to be Agile. It's a new mindset of developing products, one rooted in values and practices like those mentioned by Scrum: commitment, focus, openness, respect, courage, transparency, inspection, adaptation.

When you have these and people collaborate on the same initiative, you don't need to protect the team from anything because everyone has neck in the game and is committed.

But I've seen almost zero companies like this. Most of them use Scrum or Agile in name only. It's just the same old behaviors but now with sprints. The same mindset applied slightly different, ending up with arbitrarily chosen deadlines and priorities followed by finger pointing and blame placing when they are not met. Simply because people don't understand or/and don't care about building a product with all that's involved and considering the nature of software development itself.

The result in these cases is usually heavy processes and procedures put in place to try to bring in some sanity or slow down the amount of changes (contrary to the reason for using Scrum/Agile in the first place). That and documenting everything in details, but not for clarifications and building shared understanding, but for blame avoidance.

If people don't care, there is not much you can do but try to put in place this kinds of processes, procedures, documentation, and often also a change request management mechanism, just so that there is a trace of all of the changes in place that then can be used to deflect blame.

If on the other hand people do care, but don't understand, then a lot of work needs to be done to increase communication, collaboration, transparency, and ultimately understanding. The Scrum Guide says that the Scrum Master serves the organization in several ways, including:

• Leading, training, and coaching the organization in its Scrum adoption;
• Planning and advising Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
• Removing barriers between stakeholders and Scrum Teams.

Some high level objectives, and vague on the details, and getting more abstract with each release of the Scrum Guide. Achieving these things depends a lot on the context within the company and the organizational culture, and you can't really be too prescriptive on the methods to use. But still... not of much help when it comes to holding a mirror to the organization and reflecting the problems, because the problems need to be fixed. And all eyes tend to turn on the Scrum Master, because you are doing Scrum, right? And who is responsible for Scrum?

So a lot starts with training and conversion to bring in understanding. Understanding that the scope within the sprint should be fixed if you want to do Scrum. Understanding that constantly changing priorities doesn't generate outcomes or results but just creates work in progress while you constantly start things without finishing them. Understanding that the team capacity is limited and if one new thing needs to be done urgently then some other work needs to be removed to make place for it. Understanding on the nature of the work and on choosing the proper development method to do it (e.g. if things can't be stable not even for a sprint then maybe Kanban would yield better results). Understanding that all decisions have consequences and those consequences don't change with wishful thinking or putting pressure on the team or imposing overtime (in fact it makes it worse). Etc. Etc.

So to answer your question:

How does the Scrum Master protect the team against the business rapidly changing priorities/contexts.

By starting these conversations and trainings with those outside the Scrum team, while carefully considering the full context. It's about full transparency on the current impact of the way of working on the team and on the outcomes. And the courage to bring in that transparency.

If you are dealing with reasonable people, you will eventually reach a consensus on how to improve things. If you are not dealing with reasonable people, then you either move away to greener pastures or you keep you head down and try to do what you can to slow things down and not take the blame for the end result.

Unfortunately for Scrum Masters, in an organization where "Scrum" is just a fad word, it'll be their fulltime job to convince management Scrum is more than a word, or get fired trying.

Answer 3

Reflect the pain

The Scrum Master can help by preparing sprint reports that highlight the impact of priority/context changes.

For example:

Midway through this sprint the team was asked to stop the search work we were doing as the new home page was given a higher priority. The team switched to the new work, but the context switch cost perhaps as much as 20% of the capacity for the sprint. As a result, we were less productive than we would normally be.

Help the team get better at accomodating change

Are there things the team can do to make changes less painful?

• Does the team have an effective branching strategy that helps switch focus?
• Would extensive automated regression test coverage make it easier to pick up new feature requests with minimal disruption?
• Could the team switch to a continuous delivery approach, perhaps using feature toggles on work in progress?
• Can the team prepare a process for rapid re-planning?

Answer 4

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Above, I cited the Agile Manifesto. Which of these do you believe to be applicable in your case, and how do you think this might assist the Scrum Master in coaching the team and organization?

Scrum also doesn't prevent us from changing or adapting the Sprint backlog in response to new information, but it does advise us to be careful not to jeopardize our Sprint Goal.