We all screw up from time to time.
It’s in those moments when the most important thing is to know who to blame.
Blame Management
Just kidding.
I just had an eye-opening experience. One of those ‘duh’ moments where something didn’t go as planned with my project. It was a simple, small piece of our system design that sounded great in discussions and on paper, but turned out to be unworkable.
After beating myself up a bit because we should have been able to discover this about 5 months ago, I reframed the problem.
Here’s how.
The 5 Whys
Developed by Sakichi Toyoda, this technique for root cause analysis is a big part of Lean Thinking. It’s also what we just used on my team to extract a big lesson learned from this problem.
Very simply, you start with the problem and ask why it happened. It’s important to not place blame per se and focus on objective causes instead.
Here’s an example that’s fresh in my mind, made generic for public consumption.
The Problem
Even though all stakeholders got together to discuss the new design and no flaws were found with it, we have uncovered a fatal flaw with the design now. It could have been discovered 5 months ago but was only found just now.
We’ve already solved the technical problem, what we’re doing here is discovering why it was a problem in the first place and why it took so long to discover it.
Why # 1
Why did a flawed design get universally accepted as valid?
It looked good to everyone at the time. We didn’t spot the flaw.
Why # 2
Why didn’t we spot the flaw?
This was an implementation detail no one thought about at the time.
(Important point: This is where it’s tempting to place blame on ‘those guys’. Don’t let the 5 Whys turn into the 5 Blames here. Think about the process, the system first. Usually it’s not a bad apple. But sometimes it is….)
Why # 3
Why didn’t anyone think about this implementation flaw at the time?
Because we hadn’t implemented anything.
Why # 4
Why hadn’t we implemented anything 5 months ago to validate our design?
We don’t release software until our waterfall milestones come around for major releases. Our development is done in silos with coordinated releases. We didn’t have a minumum viable product (MVP) or prototype to work with.
Why # 5
Why didn’t we have an MVP or prototype to work with?
Because we have not fully adopted lean thinking in this area.
Solution
Further adopt lean thinking and processes by developing rapid prototype code every time there is a major design change, a minimum viable product (MVP). Iterate on the MVP while getting continuous feedback from stakeholders.
{ 1 comment }
