How to move to a Continuous Delivery Model (Proven Experience)
Apr 8, 2016
A pattern we’re noticing more and more is that technology departments are starting to get out in front of the business. All too often this creates an odd paradox: the business might be asking technology to slow down because it hasn’t adapted to a continuous delivery model. This is especially true in organizations that have fully adopted agile and DevOps and who have adopted a more continuous approach to software delivery.
A decade ago when the business was asking for a faster release cadence no one would have imagined that technology would have adapted to support a daily release cycle or a release cycle even more frequent than that. We’re seeing business stakeholders in some of the most mature DevOps organizations ask developers to take a breather and step back from such an aggressive timeline. This points to a lack of infrastructure and management around continuous delivery pipelines.
We solicited some feedback from some of our own clients to understand the pain points, and in this post, we’re going to explore what you can do to get your own organization ready for a continuous delivery model.
As a release manager, you understand that you sit at the center of the discussion between business and IT, and you're being asked to help answer the question, “What do we do with all this new agility?”
Here are some of the common pushbacks and questions our customers are asking about the continuous delivery model:
“It was easier when we had a two-week release cycle.”
We’re seeing this more and more in the industry. Business stakeholders and VPs are lamenting the fact that with continuous delivery comes continuous responsibility.
They have to commit resources to an almost continuous series of releases and yearn for the old days of monthly or quarterly releases. Business stakeholders are noticing the increased workload that a more frequent release cycle brings and how that causes problems for staff not yet ready to support continuous delivery. Other business stakeholders haven’t adapted to the approach and miss the ceremony of a “big, important” release event.
As a release manager, you can help people adapt to a continuous delivery model by sending out a release activity summary using the same cadence as the old release process. If you used to have a release every two weeks, you can use a dedicated release management solution like Plutora to generate a summary of release changes and release activity once every two weeks and send this to the business executives.
They’ll appreciate the simplicity of the communication, and you can use it as an opportunity to drive home the fact that a continuous delivery model allows you to move faster with the same level of transparency.
“I feel like we’re sacrificing quality for agility.”
If you hear this complaint your business stakeholders may have a point. One of the biggest issues across all industries is quality assurance and automation.
While we’ve perfected the art of automation within a continuous delivery model, our QA problems are still gated by resources.
Believe it or not, it's often more difficult to find a qualified QA tester than it is to find a great programmer. If you know what you're looking for, it's difficult to come across the right kind of QA testing resource because you're looking for a more specialized set of skills. If the business is complaining about quality sacrifices, they may be reacting to a perception that quality has suffered. If you're managing the continuous delivery process properly that perception will be a misperception. It's your job to correct it.
Send your executives a record of how your releases are tested both before and after a release process. Some of these concerns may just be an attachment to the old QA “ceremony.” Our experience shows that it's best to address these concerns with data.
The best response makes it clear that more frequent releases will result in far less risk while giving your developers the ability to address problems in production more quickly than before.
“I don’t even know what we’re shipping and when?”
This is a variation on “it was easier with a two-week release cycle.” What you need to do here is make sure that your continuous delivery pipeline has the appropriate change notification sent to the appropriate stakeholders.
This is where Plutora’s RACI matrix comes in handy. If your executives don’t feel communicated with about what’s happening in a specific release, you need to make sure that the right people are on the “I” quadrant (informed) of this matrix.
Such a comment also suggests that you need to take the time for each release to schedule meetings with affected business stakeholders. If you're not using a dedicated release management tool like Plutora, it's almost impossible to aggregate and understand the effective RACI matrix for a given release process. With Plutora we record all of this for you and give you a list of people who need to be informed about the release process.
If you're embracing Agile and moving toward a more continuous delivery model across your organization, Plutora is one way to make sure that you keep your executives informed.
“Continuous Delivery seems risky. Who’s making decisions about features?”
When your releases are infrequent and more “ceremonial.” Business has a steady and predictable number of interaction points with IT. Product managers and business stakeholders can also think of the progression of a product in distinct cycles. Once every two weeks the business used to deliver a set of features and those features could be measured and reported upon.
In the past, when the business end focused all efforts on a “release,” it wasn’t thinking about individual features. This might have made it easier for the business to think about “what is going into the April release.”
Now that you have a team of engineers ready to push code to production every single day, the business end needs to stop thinking about the release "event" and start thinking about the product as a continuous progression of features. Product managers and project managers need to start thinking about “features” and stop thinking about “releases.
Moving to a Continuous Delivery Model
As you move to a more continuous delivery model, you should also be moving toward smaller, more independent release teams. These smaller teams will be delivering features to a very well defined portion of your application. After you make this transition you’ll be able to create a report for the business that outlines changes to a specific portion of your application.
With Plutora you’ll be able to see everything assembled, in one place, no matter how many teams you're supporting. Request your Plutora demo here.
Download our free eBook
Mastering Software Delivery with Value Stream Management
Discover how to optimize your software delivery with our comprehensive eBook on Value Stream Management (VSM). Learn how top organizations streamline pipelines, enhance quality, and accelerate delivery.