This post was originally posted on https://blog.squadlytics.com/the-economy-of-continuous-delivery

Most of the conversation about Continuous Delivery (CD) is technical. And that makes sense! There's a lot to unpack when you want to make the transition from manual, risky releases to shipping code to production multiple times a day. You need to embrace automated testing, get a good enough code coverage, think about data migration, infrastructure as code, versioning of APIs. You will debate your branching strategy, your implementation of feature flags, the use of microservices. You'll think about your monitoring tools and your rollback plans. Adopting CD needs a real strategy and planning.

But the issue with doing so is that it often makes it look like a dev-centric initiative that only benefits the engineering team. After all, the time taken to improve the deployment pipeline is time not spent on developing new features for customers. That is why it can be hard to convince stakeholders that it is something worth doing.

This is a framing problem. Continuous Delivery is not about making developers happier, although it's a significant by-product of it. Continuous Delivery is first and foremost about getting an edge on your competition and delighting your customers.

What makes you competitive?

To understand why CD is a critical advantage for any business we need to go back to first principles. You rarely win a market just because you are the first player there, especially nowadays when technology has reduced the switching costs for customers drastically. You win because you understand what people want better than anyone else. It all comes down to having more information and knowledge than your peers and being able to use that information to make great products.

This is one of the reasons why Agile and the Lean Startup methodologies have been so successful. They allow teams to rapidly test ideas on the market and get feedback from users. You know how to correct the course within weeks instead of having to wait months to know if your hypothesis were right.

So the question is, how can you reduce friction to get data from the market faster?

Iterating in practice

A common cause of tension in product development is the difference of speed at which the Marketing team and the Engineering team operate. When you get an idea for a new feature, the Marketing team is often able to shape a campaign and get a budget ready within days, whereas it might take a couple of weeks or months to get the feature out. This is an accepted frustration coming from a desire to get the feature to the market as fast as possible.

But now, your feature is out. And after a few days, you're getting feedback from customers and figure out a small tweak that can increase your conversion rate by several points. But your team can only release it in another two weeks -- not because the development itself is complicated, but because your deployments are costly and risky.

So, you shipped a new capability, got valuable information from the market, but you're unable to act on it. This is costing you money now as your marketing budget is attracting people to a feature that does not convert as well as you know it could. With each day that goes by you know you are losing customers.

Fast release cycles are about being competitive

We need to stop seeing the challenges of deployments as being a technical issue, a nice-to-have for developers. It is a business hurdle that needs to be addressed to stay competitive. Each release is an opportunity to have a discussion with your customers, to test an idea and improve on it. The teams that can deliver multiple times a week are the teams that enable their organization to respond quickly to the needs of their market.

And then, you'll see the fantastic side-effect of having a smooth release cycle: your team will be noticeably happier as they will be less stress, and able to see more often how their work is helping people.

Squadlytics helps teams measure and optimize their release cycle. Try Squadlytics for free today.

(Photo by Pope Moysuh on Unsplash)