What is the Business Value of Continuous Delivery?

Michael Bolton sparked a fascinating discussion on Twitter by asking what exactly is the business value of Continuous Delivery? I’ve attempted to capture the conversation on Storify but I also want to explore the topic a little further.

Michael quite rightly pointed out that beyond CD being technically possible and cool, it is difficult to see the business value of the approach. I agree with him that there are practically no systems that could ever need to release new features every few minutes. In fact I can’t think of a single system which would require such frequent updates.

Despite this I believe that Continuous Delivery can provide value to the business.

Let’s step back for a moment and consider what ‘Business value’ actually means. It obviously means ‘providing something of value to the business’. Usually this ‘something’ will be a new feature or maybe a bug fix. Being able to release frequently could certainly get either one of those out to the business, but CD is only one possible solution to this problem. Even more important that releasing frequently is releasing reliably.

Almost every business wants to know exactly when a feature will be useable by real users. Releases require code to have been written and tested. Deploy scripts need to be reliable. Code needs to be packaged for release. Release documents, notes, maybe even marketing materials need to be produced. It seems logical to think that with so many parts to a release, and most likely the need for multiple people or even teams to be involved, you should release as infrequently as possible to reduce impact. In reality the more infrequently you perform an action the more likely you are to make a mistake.

The more frequently you practice a series if actions the more natural they feel.

Painful systems requiring workarounds or insider knowledge are often accepted if the user only has to feel the pain once in a blue moon. Bringing the pain forwards is really the only way to motivate people to fix these issues.

Simon Stewart responded to Michael Bolton’s initial Tweet questioning the business value of CD with the benefit of cleaner code. To be successful at CD you will need to learn how to be disciplined about writing and maintaining code. Developers need to be adding automated checks, and builds will need to be manged. My experience of adopting CD showed that having a goal that the developers were excited to achieve could be be a great motivator to get people fixing test environments, taking responsibility for quality, and maintaining automated checks. Obviously there are others ways that you could achieve these benefits but it would be foolish to dismiss the impact that CD can have on a development team.

Maybe the value of CD only starts to appear when you have multiple development teams contributing to a single code base. With a single developer and a single codebase the thought of releasing multiple times a day points to poorly written and tested code being endlessly thrust upon the user. If you consider a CD approach for multiple small development teams working on a shared codebase then you can see that if you do 3 releases in a day you are not necessarily saying that each developer released in that day. In fact at Songkick our release problems increased as the development team grew. Each developer was spending around 1-3 days on building and testing new features but this alongside regular bug fixing and technical improvements meant we were exceeding our release capabilities.

We could see that creating a process that allowed developers to commit code freely and receive fast feedback would be a huge improvement. Once we had made the necessarily cultural and technical changes to our process, attitude, and environments, we realised that with just a few additional changes we could ship our code directly to production without increasing the risk beyond our comfort zone. Taking this final step was hugely motivating for the development team; we wanted to create an environment where everyone has access to the information they need, can make decisions based on their expertise, and has access to support when they want it. At Songkick we did this by giving all developers the freedom to ship code whenever they were ready.

Unfortunately it seems rare for a team to sit down and define their release process, instead they rely on some process which evolves over time to handle new tools or respond to problems. Business value can only be achieved if you have code that actually makes it to the hands of your users. Being able to release the code to production in minutes doesn’t remove the need to define, design, build, and test changes but it can help you to develop a reliable release process.

I consider CD to be a technical solution to the problem of release delays. As with all releases there is likely to be some impact to the user, consider what this means and then plan accordingly.

Look at the risks of every release and identify actions to monitor or mitigate them. CD gives you a hugely flexible release process, you have the means to release quickly and frequently, but you also have the choice over whether you use it.

Advertisements

