During a recent presentation, I was asked how I thought Agile changed the landscape when it comes to Lean Six Sigma. It’s a good question that bears some examination. But maybe not a lot, since they are not competing, but rather complementary methodologies.
So, first, why do we use Lean Six Sigma (LSS)? LSS is great when we have an opportunity for improvement, and we need to identify the root causes and develop solutions addressing the opportunity. Basically, LSS, or specifically DMAIC, is a problem solving methodology where we Define the problem, validate the existence of the problem by Measuring it in data, determine the root causes for the problem through Analysis (Analyze), identify the possible solutions, and then narrow that list down to what will be implemented (Improve) and then validate the solution had the desired effect (Control).
But, what do we do if we don’t know the problem? In some cases we know a problem exists, but we can’t quite “put our finger on it”. Everyone agrees something is wrong. This is where Design Thinking is useful. Design Thinking brings a team of people together to use a creative process to clarify the problem. We can think of DMAIC following the scientific method, where we establish a hypothesis and then evaluate it. With Design Thinking, a more creative process is followed to identify the problem and then approach solutions.
In those situations where we have a problem, and it has never been encountered before or we have no current method to handle it, then we can use the Design for Six Sigma (DFSS). Using this approach, we start with nothing, and work through the solution using the DMADV process. DMADV standard for Define, Measure, Analyze, Design and Verify. The overlaps to DMAIC should be obvious.
When we are starting with a challenge problem which is related to an existing process, we can use DMAIC to clarify the problem, determine the causes, and select and implement the best solution.
But where does Agile fit into this? Agile, from a software development approach, wouldn’t be used until the project team has decided on a solution to the problem, where the solution involves some form of software development. Once the solution has been selected, we can write the user stories, have the development team sprint to complete the development of those user stories to implement the solution. When IT has completed the development, the solution can be implemented and we can verify the impact of the solution.
The analogy I heard used to describe how these approaches work together is that of a rope. If we consider Design Thinking, DMAIC, DMADV, Agile and other methodologies like DevOps to be the individual threads, when you weave them together, the “rope” is strong, and allows you to select the best elements from each to quickly identify, clarify and solve the unique problem you are working on