Morten’s adoption story starts with a team at eBay Denmark. The team had started working in a more continuous mode, but there was a lot of “release friction” as Morten calls it. You are probably familiar with that friction: it takes a long time to release; the site needed to be “closed” for every release; the team would need to come in at night during the weekend, etc.
That’s the reality for many teams. No surprise they prefer to release less often. In this segment, we explore that story, and also the steps the team took to go from “high friction” to “no friction”.
Read more to find out how Dev and Ops are different and why that matters when adopting Continous Delivery.
The contrasting goals between Development and Operations
Operations teams have different goals from development teams. While development teams want to get software early and often, Operations teams need to consider the impact of all changes on the availability of the service. Because of this, Operations teams tend to be cautious and pull back their support for continuous releasing. Here starts a conflict that Continuous Delivery can solve. Many of us are familiar with the idea of DevOps, where development teams are close to the operations. DevOps is one of the possible solutions to this tension, but there are more. In this segment, we talk about a Maturity Model that helps determine if the team is ready to move towards Continuous Delivery. We refer to the ThoughtWorks Continuous Delivery Maturity Model, as well as the Continuous Delivery maturity model by a Norwegian company Bekk.No.
Reducing stress levels and business risks with Continuous Delivery
There are many different benefits to using Continuous Delivery. In this segment, we focus on the benefits to the business and the team. We mention 3 critical benefits, and how Continuous Delivery helps us achieve those.
We discuss the focus on value, the enablement of fast learning through the quick release cycles, and finally, we mention the reduction of stress that comes from knowing we can release often. As we discuss, releasing more often actually reduces the risks that teams run because the changes they introduce are smaller.
In this segment, we refer to the book by Eric Ries, Lean Startup.
Value Stream map your way to a Continuous Delivery pipeline
How can we get started with the adoption of Continuous Delivery? Morten likes to start with a tool called Value Stream Map. The goal is to follow a change, from the moment the idea is generated to the moment when it is live for the end-user. From this, he gets an insight as to what are the steps of the process that take the longest (best to focus on these), and a good idea of what could easily be automated to remove errors or speed up the process. Value Stream Mapping is a process of understanding in detail how the workflows from beginning to end.
Visit this page for more on Value Stream Mapping.
The main challenge for teams wanting to adopt Continuous Delivery
When we talk about the main challenge for teams adopting Continuous Delivery, we end up discovering that the size of the batch (Sprint, number of stories, length of the project), is often the main impediment for teams to adopt Continuous Delivery.
Morten has a different challenge for you. When considering Continuous Delivery, consider first the size of the batches your team is taking on. What if the team was able to deliver to production every single story? That would define a simple, yet demanding, Definition of Done (DoD): the story is live to end-users.
This, in turn, changes the concept of what a release is in practice.
The unexpected meaning of Release when using Continuous Delivery
What if you could release to production every single User Story? This would change the meaning of Release. A Release would no longer be a large collection of changes, but it would happen several times per day. How can we get to that point? Beyond the process of change that the teams need to go through, there are some tools that help teams get there.
We refer to Feature Toggle / Release Toggle, Access Restriction to Features (by log-in or IP, for example). There are some Feature Toggle frameworks out there that help with the adoption, and we refer to this Feature Toggles article by Pete Hodgson on patterns for Feature Toggles.
Resources to help you adopt Continuous Delivery / Continuous Integration
We list many different resources in this episode. Here is the list of the ones Morten highlights:
- Jez Humble videos on YouTube about Continuous Delivery
- The book Continuous Delivery by Jez Humble and Dave Farley. Dave was a guest on the podcast.
- The book Accelerate by Forsberg, Humble and Kim
- The State of DevOps report by Puppet
A cautionary tale for the use of Feature Toggles and Continuous Delivery/DevOps.
About Morten Herman
Morten is a software professional that has been working with Software Product- and Software As A Service development for the last 15 years.
He started his career as a developer with a SCRUM master role and later became a software architect. In 2011 he changed to the team lead role and people manager at eBay in Denmark for four and a half years. In 2012, he heard about Continuous Delivery and DevOps for the first time. And since 2015 he started as an independent consultant, working with clients in relation to implementing various aspects of continuous delivery, DevOps and microservices in their organizations.
You can link with Morten Herman on LinkedIn.
