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 fromAtlassianthat outlines four key benefits:
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.
