Timeboxing is bad? NO, it's GOOD!

Last week I read an article in the Computable (a Dutch IT week magazine, in Dutch only, sorry). The subject was about system design and which pitfalls should be prevented. Besides being a story about more or less well-known practices it ended with an statement that we shouldn't time box. It even says that the "time box promise" requires a iron discipline to first create the full design upfront.

The provided advise is exactly where the trouble started in the first place, that's why too much projects failed and still fail. That's why we love and apply Agile!

Agile iterative time boxes help us to focus and to deliver the required value/functionality which can be delivered in the time boxes and with the requested quality! I we fail, we really want to fail fast! Failing fast enables us to learn quickly from our mistakes and errors. Sticking to old "unproven" practices as the article suggests is not what I did and will do...

The funny thing was that two pages further, an article dedicated to agile practices was printed. It was an interview with/some citations of Alistair Cockburn. Communication, having a feedback-cycle and delivering the value in steps were the mentioned key values.

A nice anecdote in the article was that some project owner was very happy because he got exactly what he needed, not what he asked for in the first place. Suppose that happens very frequently... I know it does!

What is the wasted investment of a full upfront design? We will never know exactly, but we know that things change in our world and even just by thinking about the thing we want. And then I'm not even talking about complexity...

The article: Vermijd valkuilen bij systeemontwerp (English translation by Google)