Beware The Iterative Approach

During one of our regular divisional management meetings recently, I was pleased to hear the announcement that all development projects will now be approached iteratively.

Strangely, even though this is the first real sign of an acceptance that we should be considering other methods for software delivery and given that I have been trying to promote alternative ways of delivering software for some time now, you’d think I’d be pleased. However, I feel nervous and am inclined to urge caution.

Why? Well, I’m just not sure that the people that are making this declaration actually understand what it means to be iterative, sure it means that we’ll approach stuff in iterations, mini phases if you like, but haven’t we seen that somewhere before? Let’s say you have 6 features to implement and your initial estimates suggest that each of those will take a month to complete, I think that what’s being suggested is that we’ll approach each of those in an iteration. What happens if the sixth feature that you do actually ends up taking 2 months? More importantly, what happens if the sixth feature is the one that is of most value to your customer?

In my opinion, approaching software development in an iterative manner means that, given the example above, you would consider a portion of each of the six features and look to complete each of those portions in the first iteration, and then revisit them (starting again if necessary)  in the second and so on and so until all of the features have been delivered. The two main benefits of this are that the customer gets to start using their software as early as possible and secondly, information starts to flow from the development team about their confidence of being able to deliver to the afore mentioned estimates.

Advertisements
Tagged , , ,

One thought on “Beware The Iterative Approach

  1. Ralph says:

    Hi Dan,

    Being an former contracting colleague of Rob’s, I stumbled upon your short description of what you consider to be iterative software development. This is so true… Unfortunaletly larger organisations do not realise this soon enough, and enormous mishaps resulting ion cancellations or strained relationships between integrators and clients are the result. I have seen this in two projects I have worked on thus far, one for BMW and one for DHL (Current project, and in limbo between continuation or cancel)

    A similar issue I have with a UseCase approach for implementations of relatyively predefined software solutions such as Siebel. UseCase driven development is fine for .Net or Java framework development, but packages such as Siebel have constraints for which UseCases do not cater.

    nevertheless, I am delighted to see that your stay in Canada was good, and have pity on you that the rat race has picked up pace again.

    Say ‘Hi’ to Read when you see him. (I was his BA way back in Q1-Q2 2005)

    Ralph

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: