In the previous post we touched on blockers a bit, however, one thing we have learned is that there is a large variance between clients on the understanding of what constitutes a blocker and how to use them while maintaining maximum flow.
The advice we have been giving clients based on dozens of projects for the workflow getting from backlog to demo:
- Is the work just incomplete yet adds some incremental value? If yes, it’s not a blocker. A new card in Next of Backlog should be created for the remaining work.
- Have additional requirements been added? If yes, it’s not a blocker. The extra requirements should prompt the creation of a new card.
- Is it truly a regression? Does previous functionality no longer work as expected? If yes, then it is a blocker and needs immediate attention.
There is a nuance that should be explained with rule #1. The entire purpose of this rule is to avoid a log jam preventing deployment to demo. The only way cards get into this state is if the requirements were not clear to the developer or the team lead missed something in the review. We are not advocating intentionally merging feature branches that are incomplete. What we are advocating is when the mistake happens there is no need to block it, thereby blocking the rest of the approved cards that might also be in demo from being able to be released.
Resolving blockers should be approached with expediency first, elegance and completeness last:
- If you can unblock by commenting out some code. Do it.
- If you can unblock by putting in some small hack. Do it.
- If you can unblock by reverting a commit. Do it.
If you take shortcuts like these to unblock a release, you should leave comments in the code and create card(s) in the backlog for addressing them so that the client can consider when queuing up cards in Next.
The idea in general is lots of small successive iterations is better than longer, drawn out iterations. By using these strategies you can keep your blocked time to a minimum, increase flow, and make overall better progress.