Choose the simple and good process over the complicated and perfect process. The value of universal understanding outweighs the value of accounting for every possible edge case and gotcha.
I like to talk about processes in terms of recite-ability. If everyone involved in the process can’t recite it off the top of their head, try to simplify it.
Look at the humble Kanban board with Todo, Doing, and Done columns. Everyone knows which column their ticket should be in. There are only 3 of them! Simple!
That’s why we should think long and hard before adding that In Review column or the Awaiting Deploy column. Those should only be created when not having them becomes torture. Each one makes the process that much less recite-able. If a team’s board has so many columns that the average team member can’t recite them all from memory, that’s trouble.
The 80/20 rule applies, as always. If I can get 80% of the value of a process with 20% of the complexity, then that’s a tradeoff I’ll take almost every time. Of course there are exceptions, but I find that they aren’t as common as we’d expect.
I know it feels safer to account for everything so that there’s nothing left open to interpretation. But then we’ve just replaced one problem (“if X is true the we’ll have to do Y manually and that allows for human error!”) with a worse problem (“nobody deeply understands this so they’re making mistakes or ignoring it altogether”).
One of my favorite rules for spotting broken processes is: when times get tough, if people run away from the process instead of towards it, it’s broken. And when people are freaking out, they run away from complexity and towards simplicity.
So strive for simple. A simple process is a happy process.