Spotting broken processes

Rule #1: processes should be universally understood

If you asked everyone on your team affected by a specific process to explain it in detail, would they all be able to? Would they forget pieces, or get confused, or get the order of the steps wrong? If a process isn’t completely clear to everyone affected by it, then it’s probably a bad process.

Subjective processes are a common example. For example: the process for determining ticket severity. Is “New Feature XYZ” a “major” or a “critical”? Depends on who you ask and what their role is (although the Product Owner’s answer is the only one that should matter). Subjectivity in a process is often a sign that the process isn’t helpful. What would happen if you got rid of the “Severity” field altogether?

Rule #2: processes should protect people

That’s the whole point of even having a process. If the process is not protecting people, then at best it’s doing nothing and at worst it’s harming people.

What “protect people” means varies a lot depending on the type of process. But really think about it. Is there any chance that a process you’re using is making someone’s life harder than if you didn’t have it at all?

Rule #3: when things get tough, people should run towards the process, not away from it

When crunch time hits, or when production goes down, or when someone smart is out on PTO, what happens to the process? Do people cling to it stronger than ever, and rely on it to get them through? Or do they abandon it because they think they don’t have time for it?

A good process will naturally be followed no matter how crazy things get. If people abandon a process when things go south, then that process is probably a flop.

Rule #4: processes should be centered around constraints

The Theory of Constraints says that any efficiency gain at a non-bottleneck is an illusion. Increasing efficiency before a bottleneck just causes work to pile up at the bottleneck, and increasing efficiency after the bottleneck makes that phase even more starved for inputs.

If you’re tweaking a process, ask yourself, does this process focus on exploiting and elevating the constraint that we have? If not, then why are you wasting time caring about it?

Once you have those 4 rules locked in for a process, then you know you’ve got a winner.