Constant Interruptions
As the third cause behind Scrum-implementation-failures, we present: Interruptions. There are those who might say that this is the most common cause leading to implementation failures. But what do we then mean by “interruptions”?
In this context interruptions are meant as interruptions of The Team – that team in Scrum which is presumed to commit to a certain level of deliverables in a Sprint. The Team plans out its work and gets started. They might have barely begun, before a new task or assignment is dumped on them, something that also requires their attention. I use the word “dumped”, because it seems to be something the system just does – it isn’t really a person, who takes responsibility for the change in priorities.
Sometimes a team member just walks to the coffeemaker for a cup of mocha and comes back with a monkey on his shoulder. He just met “someone”. Sometimes it is a phone call that gets through or a email gone astray. No harm is probably meant, and it is presumably something important that needs to be done. It just wasn’t the priority. Other times, of course, it can be more direct and canny. Especially in large organizations, where the ethical self-correction of small teams has disappeared, there might be people who more or less prey on hi-jacking resources for their own projects. Often they look like executives, so the Team might feel it has to obey. These instances often go together with the sort of activities, which doesn’t stand too much exposure. There are also situations, where the situation in the company is such, that it is so weighed down by problems, that this hits the Team again and again. For instance if products with serious flaws have been released. Then you find yourself in the chaos domain and the Team either runs away screaming or a firm crisis management is required where a team stabilizes the situation while another attempts to find a new positive way forward. To be fair. There are also Teams, who seek interruptions themselves. Perhaps they are in need of challenges – just bored, although more often than not it is more a result of a bad habit: growing accustomed to not concentrating or focusing. It seems more appealing or even productive to just zap around between tasks.
Whatever the reason behind the interruptions, the result is destructive for the Team and the progress: Once the interruptions reach a certain size, a rule of thumb is approx. 10%, then the self organization of the Team stops working. “What is the use, soon someone will come along with something else, we need to do.” After some time the Team stops planning and rather randomly accepts the content of Sprints. The interruptions also have a very specific effect. Task-switching is incredibly expensive; it costs minutes, perhaps even hours to switch between tasks. Apart from this, it is also costly on the quality account. An interruption sometimes makes people forget half of what they were doing.
Therefore Scrum Masters: protect the Team, bring forth the visibility, red notes on the Sprint Backlog. People can then see the interruptions – where they came from and so on. It is surprising, how much that alone helps. The people, who bring the interruptions, usually do not want to be known by everybody. If this is not sufficient, then as the Scrum Master you might have to physically block the access to the Team. Get in front of a time-snatcher on the way to the team and with your most innocent smile ask if there is something, you can help with. You will find that many of them have “come the wrong way”.
