April 11, 2007

...Learn TDD with Codemanship

Even Waterfall Teams Do "Agile"

Duncan Pierce pointed out to me yesterday that, in his experience, teams that claim to be following a waterfall process actually - when the chips are down - go "Agile".

I've seen many "stabilisation phases" on waterfall projects that follow the initial customer acceptance testing. In these phases, customers raise a long list of issues that need fixing. But the deadline is looming, so teams have to ask the customer to prioritise these issues so that they can at least find time to fit in the most critical ones.

And there tends to be a lot of to-ing and fro-ing with new builds of the system to get customer feedback throughout this stabilisation process.

Duncan suggests that the teams he's worked with often say they make the fastest progress towards a usable system in this late phase of development. This is probably because of the greatly increased frequency of feedback and the prioritisation of value, both of which will tend to see you delivering more value sooner.

All this sounds very familiar, so I have to concur with Duncan's theory: when they really need to get something done, most teams end up doing some kind of - albeit half-baked - iterative, incremental, "Agile" process.

Now that I think about it, this makes perfect sense. The chances of coming up with a system that's good enough for release in a single delivery are remote. Teams that have to deliver inevitably find that they need more throws of the dice. Their chances are even more enhanced by tackling the most critical issues earlier. so teams instictively find an "Agile" path to delivery, even if they do wait until the last minute to do it.

I put it to you, Sir, that there simply is no other way to deliver useful software. So put that in your pipe and smoke it, Mr Big-Design-Up-Front Smartie-Pants!
Posted 14 years, 3 months ago on April 11, 2007