Agile Lean Six Sigma
Faster, Better, Cheaper
January 23, 2017
We all have a similar dual problem: we need to figure out what work to do, and then we need to figure out how to do that work. We need to be smart about what we do, but not take forever to get it done.
Former Notre Dame football coach Lou Holtz spoke on this dynamic 25 years ago:
"If you have speed with intelligence, you have an unbeatable combination. Speed with a lack of intelligence will get you in trouble. I’d rather have a slow guy going in the wrong direction than a fast guy going in the wrong direction. At least the slow guy won’t be as far out of position as the fast guy."
Many process improvement programs, especially Lean Six Sigma efforts, have not done a very good job of balancing speed and intelligence. There are myriad reasons. Sometimes it’s due to poorly scoped projects that are just too big to swallow, sometimes it's due to a paucity of change management skills, sometimes it’s due to an overemphasis on using complex data tools whether they are needed or not, and sometimes it's due to a lack of urgency and poor support by leadership. And then there's the training, which often emphasizes statistical rigor over speed — as if the M in the DMAIC roadmap stands for Months instead of Measure.
As my plant manager at Ford used to say, a really accurate description of screwed up is still screwed up (OK, his rendering was a little more colorful). If you need to improve by an order of magnitude in order to satisfy your customer, why delay while figuring out how to measure just how bad you are to several decimal points?
As a natural reaction to extended project cycle times, there’s a lot of emphasis lately on the "how to do the work?", but it may be at the expense of "what work should we do?". Agile methods are really useful to organize work and drive out waste. And failing faster can offer a useful acceleration of the learning curve. But Agile methods alone don't offer much in terms of specific analytical methods to ferret out the root causes of complex problems.
Methods to implement known solutions for known root causes are just very different than methods to find unknown solutions to unknown root causes. There’s some overlap of course, but also stark differences, and every organization needs to manage both types of work.
I'm trying to be a better tennis player. I'd like to just work on hitting forehand shots, but my opponents do not agree to only hit to my forehand. So I need to master a lot of different and difficult skills — relying on a single predominate capability just exposes other weaknesses. Tempting as it is to focus on a single approach to organizational improvement, it's just never worked that way. As Deming said, there's still no instant pudding.
We need both intelligence and speed, so those of us in the process improvement business need to figure out how to better marry Agile thinking and work practices to appropriate data‐driven analytical methods so we can achieve Lou Holtz's "unbeatable combination".
The onus is on Lean Six Sigma practitioners to incorporate a greater sense of urgency — to value time as much as measurement rigor. So let's look critically for heavy objects that don't add much value and throw them overboard. I think we've all seen some of those. For starters, unnecessary tools and unnecessary precision are excess processing, a form of waste. Let's get back to the pull signal from critical questions instead of checklists of tools. A strong dose of practical thinking and simplicity might really speed things up — a good place to start. At MoreSteam, we'll be working on that.