5 comments

  1. Hi Amy

    I like the above, although I’m a bit puzzled by the debate – for me, the business value of CD isn’t hard to find.

    Soon after the publication of the CD book Jez wrote about the value propositionhttp://continuousdelivery.com/2010/10/continuous-delivery-the-value-proposition/, and a while after that I wrote a similar definition athttp://www.alwaysagileconsulting.com/the-value-proposition-for-continuous-delivery/. Furthermore, Don Reinersten’s “Principles of Product Development Flow” provides a thorough explanation of Lean Product Development and it is Cost Of Delay that makes Continuous Delivery desirable.

    Continuous Delivery enables reduced lead times, which means we can shrink customer feedback loops after releasing new features. By responding to market demand faster we can drive up profitability and reduce waste.

    In business domains where opportunity costs are high (such as social media), the ability to release new features faster is essential. I imagine in your own company opportunity costs are high, and that you’ve seen tell tangible business benefits from adopting Continuous Delivery.

    Even in business domains where opportunity costs are low (such as the telecoms indusrry), there are a range of beneficial side effects from Continuous Delivery. For example, releasing smaller change sets more frequently reduces the probability of failure and the cost of failure.

    Cheers

    Steve

  2. Hi Amy,

    Steve has made some validate points and good references. In particular the “cost of delay” Steve mentions is important to any CEO/CFO of a company dependant on revenue.

    The business is making a capital investment in every single feature to gain some form of value (Revenue generation, Cost saving etc…). It doesn’t see any return on this investment until the feature is released. Businesses are always looking at where they should be investing and getting the maximum return. In the time period that a completed feature waits to be released what else could the business have invested in and gained from.

    Cheers,

    Alan

  3. Hi Amy

    I am little confused regarding this post, even though I feel these kind of conversations need to happen. My confusion is over what is meant by ‘continuous delivery’ opposed to what is meant by ‘continuous deployment’. These are often mixed up and interchanged which causes many misunderstandings of what continuous delivery really is. For example you state the following:

    ” I agree with him that there are practically no systems that could ever need to release new features every few minutes. In fact I can’t think of a single system which would require such frequent updates.”

    This IMO appears to be a continuous deployment model not continuous delivery. Martin Fowler in his article (http://martinfowler.com/bliki/ContinuousDelivery.html) makes this point.

    “Continuous Delivery is sometimes confused with Continuous Deployment. Continuous Deployment means that every change goes through the pipeline and automatically gets put into production, resulting in many production deployments every day. Continuous Delivery just means that you are able to do frequent deployments but may choose not to do it, usually due to businesses preferring a slower rate of deployment”

    Puppet Labs has a good diagram and article on the difference between continuous delivery and deployment here: http://puppetlabs.com/blog/continuous-delivery-vs-continuous-deployment-whats-diff

    The following link is a diagram that I use to explain to people what continuous delivery means: http://continuousdelivery.com/wp-content/uploads/2014/02/01_CD_the_idea_low-res.jpg

    To mean the value to the business of continuous delivery is that we have confidence that any changes in the code have not impacted what we currently know about the software and how it behaves. This frees up time for testers to explore and discover information that could have a significant impact on the value to the business. It is a staged/gated approached which has exploratory testing front and center.

  4. Thanks for all the excellent points and links to references. I agree that continuous delivery is very different from continuous deployment, I’ll make sure I’m more accurate in the future. What a shame that they share the same abbreviation!

    In either approach the business value clearly comes from the shorter feedback loop. As Alan rightly points out your can’t see any return on investment until it is in the hands of real users. Even then you need to be thinking about maintenance.

    Success with either continuous delivery or continuous deployment relies on having robust testing processes in place. Frequent low-quality releases will not benefit anyone in the long run. John makes a good point that exploratory testing should be central to a continuous delivery approach. Hopefully this is true.

    Thanks to Steve for clarifying that continuous delivery and continuous deployment, like any release approach, must suit your business goals. To me this is the real benefit of having conversations such as these. Once a practice such as CD, or Agile gains popularity it starts to be applied to situations or projects in which it is really not suitable. The side effect benefits that you receive from adopting these approaches are very real but people mustn’t make the mistake of thinking that this is the only way to gain these benefits.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s