If you take a long hard look at the DevOps movement, you will find it actually divides neatly into two sub-movements. The bigger and often noisier of the two is about technology, advocating for the latest and the greatest tools and techniques, be they Cloud, CI/CD, Serverless, or Containers. The smaller sister, however, is much different, stemming from Management Theorem and focusing more on processes.
Nothing says Management Theorem as much as ‘The Goal’ by Eliyahu M. Goldratt, that pesky little book ‘The Pheonix Project’ by Gene Kim, Kevin Behr, and George Spafford, was based on, which teaches us all about the Theory of Constraints and Bottlenecks. Today, I wanted to share with you my thoughts on the biggest bottleneck our customers and prospects are struggling with: the dreaded deployment.
To be blunt, deploying new code is always the bottleneck. Be it to development, staging or production environments, you can (almost) never deploy fast enough. But you might want better proof than a comic strip (though personally, xkcd is more than enough for me 😁).
Let’s start by checking where work is piling up. Open your issue tracking system (Jira, Trello, or something else owned by Atlassian) and take a look - how many of your tickets are pending deployment?
Next, take a look at your team - engineers, product managers, support and customer success. What are they worried about? What are they waiting for? If they are anything like the ones I’m working with, they are waiting for the next deployment to fix a bug or get a piece of data for them.
The obvious answer is to increase capacity within the bottlenecks. Some of the tested and tried approaches we have used for optimizing deployments are:
Unfortunately, we’ve noticed that many of these action items are easier said than done. After all, there’s a reason deployments have become a bottleneck, and if it was that easy to fix engineering leaders throughout the world would have squashed it long ago.
If you are building a new software product, you should definitely go for it. But for most existing (and profitable!) software products out there, this journey is likely to take years, cost decades of human time, and may not even net a positive ROI.
“You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer. Good. We need better programmers.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
At its core the Theory of Constraints doesn’t focus so much on increasing capacity at the bottleneck, but rather maximizing the value you are getting out of the bottleneck. So how do you go about it? What we’ve learned from our experience is the following: