Everybody makes mistakes from time to time.
It is in these moments that it is most important to know who to blame.
Blame Management
Just kidding.
It was an eye-opening experience. It was one of those “duh” moments when something didn’t work out as planned. It was a small, simple piece of our system design, which sounded great in discussions, but wasn’t practical.
I was a little frustrated that we hadn’t been able to find this 5 months ago. But, I decided to reframe the problem.
Here’s how.
The 5 Whys
Sakichi Toyoda developed this technique for root cause analysis. It is an integral part of Lean Thinking. It’s what we used on my team to learn a lot from this problem.
Simply put, you need to start with the problem and then ask why it happened. It is important not to place blame and instead focus on objective causes.
Here’s a new example I have in my head, made generic for public consumption.
The Problem
Even though all stakeholders met to discuss the new design, and there were no flaws found, we discovered a fatal flaw in the design. It could have been discovered five months ago, but it was only discovered now.
We have already solved the technical problem. What we are doing is investigating why it was a problem and why it took so much time to find it.
Why # 1
Why was a flawed design universally accepted as valid?
It seemed good to everyone at that time. We didn’t see the flaw.
Why # 2
Were we not able to spot the flaw?
This was a detail that no one thought of at the time.
Important point: It’s tempting to blame ‘those guys’ here. Do not let the 5 Whys become the 5 Blames. First, think about the process and the system. It’s usually not a bad apple. It can be ….).
Why # 3
Why didn’t anyone consider this flaw in implementation at the time?
We hadn’t implemented anything.
Why # 4
Why hadn’t we done anything 5 months ago to validate the design?
Software is not released until major milestones are reached for waterfall releases. Our development is done in silos and with coordinated releases. We didn’t have a minimum viable product (MVP), or prototype to work with.
Why #5
Why didn’t we have a prototype or MVP to work with?
We have not fully adopted lean thinking here.
Solution
Continue to adopt lean thinking and processes by creating rapid prototype code whenever there is a major design modification, a minimum viable product (MVP). Continuous feedback from stakeholders is required to iterate on the MVP.
