The value of timeboxing

One of the best practices that I have been rolling out is splitting iterations of customer-valued work in boxes of a couple of weeks instead of using a full-blown waterfall methodology.

Under the old model, the customer received dates commitments and estimates of work. However, priorities changed quickly and the team needed to spend more time re-estimating and keeping the documentation uptodate than producing the software the customer actually valued. As a result, the development team was rarely able to deliver on useful software on time, and had to spend even more time communicating the delays. A vicious circle ensued. When software was eventually delivered, the business had moved on and the requirements were out of date (despite being signed off).

Now, the customer gets regular supplies of fresh software. The software is guaranteed fresh because requirements are only analysed in much detail at all for the next iteration. He knows that his latest priorities will be pretty quickly converted into working software every couple of weeks. He also sees something like a cumulative flow diagram showing a steady stream of working features being delivered to him. His need for time and date planning, for estimations and documentation goes down.

Technorati Tags: , ,


Leave a Reply

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

You are commenting using your 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: