My company wants to bring Six Sigma rigor to our Agile sprints to improve code quality. However, the developers feel that the heavy documentation of DMAIC will slow down our velocity. How do you balance the need for statistical data with the Agile Manifesto’s preference for "working software over comprehensive documentation"? Is there a "Lite" version of Six Sigma that works for two-week cycles?
3 answers
The trick is to not treat Six Sigma as a separate "project" but to embed the tools into your existing Agile ceremonies. For example, use a "Five Whys" analysis during your Retrospectives to get to the root of a failed sprint goal. Instead of full DMAIC reports, use automated dashboards to track "Defect Density" and "Cyclomatic Complexity" as your Measure phase data. This gives you the statistical insights without the manual paperwork. You aren't adding "weight"; you are adding "precision" to your inspections. The goal is to use data to make better decisions during the Sprint Planning, which actually increases velocity over time by reducing the amount of re-work.
Have you considered using Kanban boards to visualize your "Work in Progress" limits as a way to identify the bottlenecks Six Sigma needs to solve?
Focus on the "Definition of Done" (DoD). Integrating Six Sigma quality levels into your DoD is the easiest way to ensure high standards without extra meetings.
Exactly, Elizabeth. Strengthening the DoD with clear, measurable quality gates is a proactive way to bake Six Sigma principles into every story.
Thomas, we are actually moving to a Scrumban approach for that very reason. The Kanban board is making it painfully obvious that our "Testing" column is the bottleneck. We plan to apply Six Sigma analysis specifically to our automated test suite to see why so many tests are "flaky" and failing for non-code reasons. By focusing our Six Sigma efforts only on that specific bottleneck, we hope to win over the developers by showing them that the data actually helps them spend less time fixing broken builds.