Chris started her Continuous Delivery in a small agency, nurturing a build server that nobody cared for. That gave her an insight that is not very common: taking care of the build server was a very practical way to help and care for the team’s success. It was a practical tool that the team needed, but no one was looking after. It was a concrete way to help people.
Read more to find out how trust plays a key role in Continuous Delivery adoption, and to read Chris’ recipe to get your team started with CD.
Adopting Continuous Delivery requires trust between different groups of people
One of the biggest challenges teams face when adopting Continuous Delivery is the lack of trust between different areas or departments. Even if engineers want to ship, ship, ship, as Chris puts it, the problem is that on the other side you might have an operation’s team that has suffered through many botched or problematic releases. One of the steps we must take is to help repair that lack of trust, and even build the necessary processes and tools to support that change. A possible way to repair the trust between engineering and operations is to focus on smaller and less risky changes/releases, a topic that Chris develops in this blog post.
Getting Scrum teams started with Continuous Delivery
When helping teams starting their Continuous Delivery adoption process, we talk about the need to start with simple steps, and supporting what the team already has in place. From there, we can help the teams find and solve some of the major pain points like adding simple smoke tests, for example. A question that can help that process get started is: “can you build the current known-good version and release it?”
Once the building and releasing process are reliable, we should also focus on monitoring, which will allow us to find problems after a release gets out the door.
How much is too much releasing?
When we talk about multiple releases, even 100’s of releases per day, we should first consider the scale of the organization. Chris suggests that 1 release per developer per day is a good benchmark number for organizations to evaluate their ability to release continuously. How we get there is by focusing on small improvements that aim to resolve the most important bottleneck at any given time. In this segment we refer to Theory of Constraints, and discuss the roles that tools and culture play when enabling teams that want to reach multiple releases per day.
When releasing stops being what you would usually consider a “release”
When teams can deliver multiple versions of the product to the market per day, the release process takes on a significantly different role in the Software Delivery Lifecycle process. As smaller and smaller changes get released, so does the process of releasing. For example, Feature Flags enable the team to continuously develop the product, and not need to separate the release (latest code gets shipped) from deployment (customer gets access to the latest features).
The smaller changes also represent smaller risks, which makes the release process more lightweight.
Resources to help you adopt Continuous Delivery / Continuous Integration
We list many different resources in this episode. Here is the list of the ones Chris highlights:
- The website by Jez Humble: ContinuousDelivery.com
- The Goal by Elyahu Goldratt, a business novel about Theory of Constraints
- The Phoenix Project by Gene Kim at al., a business novel based on The Goal, but specific to the IT world
- The book Accelerate by Forsberg, Humble and Kim that goes into the science / study of the impact of Continuous Delivery
Happy Learning!
About Chris O’Dell
Chris works at Monzo helping to build the future of banking. She has spent nearly fourteen years as a backend engineer, primarily with Microsoft technologies, but recently with Go on Monzo’s large microservices platform. She has led teams delivering highly available Web APIs, distributed systems and cloud based services. She has also led teams developing internal build and deployment tooling with the goal of improving the developer’s experience. Chris promotes practices such as Continuous Delivery, including TDD, version control, and Continuous Integration.
You can link with Chris O’Dell on LinkedIn and connect with Chris O’Dell on Twitter.
