One of the harder parts of being a Scrum Master is this: sometimes you can see that a team needs to slow down, but managers or stakeholders want the opposite.
That is understandable.
From the outside, slowing down can look like reduced effort.
But in practice, reducing overload is often how delivery improves.
The key is not to argue for ‘slowing down’ in the abstract.
It is to help people see that too much work in progress, too many competing priorities and too much pressure to start work are often the very things that stop work from finishing.
Suggested ways to influence
A useful approach may be to:
- speak in delivery language, not Scrum language
- show the cost of too much work in progress
- use data such as cycle time, ageing work, blocked items or spill-over
- explain that starting more is often delaying more
- position slowing down as a way to finish sooner and learn faster
- suggest a small experiment, not a permanent ideology
- show how stakeholder feedback arrives sooner when work flows better
That last point matters.
Stakeholders usually do not care about flow for its own sake. They care about when they will see something useful, when risk will reduce, and when they can respond to real feedback.
That is why influence matters here.
As a Scrum Master, you are not trying to sell slowness.
You are helping people see the economics of flow.
Because sometimes the fastest way to deliver is to stop trying to do so much at once.
