Improvement Insights Blog
SPC for Software Development
I just got an email from a guy trying to sell his IT department on Lean Six Sigma and SPC for software development and maintenance. Needless to say the main developers were not too pleased, but basically made the argument that SPC cannot be applied to software cycle development because there are no repetitive processes involved, but rather it is reactionary to external (or unassignable events). He wondered: How would I be able to apply control charts to this environment. Maybe such an environment cannot be ‘controlled’?
This is actually the lame argument that every so called “artist” uses to explain why they shouldn’t have to learn how to monitor and improve their processes. Everything, including software, follows a process. Just because your process is a random, chaotic walk that produces buggy, feature-poor software that routinely misses due dates, doesn’t mean that you don’t follow a process.
The Software Engineering Institute (SEI) has a capability maturity model (CMMI) that’s been in existence for 20+ years detailing the stages of software development/maintenance lifecycles:
1. Chaos
2. Repeatable
3. Defined
4. Measured
5. Optimized
(in other words, steps 3-5 are DMAIC/PDCA)
The latest software development process is called “Agile”. What’s Agile? Lean applied to software development. Small batches of functional code delivered biweekly.
If you google “spc for software development”, you’ll find a slew of articles on how to do SPC in software:
My advice: Don’t buy this B.S. because it’s IT’s way of trying to avoid doing the right things right by clinging to a craftsman model of software development that’s as silly as cobblers trying to resist becoming Nike.
So much of business today depends on IT for the speed and quality necessary to compete in a global marketplace that IT has to get on board with Lean Six Sigma and SPC or risk killing the company.
