On the whole, my experience is that most organizations value shipping something by a deadline over quality and have become used to spending between 30 and 60 percent of their resources fixing issues after the deadline. The immediate emotional rush of shipping something now trumps shipping something that works, even if customers are not happy and costs are more.
- Your customers’ desire to order more of what you sell because it works. For internal IT organizations “more sales” means avoiding being replaced by an external supplier.
- The total effort spent in rework throughout the project including the time for:
- Redoing requirements
- Redoing design
- Repeated testing cycles and bug fixing
- Meetings and maintaining lists to communicate among developers, testers and managers on what bugs to fix
- The total effort spent on software maintenance after delivery.
The knowledge level of engineering and quality practices across the software development community is, on the whole, limited. “We do Agile and some test” covers the bottom end of the range; the list of practices below covers the middle to the top end.
The following practices can be performed to clean up quality regardless of the project lifecycle model being used. If you are starting a new project, work from the top of the list. If you are in a buggy mess, pick from the end of the list for starters.
- Peer reviews of requirements, design information and interfaces
- Prototypes and simulation
- Peer reviews of code and interface definitions
- Peer reviews of test cases and test procedures
- Component testing
- Code coverage checks to determine what code has been tested
- Process audits to maintain the adoption of the organization’s best practices
- Integration testing
- Analysis of defect statistics to determine product state and areas for further investigation
- System and acceptance testing using the intended environment, user-oriented requirements and exception conditions
There are a host of other practices that exist to prevent quality problems, such as configuration management, requirements elicitation and risk management. See a good list at “What Does a Great Product Development Group Look Like?”
But there is no time for quality!
Don’t add time to the schedule for quality. Look for opportunities to replace existing rework with quality practices.
The goal is not to perform all quality practices immediately and aim at zero percent rework. Zero percent rework is not achievable and such a goal is not practical. Instead make a few rudimentary calculations of your quality and rework levels and aim to reduce the amount by 20%. Then select two or three practices and try them.
If you would like help addressing your quality and rework challenges, please contact us for a complimentary 45-minute chat, or just send an email.
[Forward this email to your boss! Subject: Here’s a cool tip for you] Quick Link