Gojko Adzic presented a keynote on "how to turn continuous delivery into competitive business advantage" at the Agile Tour London 2015. InfoQ interviewed Adzic about getting benefits from continuous delivery, Gojko’s three rules of continuous delivery, possible problems and risks, and using multi versioning with continuous delivery.
InfoQ: You talked about how companies can get business benefits from continuous delivery. Can you give some examples?
Adzic: I think companies are getting the benefits from continuous delivery, such as reduced technical risk of releases and faster time to market, but they could be using continuous delivery for a lot more -- effectively the same solutions that unlock key aspects of continuous delivery from a technical perspective also unlock some very interesting business advantages. For example, by sorting out a continuous delivery pipeline to their vehicles, Tesla (car manufacturer) was able to deal with product faults and recalls a lot cheaper than their competition (see Tesla’s over-the-air fix: Best example yet of the internet of things?).
Plus, people rarely consider the impact of continuous delivery on non-technical parts of the product experience -- such as marketing and user expectations. For example, while working on MindMup, we used continuous delivery to take away the drama from releases, and make things run smoothly and predictably. But by taking away the drama, we also took away the excitement. It’s almost impossible to get media to cover a continuous stream of small improvements -- no single update is newsworthy enough so that it deserves media coverage.
Likewise, without software versions and major updates, customers tend to feel more entitlement. With one major version per year, it was usual for users to pay for upgrades. When that gets replaced by a continuous stream of small improvements, users expect to keep getting new things for free, forever. Many mobile app developers struggle with this problem, where it’s almost impossible to get more money from existing customers for a significant upgrade, but just developing and releasing things for free doesn’t make a lot of commercial sense.
InfoQ: You came up with Gojko’s three rules of continuous delivery. Which are they?
Adzic: More as a play on words on Asimov’s famous three rules of robotics, than a serious set of rules, I tried to capture the three key things I see teams getting wrong with continuous delivery pipelines outside the technical aspects. Tech aspects are well covered and solved by existing practices and literature, but it was interesting to play with taking that one step wider and looking at how a stream of small changes often messes things up outside technology.
Continuous delivery may not ...
- confuse users
- interrupt users’ work or sessions
- disrupt or prevent marketing initiatives
InfoQ: There are some possible problems and risks with continuous delivery that you mentioned in your talk. One potential one is that speeding things up can hurt your customers. Can you give some examples of that?
Adzic: When there is a continuous stream of updates coming out, many teams don’t consider what happens to users’ sessions or work throughout the process of updating. I’ve seen teams require that their customers log off and log back on during a busy working day just because a new release of software is coming out, and people being utterly confused by incremental UI/UX updates. With big changes, it’s easy to keep UX consistent across the whole product. With a stream of small changes, parts often get updated and released over a longer period of time, so users often have to deal with inconsistencies. An example of that is the "new business dashboard" that Paypal implemented last year. My company has balances in two currencies in Paypal accounts, and when I logged on one morning, the total balance got me to think that several thousand pounds were missing from the account. I spent a hour trying to figure out whether one of the other people with the access to the account withdrew the money, or if we got defrauded somehow, but I couldn’t find anything obviously wrong. In fact, the money was there -- someone redesigned the dashboard and displayed only a single currency, I assume postponing the design for multi-currency customers. That isn’t the best customer experience I’d want, but I can understand why they did it that way. At the same time, it would have been better not to force-feed this new business dashboard to customers until it’s ready.
InfoQ: Another one that you talked about is that by delivering small increments of functionality there won’t be any big releases that you can market to your customers. Any solutions how to deal with that?
Adzic: My current thinking is to decouple deployments and releases. Deployments and releases are considered almost the same thing in our industry, but one is a technical event of shipping code to production, and the other is a marketing event of making things available to customers. By decoupling those two things, we can get the benefits of taking the drama out of the deployments, while still keeping things under the covers so the features can be released into the wild for the biggest marketing excitement.
This is a difficult technical problem to solve, especially because some version of the deployed software needs to be accessible at least to someone, so it can be validated and verified, but it also needs to be hidden from the majority of outside users to cause a marketing bang.
InfoQ: In your talk you stated that "Continuous Delivery without multi versioning is irresponsible". Can you explain this?
Adzic: Being able to run multiple versions of different components that talk to various versions of other components is a pretty good solution or the problem I outlined above -- having some version of the deployed software visible to a subset of users, where other users see a different version. I’m not talking about web re-routing or feature toggling here -- but about a systematic solution where multiple versions can run in parallel, without interruption. When that’s solved, there is no need to interrupt sessions or work for a deployment any more -- people can just keep using the current version until they finish the session. It’s also possible to release things gradually -- in the Paypal dashboard example, they could have just released the dashboard to customers having a single currency account, and solve the whole UX consistency/iterative delivery problem. This also allows deployment to be decoupled from releasing. Which is why multi-versioning is so powerful as an architectural concept.
At the same time, multi-versioning opens up some amazing business capabilities, such as gentle/gradual release of high risk or experimental features, running product experiments on 1% of the live user base to prove costly assumptions, offering early access to premium customers, hot-fixing and preventing problems much cheaper than before, running marketing initiatives around marketing events rather than technical deployment capabilities.
InfoQ: Is there any advice that you want to give to organizations that want to effectively apply continuous delivery
Adzic: Think wider than just technology. Continuous delivery opens up some amazing business opportunities if done right, it’s not just a technical solution.
