Rework is just another word for money down the drain. Not only does it wreak havoc with your delivery, but it can be unbearably demoralizing for your development teams. To minimize rework, think of it like a goldfish that grows as big as the space you give it – bigger bowl, bigger fish. You have to shrink the space that rework lives in before it becomes fishzilla….
The rework monster lives in the gap between your developers and your QA teams. If coders and QA are on the same team, rework is kept to a minimum. But in organizations with a large gap between development and QA, rework can grow big enough to consume every resource in sight. What if circumstances force you to keep your coders and QA teams separate?
We worked with a company in the medical equipment industry that faced a huge rework problem. It wasn’t all their fault. The equipment they manufacture must be approved by the Food and Drug Administration (FDA). This, of course, puts them in a highly regulated environment with stringent requirements. To ensure compliance, they had a separate quality department. Unfortunately, this separate department meant a wide gap had been created between developers and QA.
This gap gave the rework monster plenty of room to live and grow in. With everyone working in silos, code would sit for months before being validated. Costly cycles of rework had grown completely out of control.
Folding QE into IT was not an option. But, there’s always a way to close the gap. So here’s what the company did. They reorganized and added new QA people to their IT department, leaving QE in operations to work exclusively on FDA requirements. That way code could be tested internally before making its way up the line for FDA approval.
Our client was able to stop the rework and adopt a faster, smoother cadence, propelling projects forward every two weeks with tested code. They are even beginning to identify bottlenecks and solve them – on their own initiative.