Received a comment this morning on tiny iterative releases... Want to clarify something:
The comment was: if our typical release these days is likely to take a whole month from inception to production (half-a-week for analysis/design, week for dev, week for testing, week for uat/bug correction, half-a-week for deployment) then making it any smaller won't be practical as it would put too much pressure on everybody.
My answer to that is twofold.
Firstly, I'm not suggesting making releases short and keeping the same scope. If release contains only one incremental enhancement it should not take entire two weeks for testing, UAT and bug correction.
Secondly, even if releases are somewhat longish, it does not mean we can't tile them! This way, from dev perspective, every week is a development week, plus dealing with bug from the previous week, plus deploying something developed two weeks ago, plus helping with analysis of a feature for the next week. This is how we already work today, all I'm saying is let's legitimize/institutionalize it and put some structure/guidance/limits around, specifically:
By making conscious effort to limit the size of each "tile", we're ensuring that fewer number of the "tiles" will end-up getting overlapped with subsequent "tiles", thereby reducing the multitasking overhead and helping improve the quality.
Tags: