Most organizations have their batch size tuned so as to reduce their overhead. For example, if QA takes a week to certify a release, it's likely that the company does releases no more than once every 30 or 60 days. Telling a company like that they should work in a two-week batch size will sounds absurd - they'd spend 50% of their time waiting for QA to certify the release! ...
Imagine moving to a two-week release cycle, with the rule that no additional work can take place on the next iteration until the current iteration is certified.Okay, I'm with him so far. So the week-long QA cycle is treated like a one week long task in a Gantt chart. That makes the reduction to a two week release cycle seem counter-intuitive. But:
The first time through, this is going to be painful. But very quickly, probably even by the second iteration, the weeklong certification process will be shorter. The development team that is now clearly bottlenecked will have the incentive needed to get involved and help with the certification process. They'll be able to observe, for example, that most of the certification steps are completely automatic (and horribly boring for the QA staff) and start automating them with software. But because they are blocked from being able to get their normal work done, they'll have a strong incentive to invest quickly in the highest ROI tests, rather than overdesigning a massive new testing system which might take ages to make a difference.Ah-ha. The key bit of insight is: don't assume that task duration is necessarily static. Clever scheduling can apply pressure to drive out waste in a system. When you compress the time allotted to complete a project, your team is probably smart enough to identify and take advantage of opportunities for automation.
(By the way, Eric's original post lives here.)
No comments:
Post a Comment