Objections To Evolutionary Delivery

Some information about the tutorial and think tank on EvolutionaryDelivery that I ran at the OT99 conference can be found at http://www.cix.co.uk/~jdaniels/evo (link dead).

The think tank participants came up with objections to ED and then tried to refute them. The one we had the most trouble with was number 10, the one about large, geographically distributed teams. If anyone can come up with a better answer for that one, I'd like to hear it!

-- JohnDaniels

Interesting. I feel that the objections in #10 are mostly dust thrown in the eyes, not substantive objections by actual project sponsors. I had to read the slides to get what might be the cause of the commotion.

If you decide to walk around the block 5 times, and you are crippled and use a walker, then it is a natural consequence that you will walk slower around the block 5 times than someone who has put RollerBlades on and is blading around the block. It doesn't mean you won't decide to walk around the block 5 times.

Similarly, if you say, "we are going to deliver this software in 5 deliveries, but we can't put everyone in the room together, in fact we're going to put 50 people in different countries", then it is a natural consequence that your cycles will be longer and slower than if you put 8 people into one big room together. This doesn't mean you won't do 5 deliveries, it means that you have to account for long, thin communication lines.If you don't account for that, then you are simply mismanaging the project.

Read, if you will, the MethodologySpace article [1] to get comfortable with the idea that one size methodology cannot possibly fit all projects. If ED requires close, rapid communication, with people sitting together, then it fits a particular project profile, and not others - and that is OK. The idea of incremental delivery does not become invalid for having more people, but the mechanism employed will necessarily be different.

The consequence for the ED discussion is what is considered "in bounds" as Evolutionary Delivery, and what considered "not" ED. Could you please comment on where the dividing line is? That will help determine whether Objection #10 is really trying to say "A speedboat is not an ocean liner" (i.e. ED really only applies when communication lines can be made short), or whether ED applies when the time scale and communication lines are stretched. --AlistairCockburn

In the tutorial I stressed that there are a number of factors influencing the choice of appropriate cycle length and content, and a very important factor is team size. As others have said here, I think ED is the most realistic approach to risk management on all software projects. It's certainly harder to apply efficiently with big, distributed teams, but what's the alternative? -- JohnDaniels

Note here the universal scope of EvolutionaryDelivery implied by John. Even where ED is hardly practical, it's still the only practical approach. --RichardDrake

Regarding Objection #9. User disruption and the necessity to copy data from one evolution to the next can be reduced by using XML, which is a version-friendly data format.

CategoryApplicationDevelopment