BONUS: Chris O’Dell interview – Continuous Delivery for Scrum teams, Part 5

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:

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.

Get The Booklet!
How to deliver on time and eliminate scope creep By scoping projects around outcomes and impacts, not requirements!
Get the Product Owner Booklet!
Avoid scope creep! And learn to scope projects around impacts and outcomes, not requirements!
Get These Valuable Lessons Today!
Down-to-earth, hard-earned Scrum Masters lessons and the Tips from the Trenches e-book table of contents, delivered by email
Enter e-mail to download a clickable PO Cheat Sheet
This handy Coach Your PO cheat-sheet includes questions to help you define the problem, and links to handy, easy techniques to help you coach your Product Owner
Enter e-mail to download a clickable PO Cheat Sheet
This handy Coach Your PO cheat-sheet includes questions to help you define the problem, and links to handy, easy techniques to help you coach your Product Owner
Enter e-mail to download a checklist to help your PO manage their time
This simple checklist and calendar handout, with a coaching article will help you define the minimum enagement your PO must have with the team
Enter e-mail to download a checklist to help your PO manage their time
This simple checklist and calendar handout, with a coaching article will help you define the minimum enagement your PO must have with the team
Internal Conference
Checklist
Internal Conference
Checklist
Download a detailed How-To to help measure success for your team
Motivate your team with the right metrics, and the right way to visualize and track them. Marcus presents a detailed How-To document based on his experience at The Bungsu Hospital
Download a detailed How-To to help measure success for your team
Read about Visualization and TRANSFORM The way your team works
A moving story of how work at the Bungsu Hospital was transformed by a simple tool that you can use to help your team.
Read about Visualization and TRANSFORM The way your team works