Blockers First in Daily Scrum

Today we revised our Daily Stand Up Meeting practices. This is the same as the Daily Scrum i.e. 15minute meeting every morning to check out the current status of the project. We noticed that we should put the number one emphasis on blockers and always go through them first. You should go through the blockers first in daily scrum.

In Extreme Programming the Daily Stand up meeting the team should revise 1. what was accomplished (DONE) yesterday, 2. what will be attempted today (WIP) and 3. what problems are causing delays (Blockers).

In Scrum the daily scrum has the same meeting agenda, but the problems are called Impediments. I call Impediments and Problems as Blockers since they are things that block your progress, such as pending firewall requests, missing specification or instruction, some major bug, or missing feature developed by an external party not yet completed. According to my 10 year experience as project manager, I have realized that the blockers are almost always on the critical path of having the project completed, so the project management should be first made aware of them and secondly put all available effort and resources on them to resolve them in the quickest possible manner. Otherwise the whole team (from a few developers to hundreds) might be waiting without having much else to do, resulting in huge waste. Escalation of the blockers is always the number one task for the Project Manager.

Unfortunately there importance of blockers is many times not understood, and thus ignored. In almost all task management systems I have used at customer projects (such as Jira, Redmine, Trello etc) setting a task as a blocker (or impediment) is made very difficult or the functionality is well hidden in menus and thus not used. In many customer projects where Scrum or some other method is being used (PHZ.fi uses XP internally) I have noticed that even the official documentation might have omited from the daily scrum practice. For example this is a one real life example of the Daily Scrum -flow in use at one company:
Per task in WIP (in priority order)
1. Tell what you have DONE
2. Tell what you are going to do next (WIP)
3. Other things outside the task list
4. If you haven’t spoken out, do so now (so that everybody talks).

As you can note, there is no mention that the blockers should be separately mentioned, or that they have any particular importance. This real life example is also in stark contrast to the both Extreme Programming and Scrum official instruction. While both methods say that you should adapt the method to your own needs, it’s not a good practice to make the practices inferior to the original, if you don’t understand their meaning.

Thus, our conclusion was to revise the Daily Stand Up Meeting practice so that instead of going through DONE, WIP and Blockers, we go now it through in this order
1. Blockers
2. Done
3. WIP

To achieve this we had to actually redraw our Task Board columns to the same order, so that we have the Blockers first. Luckily we are using the http://tee.do Pure Lean Task Management Tool, which has the Blockers -column first by default, so this was easy to manage.

We noticed an immediate boost in our awareness of project status. The Blockers that had haunted us for weeks, vaporised almost instantly when attention was put on them. The project velocity also increased. We realized that going through the blockers first is a far superior method than the original order, so this change come to stay.