Continuous delivery – have we gone too far?

I’d thought I’d share a summary of the ideas discussed by the speakers at the Agile Tour London 2015. The following are a collection of the ideas discussed by Gojko Adzic and my notes on them.

Gojko Adzic – How to turn continuous delivery into a competitive advantage.

Gojko Adzic


  • “Continuous delivery – have we gone too far?”
  • “Software is everywhere, developers are powerful”
  • “Automation is fast, continuous delivery is impressive – but have we gone too far?”
  • “Only a third of features are actually useful, a third are harmful and a third make no difference.”
  • “How often do we remove badly implemented, incomplete features?”
  • “Deployment <> Release”

The dangers of continuous delivery

  • Interrupting the user’s workflow.
  • Making a user relearn how to do a task e.g. new UI/UX.
  • Reducing the impact of marketing campaigns, due to frequently release which by themselves may not excite the user base.

My thoughts….

  • “Yes, we can build software fast now, but are we building the right thing? Because it’s quick to implement, not enough time is going into the idea behind the feature itself.” So for me, this is where you hope the Product Owner has this under control, but as an additional layer of protection, an agile tester will always be mindful of the users and really trying to understand the value of the feature before it makes it out of the planning phase.
  • For me there no doubt continuous delivery done right is a good thing, for both product developers and consumers, however, we do have a greater responsibility to be conscious of how each feature impacts a user.
  • We all know how annoying it is when for example your bank, favourite shop etc redesigns a feature that you have been using for years, and suddenly you are forced to jump through hoops and re-learn a process you use to be able to do in seconds. We need to be planning this awareness into our features.

So what can we do about it?

  • Decouple Deployment from Release
    • Clearly this represents a technique challenge, but the advantages to the user are clear.
    • As a tester it would bring great comfort knowing a feature could be enabled and disabled as required, this would allow the team to gain valuable feedback from a subset of users before pushing the feature out to a wider audience.
  • Consider the user
    • Consider for each new feature how the feature will be released to the user, can they opt into it. What help are we going to offer the user, for example if  we are changing an existing feature, how do we help the user through the transition?
  • Provide multiple versions of our software allowing the user to opt into functionality when they are ready for it.
    • We are increasingly seeing this from the big players now, either to opt into a feature or a whole version of an application.
  • Only give the user access to the features they need.
    • As software developers, it is easy to assume more is better, but sometimes holding back features so that you only give the user just enough to do what they need to do, is a much safer option. This reduces the surface area of the product exposed vs volume of users, which in turn should decrease support and training issues.

Gojko’s Continuous delivery rules

Gojko suggested the following rules as a good starting point for responsible continuous delivery….

  1. Don’t confuse the users
  2. Don’t interrupt the user
  3. Don’t disrupt or prevent marketing activities

Leave a Reply

Your email address will not be published. Required fields are marked *