Typical roadblock answers we hear include:
1. I don’t have the development environment ready yet
2. We don’t have necessary skilled people to augment the team
3. We have not received the licenses yet for the software
4. We have a key person missing in the team
and many variants of above issues.
The Scrum Master records the blockers, and no doubt takes action on them. However, over a period of time, my observation has been that, just sharing the blocker is less efficient. I feel that one should also share the impact of the blocker .
For example the above blockers could be reworded as
1. I don’t have the development environment ready yet, due to which I cannot start iteration 1
2. We don’t have necessary skilled people to augment the team so, we cannot start the project .
Yes, it is implicitly expected that the impact is automatically expected here, but it never happens.
As soon as the “impact” is shouted out, it creates its own listening . It pushes the people to think from the goal perspective rather than just removing the blocker.
Summary: The answer to the 3rd question could be reworded as
My roadblocks are … . and the impacts on this project are….
Let me know if you think it makes a difference ?