BONUS: Thierry de Pauw interview – Continuous Delivery for Scrum teams, Part 2

When Thierry got started, the team had troubles with version control, so he helped the team “commit to trunk”, and after that, it was much easier to adopt continuous integration. The build server quickly evolved into a continuous build pipeline. From there it was a small step to continuous delivery. 

Although not all stories are this easy for teams adopting CD, this story provides a striking example of how things that are “hard” for some teams, just become the “natural way” of working for others. What’s preventing your team from working this way? 

Read more to find what was Thierry’s most painful lesson about Continous Delivery adoption as well as all the resources he recommends for those wanting to dive deeper into the topic.

A lesson learned about change management when adopting Continuous Delivery

When working with your team to adopt Continuous Delivery, Thierry’s suggestion is simple: help it along and wait for it to evolve organically. We can start by focusing on the steps of the process that take the longest time, and work to either remove, change or automate (in that order). 

We then talk about what Continuous Delivery means in practice and refer to Jez Humble’s definition of Continuous Integration (a critical part of Continous Delivery): 

  1. Everyone in the team commits at least once per day;
  2. Every commit triggers a build;
  3. You can fix a broken build in less than 10 minutes.

In this segment, we also talk about some anti-patterns such as: very long living branches without any integration to master; when the team faces problems when trying to work in incremental steps; having very slow builds.

Theory of Constraints, the true inspiration for Continuous Delivery adoption

We discuss how the Theory of Constraints (TOC) was the original inspiration for improving, and ultimately getting to a place where Continuous Delivery is possible. In TOC, we learn that the goal is to find and remove bottlenecks to the goals and performance of a team/organization. That’s how CD got started. For businesses, the goal is to deliver value to customers that can be transformed into value for the business (e.g. revenue). Every added step, or slow step in the process will have a negative impact on the business. Eventually, when applying TOC to how software organizations deliver value to their customers, we will end up with a Continuous Delivery model. 

In this segment we also refer to the book Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Forsgren, Humble and Kim; and Conway’s Law, something you should be aware of when adopting CD: 

How to get started when adopting Continuous Delivery in your team

We talk about how starting the CD adoption journey can be daunting, and scare people. Alternatively, Thierry suggest, we should focus on small, yet relentless steps towards a vision for the way we deliver software. In this context, we refer to the book Improvement Kata by Mike Rother, a book that explains a coaching/learning method that can help you solve any large problem with the team.

Maturity models are often used and touted as helping, however, those models are often linear and don’t account for the many possible ways to reach the goal of CD. 

In this segment, we also talk about the many technical challenges that teams will face when adopting CD. Don’t be scared by that, help the team evolve slowly, but deliberately towards the CD Vision.

Resources to help you adopt Continuous Delivery / Continuous Integration

We discuss many different resources to help you and the team evolve towards CD / CI: 

The videos from the London Continuous Delivery meetup.

 

About Thierry de Pauw

Thierry is a CI/CD advocate, lean software engineer and occasional speaker.

Currently, he is Engineering Lead at the Fintech startup PaxFamilia.

Thierry also founded ThinkingLabs, a consultancy around Continuous Integration and Continuous Delivery. In 2019 Thierry organized the CITCON – Continuous Integration and Testing unconference in Ghent, Belgium.  

Visit Thierry’s website at Thinking Labs.

You can link with Thierry de Pauw on LinkedIn and connect with Thierry de Pauw 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