Time-boxing your way to a better product

To paraphrase a recent conference speech by Tom DeMarco, the insightful author of books and essays on software development, most projects are like Greek tragedies: During the first half, it appears that man is in control of events; the climax reveals that events are in fact in control of man. So it is with software development. At first we believe that the project controls the schedule, then we realize that the schedule was in control all along or, more likely, out of control.

This is how testing is routinely sacrificed. Not out of a conscious decision to give quality short shrift, but out of a series of compromises that conspire to delay the project…but not the deadline. At the end, quality is the only price left to pay.

What would happen if we became realists and just admitted, up front, that the schedule was the primary driver?

This concept, also known as “time-boxing,” is a schedule-driven approach that treats deadlines as sacred, while resources and requirements are variable. When combined with the idea of a “rolling release,” which comprises continuous incremental deliveries that are scheduled early and often, this approach can work wonders or terrors, depending on how you go about it. Over the past three years I have seen an increasing number of companies apply this approach to projects as large as an SAP implementation and to those as small as a departmental client/server application, with impressive results.

Working in boxes

A time-boxed project works like this. The final delivery date is identified first, with frequent intermediate releases preceding it. These may be one, two, or three months apart depending on the size and length of the project, but usually no more than three. Each release should introduce sufficient functionality to permit user interaction. The goal is to get started as soon as possible, so that feedback has a chance to be incorporated before the project is over. So, instead of a one-year development project, you would have four quarterly releases, each building on the last.

This approach forces requirements to be ranked by priority and order of implementation. Although the content of each release is aggressively planned in advance, it’s understood that the release will ship on the designated day with or without all requirements. The schedule rules–but we knew that, anyway.

In this scenario, testing continues constantly. Instead of an end-of-the-line, frenzied event, it’s a constant companion to development, providing verification of each build and successive feature or function. In the later releases, corrections are being introduced and tested as well.

The advantage of this approach is that it can produce a better product faster. Ambiguities and inconsistencies in the requirements are quickly flushed out when the software meets the cold light of user interaction. Rolling releases encourage constant refinement of requirements and continuous testing; this helps prevent projects from going too far astray or too late to test.

And, if the truth be admitted, even “completed” software development projects are never finished. Any product that is being used is subject to a constant flow of issues and enhancements as the users and business it serves evolve and change. Viewed in this way, the project never really ends: It may simply metamorphose into monthly releases.

Know where you’re going

The flip side of this rosy picture is that discipline becomes sacrificed to speed. Although on the surface it might seem that focusing on the schedule encourages minimal planning and design, the opposite is true. The system architecture must be thoughtfully structured to enable the delivery of usable increments of functionality, providing a solid foundation quickly that supports future expansion without limiting it. It means you have to know where you’re going before you start. If you don’t, you’ll degrade into producing rewrites instead of adding requirements.

One of the means for keeping tighter control on the software while enabling continuous change is to produce a software build at least weekly, if not daily. This requires the software to be assembled, available, and accounted for constantly, so that rapid responses to issues are possible. The longer the time stretch between builds, the greater the opportunity for confusion and mayhem.

It should go without saying–but we will say it anyway–that relentless project management and good software hygiene is essential. Constant coordination is needed between developers, testers, and users. And source and version control with complete configuration management is crucial among developers. A rapid-fire schedule is unforgiving, and frequent releases are uncompromising. It’s either happening or it’s not.

So simply declaring a time-box schedule and rolling release strategy, without the concurrent commitment to the supporting disciplines, will merely result in an interminable series of Death Sprints–each worse than the last.

Accelerate or be left behind

Let’s admit it. Market opportunities and product cycles are compressing; the days of multiyear development projects are gone, along with the untold millions wasted on runaways and endless delays. In this, the time of I/Net speeds, our approaches to software development and testing need to accelerate or be left behind. Time-boxing and rolling releases are just formalizations of what the market is forcing to happen. The key is to do it voluntarily and consciously, instead of unwillingly and unknowingly. //

Linda Hayes is CEO of SoftWork Inc. She was one of the founders of AutoTester. She can be reached at linda@softwork.com.