The minute you are asked to complete something ASAP is the exact moment when quality is no longer a concern. You begin making sacrifices to complete your work. In terms of software development you can’t hold accountable a developer for high quality and craftsmanship when they are forced to complete something as soon as possible.
Allowing the developer to work within the time estimates they give is part of the business’s commitment to quality. It’s as important as driving out the business requirements and understanding ROI. If speed to market is crucial part of the project, iterative development should be adopted. The business and development teams should work together to flesh out the prioritized list discretee of minimal marketable features that can be developed quickly, with high quality, and delivered to production independently.
Another way of looking at the problems caused by an ASAP mentality is by the risk it creates. Quality and ASAP are mutually exclusive terms. If you’re trying to complete something as fast as possible, you greatly increase the risk of downstream surprises. Nothing derails progress as fast as production bugs. When this happens not only are you forced to fix what’s broken, but that effort can also bring new development to a halt as the solution works its way through development cycle back into production. If it takes a day to fix a bug that’s 8 to 10 hours of lost productivity as the problem is investigated, corrected, tested and released. If you have resources working to fix the bug that earn $100,000 annually, it’s costing you a conservative $400-$500 in lost productivity. That’s money not being spent to move the business forward. Poor quality is measured in dollars by the amount of time you’re not working on projects that move business forward.
To be clear, I’m not making a case against speed to market. I’m making a case against sloppiness. Speed to market is a difference maker, but you cannot make a difference if what goes to production has bugs. Trust is built during the effort to optimize the development cycle. It doesn’t happen overnight, but eventually the business should derive satisfaction from knowing that if a project or task has an estimated cycle time of 2 weeks, you’re going to see results in 2 weeks, and the development team should derive satisfaction knowing that the business is taking their word on estimates.
For the record, I’ve personally watched the business demand projects be done ASAP and every single time there was always a problem with the production release. In each case the irony was that the business always expected fast results, but didn’t get them, and the finger was always pointed at IT for the lack of quality.
SQL - Data - Life 