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.

Leave a Reply

Your email address will not be published.