Dear Developers, Small Batch Releases Are Your Friend

One of Pivotal’s key, operating philosophies is to approach software development as a series of small batches. This is in contrast to the sadly typical “water-scrum-fall” that we see in the wild. While development teams may finally be getting around to weekly or bi-weekly iterations, the planning and deployment process still makes “big batch” deploys on 6 or 12 month intervals. If you’re a fan of lean, you’ll spot bottlenecks in this approach. The dastardly local optimizers, namely, the developers keep churning out builds, and the code just “sits” there like unshipped inventory.

You’ll Be More Successful If You Do Less

First, IT organizations who focus on shipping every week or two are finding more overall success than those who target longer-term schedules. This, of course, implies that you ship less code in each release. But, by the virtue of having smaller windows, you are given all sorts of new flexibility and opportunities to learn and change your product direction. You are already more agile. For as chaotic and unpredictable as software product management and development is, being more agile is key. In a rapidly changing environment, adaptability trumps rigidity.

This anecdote from a recent Forrester report illustrates the kind of results we often see from companies that take a small baches approach: “We did an analysis of hundreds of projects over a multi-year period. The ones that delivered in less than a quarter succeeded about 80% of the time, while the ones that lasted more than a year failed at about the same rate.”

Smoothing Out Risk

The second key benefit of small batches has to do with risk. This tends to have a lot of appeal with CEOs and CFOs. Small batches smooth out the risk of software development projects. No matter how you slice it, success with software projects is far from guaranteed. So, mindful management of the various risks is good, common sense. To that end, I see five types of risk that small batches helps manage:

Bug swarms. With less software released each time and the automated testing that comes with a CI/CD approach, you can find and fix bugs faster.

Useless software. Even if the software is bugless and done perfectly to spec, is it what the user actual wants and finds useful? Because you release all the way to production so frequently, you learn faster. You don’t have to wait 6 months to discover a feature isn’t useful and 6 more months to fix it.

Stymied innovation. Long release cycles mean you can’t try new ideas as frequently. It also means that an idea might have been novel and differentiating 6 to 12 months ago, but it may now be pedestrian and undifferentiated. If you can release weekly or daily, you can continuously explore and innovate, even if it’s in smaller chunks.

Budget overruns. Large up-front budgeting often comes with long-term projects. As the months turn into years, you’re suddenly looking at millions of dollars spent without even shipping. All too often, these projects aren’t terribly useful for users either. With smaller batches, finance is given more opportunities to check on the ongoing ROI of their “investment” in various projects.

Schedule elongation. If you’re not operating on a regular, iron cadence of shipping every week, it’s easy to slip and start adding in more time either from neglect, laziness, or the never ending desire to just add in a few more features. Shipping in small batches means, in a sort of Zen koan way, that you’re never “late” on schedule. Of course, you might expose that there were unrealistic expectations about how long it would take to code and ship various features, but that should be a good.