Toggle Menu

Insights > Digital Service Delivery > Top 3 Things a Product Owner Needs to Know about Continuous Delivery

Top 3 Things a Product Owner Needs to Know about Continuous Delivery

About a year ago our Scrum team had a conversation about implementing continuous delivery (CD). It’s something we had been striving for, but weren’t sure if we were ready to take that next step. Is CD technically feasible? Do we have the right infrastructure in place? Is it the right time do this? Will our […]

By

November 07, 2017

About a year ago our Scrum team had a conversation about implementing continuous delivery (CD). It’s something we had been striving for, but weren’t sure if we were ready to take that next step. Is CD technically feasible? Do we have the right infrastructure in place? Is it the right time do this? Will our Product Owner (PO) buy in? The first three questions were challenging, but after a few meetings between our developers and DevOps, we concluded that we had everything we needed to implement CD. However, the last question regarding getting buy in from our PO was a little more interesting. As a Product Owner, it’s easy to get satisfied with deploying to production on a set schedule, say bi-weekly or monthly. Yet, the benefits of CD can be quite rewarding. I sat down with our PO to explain the benefits and answer some questions about the risks associated with CD and the following is a simulation of that conversation.

1. Always delivering value

Q: What is the benefit of continuous delivery?

A: Arguably the main benefit of CD is that you are constantly delivering working software to production; and doing so in a matter of minutes. With every commit, code is being pushed up through all your environments and value is being delivered to the end user. If a bug is ever reported, with CD it can be resolved and corrected in production within the hour. Without CD, code could be written to fix the bug, but it may not get deployed to production for a couple of weeks depending on your release schedule. CD also results in much less, if any, downtime for deployments to get new features out to its users. I know what you may be thinking; this sounds risky. Or maybe you’re wondering why you would deploy code to a feature that’s unfinished? Don’t worry. Those topics are up next.

2. Reducing Risk

Q: How will manual testing work when deploying multiple times a day?

A: Ideally, there will be little to no manual testing that will need to occur after every production deployment. As long as you have the proper automated testing in place, you can free up time and resources that would usually be spent conducting tedious manual testing after each deployment. For example, acceptance tests could be written for every story the team completes as well as implementing automated smoke tests to ensure your application doesn’t break on each commit. If any of these tests should fail while that code is going through the pipeline, the deployment itself would fail and therefore not be pushed to production.

Q: Won’t we introduce bugs at an alarming rate with such frequent deployments?

A: It’s more so the opposite. With the proper testing in place, you should see a decrease in the number of bugs introduced over time once CD is in place. Without CD, all code commits would sit and wait to be merged until the designated “release date”. On that date, the team would have to merge all commits from the prior “release date” and then resolve any merge conflicts, or bugs, that would occur. CD results in code not sitting and waiting to be merged. As soon as new code has been reviewed and approved, it’s sent to production. Here’s an interesting article on automated tests in a CD environment, https://continuousdelivery.com/foundations/test-automation.

3. Feature Toggles

Q: If every code commit gets pushed to production, how will that work if we haven’t finished developing the MVP (Minimum Viable Product)? I don’t want our users using an incomplete feature!

A: Excellent question. Luckily, we can utilize feature toggles! Feature toggles can associate certain parts of the code with a certain feature. As you may have interpreted from the word “toggle”, with any feature, we’re able to turn it on, or off, at any time. That way, with every commit, we can make sure a feature is toggled off as we are continuing to build it out. Once that feature is complete, or the MVP has been developed, then your PO can decide to toggle that feature on at that time. If anything unexpected should pop up regarding this feature, your PO can simply toggle the feature off for the time being.

As touched on above, there are many great outcomes that can be achieved with continuous delivery. Once your team has the proper infrastructure and technical resources in place, it may be time to have the CD conversation with your Product Owner. At the end of the day, with CD in place, you’ll be able to respond rapidly to the needs of your customers, which is something we all strive to achieve.

You Might Also Like

Agile Training

Knowing Your CSMs from Your CSPOs

Agile experts think great product owners act as entrepreneurs for their product. Product owners and...

Tech Tips

Embrace the Chaos

You are probably familiar with some form of the following: Should we be using story...

Professional Development

Inspecting and Adapting Myself

“Between stimulus and response, there is a space. In that space is our power to...