ScrumMaster in a “Blocker” situation

From time to time it happens that you business encounters a so-called “Blocker” situation. An example of such a situation could be if your website went down (assuming you’re an online based company) or if you’re being hacked. I know, these are extremes and we don’t think they will actually happen – but they do. And when they do the team needs to drop everything resolve the issue.

Just the other day my team were in this exact situation (no, we weren’t being hacked). The website started to make hick-ups and all of a sudden response time increased. After a couple of hours the whole website stopped responding. This can be caused by a number of different reasons (I can’t disclose the actual cause here – and it’s not important) – but what IS important is that you, as a ScrumMaster, needs to navigate in a different set of rules than you would usually do… Scrum basically goes away…

The first thing that happens is that the team starts to “panic”. Panic in this content is NOT running around screaming (though I actually believe some did). In a group with multiple people there’s different roles set by nature and one of the more characteristic roles is the Alpha Male. In our case our alpha male started to take control of the situation and explaining what happened. The other team members was listening and while the “talk” was good for getting people onto the same page, not much came of it. As a ScrumMaster I’m here to facilitate and guide the team and that was what I intended to do… But after a while numerous people from the business would start to consult our alpha male instead of me. First thing that happens in this case is that I, as a ScrumMaster, receives second knowledge. I have one more player (the alpha male) to take into account and the lines of communication becomes more complex and information is lost.

I told people to stop what they were doing and asked them to explain to me – in a non-technical way – what was going on and how we could resolve it. The team turned to the alpha male and he started to talk. Though I got my briefing and the information I needed I only got it from one persons perspective. So after the briefing I address other team members individually to seek their input. This actually gave me some extended knowledge and I became more aware of the situation. Now, I know that this sounds like I’m afraid of the alpha male – that’s not the case, but messing with group dynamics during a crisis is not a good idea. It could potentially result in the alpha male backing down and not participating in the resolution of the actual issue – at this point I needed him to do what he was really good at – solving technical issues. Breaking his normal pattern would have let him on unknown territory and I needed him to perform.

At this point no one gave Scrum a single thought. We basically detached ourselves from our offshore team members who was, at this point, left in the total dark. All they knew was that the nearshore team was working on something else that the sprint the whole team just committed themselves to. I wanted to have everybody on the same page so I gave a briefing about the problem (from the very beginning) and we discussed the solutions that we have tried so far – and discussed the way we should focus our effort in the next hours. Everyone seemed happy about the briefing and one of our stakeholders were present at the meeting.

So, in Scrum terms we basically aborted the sprint and started working kanban in smaller teams. At this point the dialog was crucial for success and the misunderstandings in communication between the off- and nearshore team would raise the risk of success. I can’t honestly say that I think this is the best solution, but once in a while you’re still forced to do what has to be done.

To re-establish the lines of communications I came to think about an old movie I saw years ago (I forgot the title). The movie was about British soldiers during the WW2. A unit was trapped behind enemy lines and their communications had been cut off. The only thing that saved them in the end was their effort in re-establishing the lines of communications to those who could help them. With that in mind I gathered our team and had an improvised Daily Scrum. Now everyone was clear on the issues, what effort they should put in and the knowledge about what was going on. This brought back the awareness of Scrum and why we do it – and the team become more organized and resolved issues faster.

Eventually the situation was normalized and we could fall back to do re-planning of the remains of the sprint.