Tuesday, March 10, 2009

Iteration duration

I offten think why in my practice I used to fail to apply short 2-4 weeks iterations usually suggested by agile mentors. I found that 8 week iteration is the optimal. It it not too long to be become unflexible and delivers increments often to facilitate feedback cycle. And at the same time it allows normal requirements analysis and development without hurry.

Here are some my ideas why it happened:
1. All my projects last 6 years were off-shore and near-shore projects where development team was located on different site from "product owner" (in terms of SCRUM). It means that there are difficulties with knowledge transfer from "product owner" to development team. We used to transfer this knowledge mostly thru functional specs. Well it was quite informal specs often, not formal documents. Delivery of such spec usually followed by Q&A session between development team and spec author.

2. Due to communication practices it was resonable to capture big enouth chunk of requirements at once and transfer it to team. It would just be too time consuming for everybody to do requirements transfer every 2-4 weeks.

3. Functionality/user stories planned for single iteration usually were too big to be done in 2-4 weeks. It were possible to devide them of cause into sub-functions (and we did it as internal checkpoints inside iteration) but there was no sense to deliver those intermediate milestones to "product owner".

4. Often "product owner" is not ready to consume deliveries every 2-4 weeks. THe reason could be that "product owner" is just busy with something else. Depends of the feature also. Some features require sagnificant preparations to check, test, verify.

5. Interesting fact that increases my confusion about 2-4 weeks recomendation even more is that we used "staggered iterative development". Requirements analysis, construction and verification functions were distributed between different subteams that worked in parallel. While "product owner" works on specs for (n+1) iteration, development team worked on iteration (n) constraction. Testing team slitly overlap with development team. Testers works on verification of (n-1) at the begining of (n) constration and then continue on test cases creation for (n). May be better to think about it as a special period between iterations (about 2 weeks) while developers and testers stabilyse (n-1) and start (n) construction. There could be also external "functional testing" tean that works with (n-x) while (n) construction to help "product owner" to build vision, to get feedback from "end users", etc.

My current opinion that short (2-4 weeks) iterations sutable mostly for small projects and on maintenance projects where changes are small and team is small and colocated. It is important that "product owner" is near and ready to consume deliveries often enough.
I learned also that short iterations doesn whorl if there are no true "product owner" or he doing his job by "left hand" (working on other more important projects semultenously). In this case "product owner" just cannot give feedback so quickly.

But all abouve doesn't mean that development team should not use internal "micro-iterations" (or let's call it checkpoints). This is a very usefull technique together with timeboxing to concentrate to "good enouth for now" results.

No comments: