In today’s fast-paced market, the ability to respond swiftly to changes is not just an advantage; it’s a necessity. As organisations, we often find ourselves navigating a landscape filled with surprises—some of which can be detrimental, while others present golden opportunities. The key to capitalising on these opportunities lies in our lead time. If there’s a significant delay between the moment we decide to act and when our changes hit production, we risk losing out to competitors who are quicker on the draw.
Let me share a story from my experience with the Azure DevOps team. Back in the days when it was still known as TFS, they operated on a two-year release cycle. Yes, you heard that right—two years! They would ship a service pack halfway through, but the real challenge emerged when they began to gather feedback on their beta releases. Customers would provide valuable insights, highlighting missing features or changes in market demands. However, with only six months left in their development cycle, they were often left with no option but to defer these requests to the next version—or worse, the version after that. This meant that significant customer needs could go unmet for over two years, which is simply unacceptable in a rapidly evolving market.
Fast forward to 2018, and the Azure DevOps team had transformed their deployment frequency from a mere 20-30 deployments a year to an astonishing 880,000! This dramatic shift illustrates the power of shortening feedback loops. By continuously delivering updates and features to production, they could test ideas in real-time, gather data, and adapt accordingly.
Here are some key takeaways from this transformation that I believe can benefit any organisation looking to enhance their agility:
Embrace Continuous Delivery: Instead of adhering to rigid release schedules, aim for continuous delivery. This allows you to push features to users as soon as they’re ready, enabling you to gather feedback and iterate quickly.
Start Small: When exploring new market opportunities, focus on the smallest viable feature that can validate your idea. This approach minimises risk and allows for rapid testing and learning.
Utilise Data and Telemetry: Once your feature is live, leverage data to assess its performance. This will inform your next steps—whether to invest further in the idea, pivot, or scrap it altogether.
Stay Ahead of the Curve: By maintaining a tight release frequency, you position your organisation to not just react to market changes but to anticipate and set trends. This proactive stance can differentiate you from competitors who are merely following the market.
Maximise Value Creation: Ultimately, the goal is to maximise the value you create for your users. By being responsive and adaptable, you can ensure that your product remains relevant and valuable in a constantly changing environment.
In conclusion, the journey from a lengthy release cycle to continuous delivery is not just about adopting new tools or processes; it’s about fostering a culture of agility and responsiveness. By prioritising quick feedback loops and continuous improvement, we can not only survive but thrive in today’s competitive landscape. Let’s not just keep pace with the market—let’s lead it.
If you’re an organisation and you’re trying to respond to changes that happen in the market, you want to be able to respond to them as quickly as possible. So those changes could be surprises. Surprises are usually bad, that you have to go deal with, or it could be opportunities, right? Things you want to go take advantage of. And if you have a long lead time between deciding you want to do something and it ending up in production, then you’re not going to be able to take advantage of opportunities that arise. Lots of opportunities are going to float by, and somebody else is going to take advantage of them, or you’re not going to be first to market or any of those things.
So one of the, I’m going to use an example. So the Azure DevOps team, when it was TFS back in 2010, 2012 type of timeframe, they were doing a two-yearly ship schedule, right? So they were shipping to production every two years. That was their cadence, with a service pack halfway. What would invariably happen is they would get halfway through their development, their two years, so after a year or maybe a year and a half, they would ship a beta of the new version of the product, and people would start kicking the tyres on the beta. They would have lots of feedback, and some of that feedback could be incorporated, but maybe the feedback was a bigger missing feature or something that customers are doing in the market that isn’t in the product, or some change in the way we do things that’s a bigger change, something a little bit meatier, right? And there’s no way we can fit that into this version of the product, right?
So there’s six months left to go. We’re effectively mostly bug fixing and tweaking from our two-year development. They’re coming to the end of our two-year development, and we’ve already planned the work that’s going to go into the next version of the product. So in actual fact, unless this feature is super important, it might be just a little problem for customers. We’re not going to bump anything out of the next version of the product to fit this in. So those features aren’t going to make it into the product for more than two years because it’ll be not the next version, but the next next version of the product. And that was a huge conundrum for them because DevOps was starting to move faster. Azure was taking off, and customers wanted these faster cycles, faster deployments, and Visual Studio and TFS and those kind of tools weren’t able to keep up at all. Windows as well, but that was a little bit later, not much later, but a little bit later.
So they needed to shorten that delivery time, right? They had to have high deployment frequencies rather than low deployment frequencies. And they literally went from, in 2010, Microsoft was doing something like 20 or 30 deployments a year, right? So the deployments of their products, and by the end of 2018, I think they were at 880,000 deployments per year across the organisation. And that’s just in Azure DevOps, not for Azure DevOps, but in the product Azure DevOps that they used for that.
So when you shorten your feedback loop between getting an idea out there, getting something in the market, testing it in the market, getting that feedback loop back around, how quickly can you adapt, right? Time to learn is going around that loop twice. So in order to do that, you don’t want a yearly deployment, you don’t want a six-monthly deployment, you don’t want, you don’t even want a two-weekly deployment. You want continuous delivery to production. You want to continuously be able to get the features that you’re working on, that your teams are working on, in front of real users as quickly as possible. You want to take an idea that you have, and you want to take, like, what’s the smallest test we can do? What’s the smallest feature we can build? The smallest thing we can build in our product to validate whether this market opportunity actually exists, right? And get that into your product as quickly as possible. Then look at the data, look at the telemetry, and decide whether you’re going to invest more in that, or it needs to be changed slightly, or, yeah, it was a great idea in my head, but once we started engaging with users, it wasn’t a good idea.
And in order to be able to do that, in order to be able to move with market changes, meet market demands, and look forward into the future to preempt and try to get ahead of the market, right? You want to be the one setting the market. You don’t want to be following your competitors. You want to be the one setting the market trends. And in order to do that, you have to be on a tight release frequency. You have to be continuously delivering your product to production. You have to be getting every change you make in front of real users, and that is going to help you adapt to market opportunities, deal with market surprises, and maximise the value that you create in your product.
