The following post is from our guest editor Srinivas Chillara. Srinivas is a Scrum coach and co-author of “Essentials of Scrum practice“- a mini-book currently in advanced draft stage.
We don’t need no disruption
We don’t need no time control
No breathing down the neck in the server room
Manager, leave the team alone.
What do we do if a senior manager is asking for a ‘resource’ from within the team, in the middle of a sprint, to deal with some urgent matter?
This is clearly another case of violation of the “NO CHANGE RULE”.
As with a lot of things, this is better preempted, by informing as much of the surrounding organisation as possible before the start of a Scrum project, that we have to keep a team constant for at least the duration of a sprint. In other words the organisation should understand that the ‘NO CHANGE RULE’ is critical and central to the Scrum way of working.
However, senior managers may not pay sufficient attention to this or feel that whatever is occupying their minds at the moment is of utmost importance, and they can pull ‘resources’ (actually people) out without too much consideration. It is the Scrum Master’s job to protect the team, and as such does throw the Scrum Masters into a very difficult situation. The organisation culture will be a dominating factor in how people (SM included) behave. In many organisations the hierarchical structure combined usually with a command and control culture means that Scrum Masters are either powerless in face of such disruption or get into a downward spiral of de-motivation. This effect should be highlighted after the sprint end, to the management including any effects on how the team struggled to meet the sprint goal.
The Scrum Master in such circumstances should talk to the team and PO, and if applicable to the PO’s manager (who could be the senior manager in question) about the side-effects of pulling someone out mid-sprint.
Organisations where everyone is well-educated about Scrum, will seldom face such a situation without being able to make corrections and recover fast. This situation is particularly difficult in organisations which are largely ignorant of Scrum and the attendant principles. So it is important to respond to this situation without using jargon in such settings.
Speak in terms of disruption, de-motivation and relative importance of the sprint goal versus the work the pulled out ‘resource’ will do, versus the importance of adhering to the rules of the game. Such a conversation should also guide the persons making this decision to think in terms of ramifications of such requests and induce an inclination for senior managers to talk to the PO and SM before making any such requests/orders to pull out people, in the future.
All this engenders a culture where disruptions are kept to a minimum and only for good, genuine reasons. A relevant point here is the case when in response to a management edict coming from much higher-up, and in essentially a knee-jerk reaction, someone is pulled out even before it is really clear what exactly needs to be done. In other words the person pulled out cannot really begin work, since certain clarifications are still being sought. In such cases the useful practical steps to take consist of the Scrum Master taking a close look, spending sometime to discuss this with relevant team member, so they are prepared, wait till the end of the Sprint, so there is minimal disruption. Then after the sprint ends, the team can be reset, with a freshly updated backlog, which may include this ‘urgent’ piece of work; alternatively the person in question will not be part of the team for the new sprint, and works independently.