Members Only Logo  

or Subscribe by Email by entering your address below:

Powered by FeedBlitz
Learn about Subscriptions Follow me on Twitter!

The topics discussed here grow out of the bread-and-butter issues that confront my consulting and software clients on a daily basis. We'll talk about prosaic stuff like Membership Management, Meetings and Events Management and Fundraising, broader ideas like security and software project management, and the social, cultural, and organizational issues that impact IT decision-making.

Thursday, March 20, 2008

Timeboxing your Development Efforts

How can you make sure you meet your promised deadlines when implementing software projects at your organization? And without late night pizza-driven coding sessions? One approach is Timeboxing.

Timeboxing, quite simply, is an approach to IT implementation planning where the one thing that you do not allow to shift around on you are delivery dates. Everything else may seem totally out of your control. The users have eighteen new features they absolutely need. Your best programmer quits suddenly because she was offered a bit part in a horror movie. You just can't find that bug where new members are going in without their addresses. But you will install SOMETHING on March 18th.

When I first read about timeboxing more than a decade ago, it seemed a nearly impossible technique to explain to the user community. Folks in our client organizations had a list of fixes and enhancements they wanted, and they were not interested in seeing a new version until these were done. But software methodologies have grown to emphasize a more iterative approach to development. In these so-called agile methodologies, fixing the schedule for each new delivery makes perfect sense.

In the Scrum development model, for example, a new version is typically delivered every thirty days. At the beginning of the cycle, the team agrees on what outstanding requests will be included in this release. But if the work does not proceed as smoothly as planned, some of the requests will be left out to allow the iteration to complete on time. The ones that were not completed will be included in the next round.

The advantages of this approach?
1. Users are not left waiting for new features already written as a delivery date keeps moving out to accommodate incoming requests.
2. By getting more features into users hands more quickly, the feedback cycle is tightened and the applications improve more quickly.
3. By allowing feature lists to slip, the "Death March" pressures around deadlines are alleviated, allowing programmers to perform work of a higher quality.

Of course there are risks to timeboxing as well. We'll look at what they are and how release planning can mitigate them in the next post.
More reading on timeboxing can be found here.

Labels: ,

Comments on "Timeboxing your Development Efforts"


post a comment