Your Happy Path is Not Your Process
You need to do more than just describe a process to know what you are doing.
This is a well-quoted Demingism. I quote it all the time.
But there is a danger that we short-cut-prone humans take and that’s to delude ourselves that the story we tell ourselves about our work is actually a definition of how things really happen.
The Easy Read
We read this quote and then think in our heads “oh my process is that I get this thing, I do this stuff to it, then I give it to someone else and they modify it, where it gets sent to this other person who gives it to the customer.” We create a neat fiction about workflow and think that it is process.
But a process is not merely the “happy path” steps to completion. A process happens in context and our happy path descriptions rarely acknowledge our context.
In short, simply being able to describe what you are doing as a process does not mean you know what you are doing.
You actually have to understand your system.
No short cuts.
The Hard Read
This is the most common happy path I see on Personal Kanbans around the world in almost every industry. We get work ideas, build them, and send them out! So easy! It is filled with design flaws. It is not a system.
It doesn’t take too much effort to see that there is no way this can be a real workflow because any time you build something without identifying quality up front, you will end up defining it at the end. In this case, that last QA verification step happens at the end and there is zero opportunity to fix what you will inevitably find in an over-eager process like this.
Your process more likely looks something like the one to the left, filled with pitfalls.
This, more realistic process is, ugly and filled with coping mechanisms that engage when your work inevitably goes awry. In our happy path, these coping mechanisms are not explicit. We don’t acknowledge them.
The pitfalls are always painful, they rarely lead to improvement, and you explain them away every single time by convincing yourself that they are anomalies or other people’s fault.
When this happens, you are at risk of being certainty-deficient. The more failure demand you experience, the more likely it is that you will reach out for canned processes or consultant to come in and tell you what to do.
You are seeking false certainty. Your problems won’t go away, you’ll just be distracted by doing exercises that other people tell you are a good idea.
In the end, if any consultant shows up, their main goal should be to work with you to understand what is really happening in your group and, once that understanding is achieved by both of you, provide mechanisms for you to improve your own system.
You, personally, need to be able to describe your process, as it really happens, in order to know how to fix it. It’s not good if you just describe your happy path and even worse if you accept someone else’s simplistic process and then say you do that.
Pro-Tip: Agile, Lean, Scrum, and Six Sigma are not your process. If you think they are, go back and read from the top. Saying “My process is scrum” is like saying “my native language is syntax.”
