A few years ago, Decade's founder, Kevin Delaney had dreams of improving the quality of our products and services, but he did not know how. He explored a methodology called Six Sigma and tried to make it work here. Ask anyone of his results, and most—if they speak their mind—will tell you that his effort was a complete failure.
Anyone would say that—except me.
I know what you're thinking—that I am merely stroking the boss' ego—but please postpone my conviction until you hear me out—as I offer my perspective on why Six Sigma failed at Decade Software.
The core of the Six Sigma ideology is built around a philosophy called DMAIC: Define, Measure, Analyze, Improve, and Control, which in itself is a sound concept. The problem? Six Sigma dictates that the Defining, Measuring, Improving, Analyzing, and Controlling be started by management, or worse—since management is not usually experts on the subject—the Defining, Measuring, Analyzing, Improving, and Controlling originates with consultants—outsiders to the team.
Samuel Langhourne Clemens' once said...
"There are three kinds of lies: regular lies, damned lies, and statistics."
The fact that everyone on the planet believes Mark Twain's assertion to be true is why DMAIC does not work as described above. If the individuals doing the actual work—the team—do not do the Defining and Measuring, they will not believe in the numbers and therefore will not work to improve them.
Being technical people, Decade's Development Team recognized the logic of DMAIC, but without trusted numbers driving the process—and with management using those numbers as a command and control mechanism—there could be no buy-in from the team, and no process, project, or philosophy can succeed without support from those tasked with supporting it.
There were limited Six Sigma successes at Decade—mostly in Marketing and Administration—but if you peeled the layers, I have a sneaky suspicion that the successes were due more to DMAIC than to Six Sigma as a whole.
For the Decade Software Development Team, Six Sigma was a failure, but DMAIC—what some refer to as the common sense part of Six Sigma—was a keeper. Quietly and quickly, the Development Team began measuring and improving it's own processes. Something many in the department had sought to do before, but DMAIC allowed us to define the thoughts that were floating around in our heads.
As an engineering process, we had adopted the Rational Unified Process, but there were problems—problems we could monitor and fix incrementally over time. The RUP dictated that we create a Development Case, and then refine and improve it at some designated interval. The RUP did not tell us how to do this, so we used the principals of DMAIC.
In Quality Assurance and Requirements, we adopted Use Cases that allowed requirements to be traceable from the day of inception, to implementation, and finally to any future defects logged against it. In each area, we measured our deficiencies and found places to improve.
Eventually, Scrum was discovered—a methodology that could actually improve our process improvement. It did so, by pushing teamwork and making everything transparent to everyone, allowing no room for lies, damned lies, or unsupported statistics.
Scrum is not an engineering methodology, like the RUP. It is a management methodology as is Six Sigma, but unlike Six Sigma, it requires that the team or teams define and track it's own metrics.
Through Daily Stand-ups and the Sprint Burn-down Chart, numbers provided by individual team members are monitored and reassigned as needed. Sprint Retrospectives are held to measure failures and develop plans to correct failures. This information is carried over into the Sprint Planning Meetings. Throughout the process, the team is Defining, Measuring, Analyzing, Improving, and Controlling it's own development process and progress.
Unfortunately, Six Sigma—as a whole—did fail at our company, but the core idea—DMAIC—is still alive and thriving. For the Development Team, it evolved into Scrum.
No comments:
Post a Comment