So let’s imagine you’re the owner of a digital platform. Let’s say, for example, a large-scale content management system that hosts multiple websites for a medium or large enterprise. You may have been responsible for securing the budget to implement the platform in the first place and now you have the overall responsibility of making sure that it operates smoothly and delivers the value the business expects.
Aside from your vital role as number one scapegoat when things go wrong, you’re also responsible for managing the sometimes conflicting demands of a range of different stakeholders across the business for changes and improvements to the system. There’s most likely at least one development team that works on making those changes and you call the shots when it comes to prioritising what they’re doing. If they’re an Agile team of some flavour, they probably think of you as “product owner”.
With this role in mind, I’d like to take a fresh look at the topic of Continuous Delivery. Here’s the dilemma I’d like to explore. One day the development team come to you with a proposal that they should spend a frighteningly large proportion of their time over the next few months working on implementing the capability to do ‘Continuous Delivery’. Not a decision to be taken lightly! But how should you go about making it and what are the questions you might be asking yourself?
Without wishing to second guess your thought process, it might be a good idea to explore some of these questions in the context of your business.
Is the potential value to the business real?
There’s an excellent blog from Atlassian that outlines four key benefits:
- Faster reaction times
- Reduced risk
- Exposed Inefficiencies and costs
- Flexible release options
While this post is well worth reading, the point I’d like to make is that all but the first of these are primarily about reducing your current pain. You’ll know if these are important to you, and how much each hurts right now. However, it’s the first point, faster reaction times, where there is really potential for the business to derive huge benefit. By becoming more agile, your business can accelerate the virtuous cycle of experimentation, measurement and optimisation. It can stay ahead of competitors by responding more rapidly to changes in the market, and it can drive changes by being better able to innovate swiftly and safely.
However, this is only a potential benefit, for the simple reason that Continuous Delivery is mainly about, err…...delivery. To be genuinely agile as a business you’ll need to be delivering the right things, at the right time. Your business stakeholders will need to be able to respond to signals from your customer and innovate on a shorter timescale and you, as product owner, will need to manage the demands for changes effectively. It’s entirely possible that your business model doesn’t put you in a market where responding this rapidly is essential. Or it may be the case that as a business, you’re not ready for this.
How can I sell Continuous Delivery to the business?
For reasons that I hope are already obvious, you need to get business stakeholders on board. You need them to want this change, not simply to accept it. You need them to understand that there is massive potential here, but that what it gives them is opportunities to be more agile - and to take advantage of those opportunities they will need to change the ways in which they work.
We can already act quickly when the business demands it, do we really need to change?
There are still too many organisations that already have a kind of ability to put code into production very rapidly. They achieve this less by automation and more by granting so much power to business stakeholders that development teams are not empowered to say no. Even when they know that doing what they are told will cause future pain to both themselves and the business. Even a horribly manual deployment process can deliver remarkably rapid results when “the CEO wants the button to be orange and it’s got to happen right now”.
Just remember that once you have taken away a developer’s power to say no, you have licensed them to take any shortcut, no matter how risky, to get the job done. Don’t be this kind of organisation. Read up about technical debt and how it needs to be managed. Understand that Continuous Delivery is as much about safety as it is about speed.
What are the barriers to putting Continuous Delivery into practice?
Organisations generally like to do the best they can to avoid shooting themselves in the foot. As a result you probably have a number of existing processes and teams who act as gatekeepers and concern themselves with things like enterprise architecture, quality, security, legal compliance and so on. If your organisation is particularly pathological, these may be people who are empowered to say “no” but have no real motivation to say “yes”. Assuming this isn’t the case for you, you will still most likely face the problem that they run processes which were designed to operate on much longer release cycles. You have a key role as platform owner in drawing these groups into the Continuous Delivery process. You’ll need to engage early and make them part of the Continuous Delivery team, not part of the problem. You’ll be facilitating and motivating people to change the way in which they work. Don’t underestimate the challenge.
We’re ready to ‘go-live’ but the business isn’t - what now?
This, of course, is the scenario you were trying to avoid by engaging early with all the stakeholders involved, but sometimes it isn’t possible to change an organisation overnight. Sometimes there are legitimate concerns, such as security or legal compliance, for which you are unable to agree a solution which will allow every release to be deployed to production. Does this mean all is lost? No it doesn’t.
Many organisations are now doing what they call Continuous Delivery, even though this doesn’t result in Continuous Deployment all the way to production. If you end up doing this, you can still shorten your cycle time significantly and dramatically, improving the reliability of your releases. Just make sure that when the development team tell you that ‘every release is production ready’, you occasionally verify that this is really true.
What’s the real goal here?
This is the big question! Continuous Delivery has grown up as a set of engineering practices that dramatically improve the software release process. Do your business stakeholders care, and should they care, about "software releases"? What we are really aiming for here is greater agility for the business. This implies shortening the overall cycle time from the generation of an idea to realisation and being able to measure its effect. The thing that we are really trying to deliver here is “change”.
One way to do this is to remove some of the friction from the software release process. Another, sometimes better way, is to put the ability to make more and more changes directly in the hands of the business, without requiring a software release. That’s why we have content management systems in the first place, for example, and that’s why we, at Cognifide, spend our time thinking about how to make them better.
If you’re completely new to the topic of Continuous Delivery, or you’re looking for a more engineering-centred view, your best starting point is probably here. But if you’re already considering whether this is the right path for you as a platform owner, I hope I’ve managed to answer some of the questions that you might be asking yourself. The questions that get you round the first hurdle and on the way to delivering real business agility.