Time Boxing – Yes You Can
- July 15, 2009
- 0 Comments
Jim Sinur wonders allowed whether you can Time Box BPM efforts effectively… and concludes that in some cases you can, in some cases you can’t. In favor of the “yes” argument:
Benefits flow early and the project sponsors look like heroes. Success breeds success and a BPM program can take off early. Anybody want to say “no” to instant savings?
Indeed, who would want to do that!? And then Jim puts up another strawman for the “No” argument:
What sometimes happens when this approach is taken is that sooner or later a project that implemented benefits may have to give them back to help the overall process. […]
Not only might it knock out strategic benefits, the conversion costs could wipe out a period of the savings. Why make false starts when you can do it right once?
Well, quite frankly, you can’t do it right once. That is the false choice in the comparison. IF you could do it right once, this would be a valid decision tree – but since you CAN’T do it right once (with any reasonable probability), this point doesn’t hold much water for me.
I don’t believe this is a six-on-one-hand, half-a-dozen-on-the-other issue. Time boxing works – and specifically it works more often than a big-bang deployment. The point is that since we can’t get a software release right in just one release, the goal is to approach the right answer increasingly accurately across a set of smaller, less expensive releases rather than one big release.
Yes, there is the caveat that you must keep corporate objectives in mind, and that in a future time box, some of the gains in one area may slip in order to achieve a bigger overall gain. But in practice I have experienced that kind of “back-sliding” as a pretty unusual circumstance.
When giving back benefits did happen, it was a classic case of “squeezing the balloon” – where one group with relatively inexpensive staff optimized their process around reducing hard costs (measurable as headcount). They neglected that their optimization created additional work for other parts of the organization, where the staff was actually more expensive – and therefore, they increased overall cost to the organization instead of reducing it. But the increase of cost can be hidden as soft cost – a slightly decreased productivity by a large number of people is difficult to notice via anecdotal or sampling data.
Time boxing is key for creating a pattern of delivering, of being accountable, of having a delivery process that has integrity. The alternative has a much higher probability of failure. In this blog, we typically refer to “time boxing” as “Iterative Development” and time boxes as “Iterations”. But both terms are valid taxonomy. They’re also similar to concepts in the Customer Development process (generally popularized by folks like Steve Blank and Eric Ries among others).