Thursday, June 14, 2007

Transitioning to Iterative Development

This was presented by Ian Spence. It was a fantastic session.
In his presentation on iterative development, he recommended iterations of 4-6 (preferably 4) week iterations. Each iteration runs the full scope of:

Requirements -> Analysis -> Design -> Implementation -> Testing

One of the key benefits is continuous measurement. Another is team members are focussed on short term goals (and we all know it is easier to focus on a short term goal than a long term one).
Other benefits are it allows you to cope with change very well, and as products are placed in front of customers, it becomes easier extract the requirements from the customer.

Iterative development can keep things with the highest priority at the top of the heap. If you find a bug in a critical part of the architecture early, then time is spent on fixing that before developing a trivial nice to have feature. So, maybe to make schedule, you ship working software with fewer features, instead of buggy code with lots of features.
I am a fan of iterative development but, I've never thought of things in that context before.

The best quote of the presentation: "The waterfall process is good if you've done it before, you are good at it, and you can do it in one go."

The biggest risk with this process can come from the people.
You need continuous stakeholder (and customer) involvement. This is good but, we have all experienced the customer who only wants to be involved at the beginning and the end of a project. This could be the most difficult.
The team needs to be disciplined and collaborative. The challenge here is that since iterations are short, everybody on the team is being judged every 4 weeks. So, there isn't any room for slacking. This can cause a bigger issue than might be predicted.
The next risk, still a people issue, is to not let the iterations stretch beyond the planned iteration period. The companion issue is, don't jump ahead to the next iteration either. This really keys in to the collaborative part of team work. If folks get ahead in their work, instead of working ahead, it is much better if they help test.

There is a lot more on this topic I want to write about. But, I'll save that for another day.


Labels: , ,

Links to this post


Post a Comment

Subscribe to Post Comments [Atom]

<< Home

Links to this post on:

Create link here by posting on Blogger