Spotting broken processes

The Agile Manifesto starts out with “Individuals and interactions over processes and tools” and yet, bad processes haunt us daily. How do we know when a process is doing more harm than good?

First of all, is this the most important problem?

First things first – are you sure that you don’t have bigger problems than bad processes?

I like to use the 3-P model: Purpose, People, and Process, in that order.

  • Purpose: Do people understand WHY we are doing what we’re doing? Are they bought into the mission and focused on delivering value (i.e., outcome vs. output)? Or are they just working tickets with no higher meaning?
  • People: Are team members happy? Are they enjoying the work and each other? Are they motivated to do great work? Would they choose to stay on this team if another option came up?
  • Process: We’ll get to that. Calm down!

If either Purpose or People seem to be having problems, then you may want to focus on those before you start dealing with Process issues.

For example, if your team is focused on resolving tickets rather than delivering value, then you have Purpose issues. That is a team of mercenaries instead of missionaries, and no amount of process work will fix that. Or if the members of your team are grumpy and unmotivated, then you have People issues. That should absolutely be where you start with your team debugging.

But if neither of those is true, then maybe Process issues are the most critical for you. So read on!

Spotting a busted process

Before you can fix something that’s broken, you have to know that it’s broken. With processes, that is often the hardest part, because we often don’t even think about them consciously anymore. They fade into the background after a while, and they just become a part of how the world works.

So let’s first talk about how to take a step back and see a busted process for what it is.

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?

Fixing a busted process

This section will be embarrassingly small, because fixing a process means so many different things depending on the process.

All you’re trying to do here is make it conform to the 4 rules above:

  1. Make it simple enough that everyone can easily recite it off the top of their head
  2. Make sure it protects people. It should reduce stress and pain rather than adding it.
  3. Make sure people cling to it when things get tough, instead of abandoning it.
  4. Make sure it focuses on the constraints – i.e., the things that really matter.

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