What Are Blockers?
In scrum, a blocker is anything that is outside your control that is impeding progress on your task. Usually this has to do with a dependency on another team in the company.
For example, suppose you write test software to validate hardware’s functionality. You have some dependency on the hardware team in order to provide that hardware to test.
Blockers can be quite frustrating. It seems you can’t make any further progress without someone else’s help. All too often, that other person has different priorities that prevent him or her from helping you in a timely manner.
But is there really absolutely nothing that can be done to make progress? Sometimes clever solutions yield some other avenues that can be taken.
How to Crush Obstacles
There are some blockers for which you have no control. But quite often there are some things you can do to continue making progress towards your goal.
A great example of this was given during one of the Certified Scrum Master Trainings I attended.
We divided into three teams, each with a product owner and ScrumMaster. Unknowing to the rest of the team or ScrumMaster, the trainer had told the product owners to be very, very aggressive and difficult to work with.
The object was to create origami figures from colored paper that the trainer had in his possession. Each figure had a point value, with more difficult figures being worth more points.
When ScrumMasters or other team members asked for paper, the trainer gave ridiculous feedback.
- Exactly how many sheets do you need?
- I need to know the exact dimensions of the pieces of paper that you need.
- Do you have a technical document describing what is needed with this paper?
Eventually, someone went up there, distracted him, and quickly stole the paper and walked off.
The trainer praised this person. The object here was to ignore the “stupid” processes/politics/whatever else impedes a team’s progress and to just get what is needed. To just plow through.
This was a clever approach to getting through a blocker. But what about more realistic examples?
In one position, I was setting up a Jenkins build server and needed the ability to send out an email if the build failed.
For reasons I won’t explain in this post, I could not get access to it. So I worked on my “own solution”.
I allowed Jenkins to SSH into my (Linux) computer and generate an error message pop-up when the build failed. So right at the center of my monitor a pop-up would tell me when the build failed.
- Was it annoying? You bet!
- Did it serve the purpose? Yes!
- Was it the best solution? Absolutely not. Using email would have been much better.
- Was it better than no solution at all? Yes!
I was able to creatively work around some unreasonable restraints and come up with a solution.
Source Code Configuration Management
In another situation (one I’m currently working on), I had to release code through a GUI that was extremely difficult and slow to use. Every time we tried to release software, it required us remembering how to do it. Even then, we often made mistakes.
Once again due to political problems and other people having different priorities, we couldn’t get the information we need to the “correct” API to use.
So instead, I found an API to that GUI.
Using this, I was able to automate a large part of that process. So again…
- Was it pretty? Not even close!
- Are there better ways to do it? YES!
- But, again, perhaps the most important question: is it better than no solution at all? Yes!
Breaking through these obstacles can be really challenging sometimes, but the rewards are quite large for some of these tasks. In those cases, I encourage you to think of ways – even if they aren’t pretty – to cut through the crap. Cut through the corporate politics nonsense, the overused excuses, and everything else, and just find some way to solve the problem.
I want to make this clear: the purpose of this post is not to say that all obstacles can be overcome without someone else’s assistance. Getting assistance is often the correct approach.
But due to politics, priorities, or other reasons, you may not always be able to get that help when you need it. This should not be a cause for immediately giving up.
As explained, there are some different ways of working through a problem that allows teams to still make progress. Sometimes the solutions are very convoluted workarounds. However, sometimes having some solution, even if ugly, is better than having no solution.
Consider alternative approaches to obstacles that block your progress on a day-to-day basis. You may find an alternative solution that helps you make progress.