Bus Stop Releases

I often hear of development groups doing weekly or nightly builds, software releases based on feature sets, or releases in the form of updates (such as Sun with Solaris 10 and Java SE 6, and Apple with OS enhancements). What used to be called patches in the past, and often reserved for bug fixes, are now generally accepted as vehicles to deliver enhancements to end-user software. Most system OS vendors do this, including Microsoft's Windows (all versions), Apple's OS X, iPhone, and even the iPod.

What I don't hear a lot about is the concept of a bus stop release when new software versions are developed. I've been part of development groups where we had release cycles that went out 12 months in some cases. In contrast, other projects I've been involved with had release cycles measured in weeks. In all of these cases, there were usually lists off features that were mandated for inclusion in each release, and if a feature(s) took longer to complete than anticipated, the entire release was delayed.

This can make sense in some cases, but in many cases, it wastes internal resources, and potentially keeps anxious customers waiting for the other, already complete, features. Instead, I propose the bus stop release paradigm. Here, releases are scheduled by date according to a bigger-picture view of what each release is about. When each date approaches, there will invariably be a feature or two that aren't ready. When that happens, it's just too bad; the release is deployed anyway.

We called these "bus stop releases" because it works like a bus on a schedule. When the bus comes, the features that are ready and at the bus stop get on the bus for delivery to customers (or onto web servers). The late ones make the next bus (release). When we first deployed this paradigm, we were concerned that late features would cause backlogs and affect each of the later releases. However, we realized that in reality, the previous method of delaying an entire release because of one or two late features impacted future releases even more. One or two deferred features (which were mostly complete when they missed the bus) had much less impact on the future schedule.

In the end, we found that bus stop releases kept the entire development organization (which includes more than just developers, such as the managers, testers, the build group, tech writers, and customer support) utilized more efficiently, it kept our customers happier as they could expect (and plan for) software updates more regularly and predictable, and it helped us realistically schedule future releases as we could measure more precisely why feature delays occurred in the first place.

What release cycle does your organization use? How do you handle delays and missed schedules? Write back in the comments section and share your experiences.

Happy coding!

-EJB