If you track obstacles electronically, some of this process changes. Many APLM tools allow for issue tracking. Hopefully, the intent and result of this post still makes sense.

Blocker Board
Always preferring high-touch and visible information radiators to track items, I tend to make a physical blocker board for teams I work with. Why do I call it a “Blocker Board”? It alliterates. I am finding it to be a problem to call it this. Perhaps I should change it to an “Obstacle Catcher”, or something that doesn’t make people think the sky is falling, just that we’re hunting for the system constraint.

Reviewing obstacles
Hopefully the obstacles are being removed quickly, and reviewing all obstacles identified during stand up lets the team verify the ones which have been removed. Having the requestor on the card lets that person verify the obstacle is gone. For the new one’s added, adding the day’s date, lets the team understand how long it took to remove, when verifying with the requestor. This review also gives a moment for people to think if they know (or want to admit to) another obstacle in the team’s way.

Obstacles are non-debatable
Having a working agreement that nobody can debate when someone states the fact they know of an obstacle helps ensure people feel comfortable bringing things up. If it is pushed off as, “not really an obstacle” or, “not an obstacle yet” can be very deflating to someone and cause them to resent mentioning it. Even if the requestor does convince others and writes it up, they may feel apprehensive that it will truly be removed.

Obstacles must be removed immediately
Having another working agreement that everyone should endeavor to get obstacles out of the way immediately, helps the morale of the team. Obviously, this allows the team to be as productive as possible. Removing obstacles immediately builds trust within the team and with management, increasing the camaraderie and expanding the notion of who is on the team. Immediate removal motivates the team, increasing respect by dealing with issues brought forth, without questions asked.

Avoid assigning owners and due-dates
Some obstacles take some time to be removed, even when endeavoring to have them gone by the next day. Assigning owners and due dates is a threatening stance. This is doubly true if obstacles are shot down as really existing when initially mentioned. Assigning one owner, especially at stand up in front of the team, implicit blame is laid on this person for having a problem. The date can only be a guess, and is now given under duress, if it is also in front of everyone. Date assignment allows the person to procrastinate on it, or use it as political leverage. It is stating that the team is fine allowing an obstacle to exist, and slow down the system. For political leverage, it is saying that I will not remove this obstacle, until you do something on my behalf. With the date being a guess, what happens when it comes up and the obstacle is still around? How much are you allowing someone to “game the system”? Assigning owner and due-date erode the sense of team and of collaboration. Avoid this, no matter how much you may feel it is the right thing to do.

If all else fails, prioritize obstacles
When the rate of obstacle removal is less than the rate of obstacle identification, there is yet another obstacle in the way. It might be incredibly difficult to find. In the mean time, prioritizing the ones that are identified helps find the greatest one for the most people. This may be close to, or a symptom of, the system constraint.

Finding the system constraint
Somewhere in the system, there is a very large obstacle, causing a bottleneck that could potentially be jeopardizing success, destroying morale and causing most of the stress. This is the team’s most significant impediment. This constricted area is the system constraint, and is where work passes through at the slowest rate. Having the practice in place of including the date added shows which ones have been around the longest, pointing the way. Agreeing to remove them immediately adds to the significance of obstacles that won’t go away. Prioritizing obstacles will also help identify symptoms of this constraint, and maybe even the constraint itself. Adding the requestor allows the organization to recognize the person who found this constraint, and reward them along with those who removed it, for helping to bring the team to a greater level of performance.

Removing the system constraint
Theory of Constraints explains it thus:

1. Find the system constraint
2. Elevate it (highest priority)
3. Subordinate everything else (nothing is more important)
4. Exploit the constraint (get rid of it for now and forever)
5. See step 1

Eventually, the largest obstacle which cannot be removed is found. Keeping this part of the system on a regular cadence and knowing it cannot go faster, makes it the heartbeat of the organization.