Frontload Design or Keep the Cost of Change Down (Waterfall vs Agile)

Matt Bauer made an interesting comment in his presentation at MinneBar today.

Front-loaded design [The Waterfall Model] only makes sense if the cost-of-change later is high.

I’ve liked Agile for some time now (despite having no significant opportunities to use it) and Matt’s comment finally crystallized the whole Agile vs. Waterfall issue for me: It isn’t that corporations think Agile is a bad idea. They don’t think it is possible. And they are absolutely right! Most legacy applications have a huge Regression Deficit. Every change comes with huge risks, and huge risks require huge testing efforts. That all then translates into a very high cost-of-change. You simply can not iterate as fast as Agile suggests if the risk and effort to change are big.

You can however be agile when you are using modern design and development processes. If you get tools like CI, VCS and processes like TDD up and running, you can think up an idea at 8am, design, code, test and publish it by 10:30am and roll the whole thing back by noon because something wasn’t Just Right. That’s Agile. In my own environment the fastest we can deploy any change into production is 4 hours and sometimes it takes us as much as 3 weeks to get everything prepared. Rolling back is another story all together.

Anyway, the Corporation would probably like Agile if it was given the chance. The Legacy Software however, will never be friends with Agile.

Tags: , ,

Comments are closed.