Is it possible to use Six Sigma Quality Management with Software Development Processes?
What's your experience on that?
If you're using an Agile method like Scrum or XP, isn't Six Sigma too bureaucratic?
I'm talking about quality management on software development as a whole, since requirements gathering until deployoment and operations, and not only the construction phase (which tools like TDD and unit testing are more or less already established as best practices).
If I understand it correctly, six sigma depends on having meaningful, measurable metrics. What will yours be? KLOC? Classes checked into your archive? Agile velocity?
Six sigma works great on shop floors, but I don't believe that software development is sufficiently "widget-like" to lend itself to such an approach.
I've used a wide range of methodologies, Six Sigma, Agile etc. Really the success of quality management on software development is dependent on one key thing. The quailty of the team. It all boils down to that. A good team can work within a horrible methodology and make it work. That's why they are good. Process is important, and you can make a bad process more efficient, but it's all dependent on the team.
Six Sigma works well with reproducible processes. By that, I mean pure process that consistently produces (or is supposed to produce) the same output. Given that software development rarely produces the same output, SS is not really applicable, IMO. This is because software development is more a practice than a process.
That being said, it doesn't hurt to read about it and try to see what top-level ideas can be put into software development...
I am not sure to follow you.
SixSigma is a is a methodology to manage process variations that uses data and statistical analysis to measure and improve a company's operational performance.
So take any process (SDP or other), choose what you want to measure, identify the issues, plan the solutions, evaluate the impacts.
The SixSigma projects I have participated were all fairly transversal and not linked to a software life cycle.
By transversal, I mean transversal to the "product design-development-construction-delivery" process that is software development.
For example, in an environment were we need to produce a set of programs running on our internal production platform, most of our SixSigma projects are centered around Operational Architecture, that is "making operational an execution environment" (how to set up servers and networks in order to stop, update, install and launch a set of executables, and that for many projects each with their own SDP).
That is a notion transversal to any SDP you want, since in the end, all those "Development Processes" have but one goal in common: put your software into production.
The criteria to measure were precise and reproducible, going from the time to manage the merges needed to consolidate a final executable to the number of merge errors to the deployment errors (because of an incorrect labels or a faulty release notes).
All those missteps were noted release after release, and the goal was to reduce them.
One side-effect was to identify an inadequate merge workflow, workflow which, once fixed, allowed us to greatly reduce the errors in the final set of deliveries.
For Six Sigma to be useful you need easily comparable metrics or procedures.
Software is too abstract to have the type of metrics needed.
Maybe a good question to ask would be
Is there a quality control tool for software development similar to Six Sigma for the production and manufacturing world?
It is definitely possible as long as you aren't developing a new product.
Just follow these steps.
1) Create a bug free version of the application. This may take a considerable amount of effort thus it is best to select an application that is trivial in scope.
2) Recreate the application from scratch and compare the iteration to the ideal created in step 1 to create a metric.
3) Tweak your process to acheive closer alignment next to the metric on the next iteration.
4) Go to step 2.
What? You don't create the same application over and over in your shop? Hmm, I don't think six sigma is going to be much use in that scenario.
There are parts of software development that don't fit well, as they do not provide a process with a normal distribution of results. On the other hand, the focus on risk, value and doing the right things is essential
Six Sigma can be a good fit for maintenance teams that have a big backlog of discrete work items.
Design for Six Sigma has some elements that can be applied to building a new software product.
And since most software is an enabler to a business process, and that business process may be a highly repeated process where the statistics tools of six sigma can be applied, six sigma can have a role in determining what the highest value software feature is to deliver maximal business value. It can take the emotion out of the decision making process for feature prioritization. If you have an environment where the product manager/stakeholder who yells loudest or most eloquently got their stuff built, six sigma can be applied to fix that unhealthy aspect of your development process by putting some rational measurement behind the prioritization process.
I had a professor in a class that taught six sigma and other manufacturing efficiency techniques, and after telling him I was in the software development field he suggested the book Lean Software Development. Unforunately I haven't read it, but it seems to deal with applying some of the applicable concepts of six sigma and lean manufacturing to producing software (like eliminating waste, reducing defects, continuous improvement). Here's a short white paper describing lean software development.