.
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.
I’ve noticed that large organizations who move to a small batches approach are actually improving their software process and overall design quality. From my perspective, this trend has been increasing over the past year. Yet, I feel like we gloss over this key concept a lot in talking about the value of continuous delivery (the pipeline and process you use to do small batches with custom software). So, I wanted to use my Register column this month to highlight the value of a small batches approach. These columns are short, so there’s not much room for detail, but there are two things worth highlighting.
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.
Learning More
There’s more detail in the column which you should check out. Also, this is actually my second column at The Register: the first one went over the state of DevOps adoption in the industry.
You can also read more of our blog posts on similar topics or watch videos about Pivotal products, like the one by Andy Zitney on “Developing the Freedom to Disrupt” and changing the way development happens.
About the Author
