This post was originally posted on https://blog.squadlytics.com/death-by-slow-releases
- Hey, can we tweak the copy on that button?
- Yeah, done.
- Great! Let me know when it's online.
- Hmm, probably in 2-3 months. We'll batch it with the next release.
- ...
- 🙃
This type of conversation happens on many occasions. It doesn't matter if you're in a big team, a small team, a startup or an established company. Time and time again you'll hear this in meetings or read that in a Slack channel. We've gone to great lengths to adopt Agile practices, embrace Scrum, do daily standups and work in shorter dev cycles. But deploying to production is still more art than science, and small changes can take a long time to get to customers.
Typically an issue moves quickly from dev to staging, and then it waits there a bit, and a little more, gets joined by other tickets squeezing together until BANG! LET'S DEPLOY TO PRODUCTION! An avalanche of changes flows down on customers while the team anxiously monitors the logs, to make sure that everyone is okay.
And then, the day has passed. And no one is complaining. At least, not more than the usual. Great. We breathe again and we can start working on the next release.
This is the death by slow releases. We often focus on the increased risk of breaking production, but there's so much more than that to take into consideration.
The rise of the cosmetic meetings
One of the subtle but costly thing that happens when you cannot ship fast is that small modifications (text, colors, the position of a button) are now requiring a lot more debate than they deserve. It's not that the change in itself is critical, it's that once you deploy it, it might take a few weeks or a few months before it can be updated. So you need to spend more time crafting it upfront to make sure that it's as close as possible to perfection. If it only takes you a couple of days to release a change you wouldn't think twice about it, just experiment with one approach and then improve it in the next sprint. But the slowness of the release cycle inflates the cost of every commit.
Finding bugs in the haystack
Big releases are a paradox. On the one hand, it feels good to deliver so many new features at once. But on the other hand, it will be much harder to identify the cause of bugs when they occur. Your team will have to figure out which one of the many changesets has caused a problem; a task made more difficult if they have to switch context to think back at some code they wrote weeks or months ago. And even if everything goes well, your customers might still get overwhelmed by the number of new concepts delivered at once in your application.
Losing touch with the market
Ultimately what happens when your release cycle is slow is that you lose touch with what people want. The whole purpose of Agile is to have a fast feedback loop with your customers so that you can correct the course early. That is all the more important nowadays as the needs and behaviors of people are evolving rapidly due to the speed of innovation. But when it takes you weeks to ship you start to pay a costly knowledge fee to compete in your market. Your peers delivering faster are making informed decisions while you have to guess how to make your product better.
The pace of your releases is the pulse of your team
There is no denying that every software team is different, even within the same organization. Of course, there's the technical aspect, but culture is also a deciding factor in how you deliver improvements to your customers.
There's still a way to compare these teams even if the way they operate differs. You can look at the pace of the development cycle to understand how they are doing. A slow release heartbeat will be painful for the business regardless of the causes. And one that is too fast can also be harmful if not controlled well.
That is why we're building Squadlytics. To help teams keep a pulse on their dev cycle and understand the health of their projects. Making your customers happy shouldn't be that stressful.
(Photo by Noah Silliman on Unsplash)
You can try Squadlytics for free today.
Top comments (1)
Thanks for the feedback! I think it's worth making a distinction between releasing a feature to customers and the act of deploying it to production. You can use a feature flag to hide something from customers until it's ready and in this case, I agree that it can take a few weeks or a few months before you make it available to all users - there are a lot of valid reasons to control the rollout of new capabilities even when they are technically ready.
But I'm a strong advocate of deploying code early and often. When changes accumulate in dev or staging then the cost of deploying to production increases exponentially. My main argument is that if the act of deploying, and the subsequent act of releasing require a significant coordination between teams and individuals then it is ultimately hurting the business, on top of being a source of stress for individuals. Of course, this supposes that you have a good suite of tests to catch regressions.
I don't think that we're in much of a disagreement but I just wanted to clarify my perspective: deploying should be done often, and releasing (making a feature available) can be on demand.