One of the primary principles of DevOps is moving from large software releases to a series of small batches.
What do we mean by “large”? Six-to-12-month (or longer) projects that follow the infamous “water-scrum-fall” model. While development teams may create builds weekly, the code isn’t deployed to production and used by actual users each iteration.
“Large” has strong appeal. It optimises the planning, development, and deployment phases of software. Planning teams want time to gather all the requirements and detail them out in exquisite documents, making The Boss feel like they’ll get exactly what they want.
Developers and QA nowadays tend to like working in an iterative manner, chunking their work into one- to two-week increments. However, operations feels that the highest chance of failure comes when you deploy, so why not minimise deployments? Each group creates the process that makes them feel like they’re doing their job well.
Despite the warm and fuzzy feeling you get from a well planned, staged out process, taking a small batch approach is showing more success. As one IT manager at a large organisation puts it: “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 per cent of the time, while the ones that lasted more than a year failed at about the same rate.”
If that’s “large”, what do I mean by “small”? Here, it’s reducing that entire cycle down from six to 12 months to a week - or even a day. And yes, you back there with your hand up: this means deploying a lot less code each time, hopefully just a handful of changes, or even just one.
Focusing on smaller batches is mostly about reducing key areas of software risk. Those risks being:
- Bug swarms: If I have a week’s worth of code vs half a year’s worth of code, and something goes wrong in production, there’s a much smaller set of code to diagnose and fix. This also speeds up your ability to deploy security patches.
- Useless software: The biggest risk in software is creating software that users don’t find valuable but that’s otherwise perfect. With small batches, because you deploy each iteration to users, you can easily figure out if they find the software useful. And even when you get it wrong you’ve only “lost” a week (though, I’d argue you’ve “won” in gaining valuable learnings about what does not work).
- Stymied innovation: Coming up with new ideas can take a very long time if you have to wait six months to try out new ideas and see how your users react. Instead, if you deploy a series of small batches, you can experiment and explore each week, hopefully getting into a virtuous cycle of steadily discovering new ways to delight users.
- Budget overruns: A small batch mentality avoids “big-bang bets” that require a massive capital outlay at first and then a white-knuckling 12-24 months of waiting before shipping the code. If you’re only focused on the next few releases, finance can adjust funding either up or down as needed. The existence of government IT projects going over budget serve as an example here (though, I assure you, private industry can be just as bad: they’re just better at hiding failure).
- Schedule elongation: Projects that don’t force shipping can often find themselves forever stuck with just “a few more weeks” left before shipping. There’s always new features to add, more hardening to do, and then it’s the holidays all the sudden, and you’ve got a good month of downtime, which is just long enough to think of still more new features to add. Without an emphasis on shipping every week you eventually slow down.
Small batches let you improve the quality and usefulness of your software by creating an ongoing feature experimentation process. Small batches mean greater control over the budgetary and planning aspects because you can spot problems early on and act accordingly, theoretically – at least – after each weekly release.
Overall, The Business feels like it has more opportunity to manage, conferring upon those in charge a sense of empowerment and control. No more nasty shocks from IT.
But, and here’s the problem: small tends to cause a loud clunking noise in the minds of The Business and of The Boss. These folks are not always comfortable moving beyond that big stack of promises. “What, Henderson? You want me to do small?! At Waddleforce &co, we’re all about BIG!”
How do we in IT circumvent this and sell the merits of “small”? I suggest discussing small batches in terms of risk management and the “optionality” that the approach creates, something that business-heads usually understand and value.
As IT proves out the small batches approach, then the code crowd might have something to teach the suits. ®