Timeboxing Risks

Before I got delayed we were talking about delivering software projects on time. Using the Timeboxing approach, the delivery schedule is the one absolute in the implementation plan. What features will be included in the delivery can slip, but never the date. New requests from the user are added to the queue, but the date is not modified to accomodate them. Unexpected technical problems may delay a feature, but never an install. With this approach, progress may be slower than anticipated, but it never halts, as it can with traditional scheduling, where an installation might be put on hold until all the planned features are completed. We've outlined the benefits to this approach, but there are also some risks. The most critical risk is safety. If Timeboxing is taken to mean that we just work away at the application until the scheduled delivery date, and then install whatever we have, users can get some nasty shocks. A major new feature might be only partially implemented. Spurious messages meant only for the programmers might appear. Untested calculation might charge people incorrect fees. The solution is release planning. Timeboxing is not a come as you are party. Sometime before the due date, the team needs to decide what requests can actually be included. Testing on those items must be completed. Features that are not ready for prime time need to be hidden. Changes that should not be delivered need to be rolled back out. This is where a good version control system comes in. Even the sacred install date can be slid by a day or so - not more -- to assure that the work already done is ready to debut. What this really means is that internally the timebox needs to end a day or two early, so the app can be cleaned up for its public appearance.

The Humane Society's LOLseals

But before we get back to delivering IT projects on time, let's look at some funny pictures. Certainly none of us have been spared the LOLcats phenomenon - where folks photograph cats and give them funny captions. Here's one my god-daughter Leah posted on Facebook, for example: Taking off on the popularity of this craze, my friend Carie Lewis, the dynamic internet marketing manager for the Humane Society of the US - one of the most savvy non-profits around when it comes to interactive and social media - has launched an LOLseals contest on the HSUS website. Take a peak. The idea is to create your own caption for one of the seal pictures. A panel of celebrity judges will announce a winner, who will take home a bunch of great HSUS seal gear. It's a great idea to encourage engagement and awareness of the ongoing plight of Canadian seals. What is exciting about this contest is the way it changes the images used in educating folks about the seals. The Canadian Seal Hunt is still the worlds largest slaughter of marine mammals. And it happens every year. We are all used to seeing images of baby seals being clubbed. This campaign reminds us of how appealing these animals are, rather than forcing us to look at violent images we've learned to shield ourselves against over the years. It gives the community a new way to engage with the issue, a new way to feel about these animals. It can be hard to find a new way of presenting the same old story - HSUS has found a way here.

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.