Two events this week convinced me of the power of timeboxing. In both cases an activity was in danger of drifting, such that the effort expended would far outweigh the value (if any) returned. And in both cases we applied timeboxes that seemed crazy at first glance, but which created the focus to get the jobs done.

In the first case, a real-live paying customer reported a bug. The current release plan says we’ll continue with 2-week iterations until mid-June, at which time the new release will be made available to all comers. But it was important to get an interim release to this particular customer much sooner than that. In fact, as soon as possible. Yesterday.

Now this team are currently making great strides towards agility, but their product and their code still show strong traces of the past. So the first estimate to produce the bug-fix release was that it would take a couple of hours to fix, and then tradition requires the entire team to test any release for 5 days! This estimate seriously crippled the release plan, pushing important stories out past the projected June release date. This, in turn, created an “atmosphere”, in which everyone looked for places to dump the blame. A project that was riding high was suddenly brought crashing to the ground by one defect that had been inserted into the code long ago.

So I decided to challenge the assumption that 5 x 7 staff-days were required for testing the release. As expected, the estimate was high because the team had little confidence in their product. So I turned the situation around: “How would you gain the confidence you need, if you were only allowed to expend 1 staff-day on the problem?” Very quickly a convincing test plan was put together, and at the end of the next day the work had been done. Everyone was now confident in the quality of the product, and the release went out to the customer. (She seems happy with it too.) The June release is also still on track, because the one day required to issue the interim release was soaked out of our slack.

[The other incident was very different, and I’ll blog about it when my client allows. Suffice to say, though, that we followed the same path of challenging a basic assumption about the scope of the work.]