This post is from leadingagile.com by Dennis Stevens.
Most of the organizations we engage with have more work to do than they can possibly get done. So, developers are writing code as fast as they can to get done trying to maximize their capacity. Typically, we see developers running way ahead of testing. Often, testing is still working on the prior release while development is running off on the next release – and testing just can’t ever catch up. This inventory of untested code shows up as long lists of defects, lots of code branches, untestable features, and products that can’t be integrated or regression tested until just before the next release. This vicious cycle of long bug lists, painful regression testing, and production defects colliding with the next release continues to grow.
The goal is not to write code faster. The goal is to produce valuable, working, testing, remediated code faster. The most expensive thing developers can do is write code that doesn’t produce something needed by anyone (product, learning, etc). The second most expensive thing developers can do is write code that can’t be tested right away. Recently, LeadingAgile’s Derek Huether wrote about Getting Teams to Deliver Predictably. He shows how having more work in the queue than can be performed slows down throughput. Pretty quickly, everything gets congested and things back up, building up latency and uncertainty in flow.
Click here to see the full post.
