Hello, I'm Thierry de Pauw
Continuous Delivery Coach - Software & Operations Engineer
Hire me!

About me

Lean/XP Full-Stack Software Engineer with a DevOps mindset. I do backend development and frontend development. I set up development infrastructures, define software and enterprise architectures, have lots of interest in operations and coach teams in adopting eXtreme Programming principles.

Along the years I have been a bit everything: Software Engineer, (Architect), Technical Team Leader, Scrum Master, Product Owner and Agile Technical Coach.

I like to help teams in creating meaningful software, with a keen eye for code quality and software delivery process - from customer interaction to continuous delivery. Instead of balancing quality & delivery, I believe and practice that better quality is actually a way to more and better deliveries. To me feature delivery and code quality goes hand in hand.

Services

Software engineering

My primary role is "Software Engineer". I have 20 years of experience. I still code and I am passionate about this. This is my bread and butter. But I am not a Monkey Coder. I do the whole shebang. From inception over coding, testing, setting up the infrastructure, to releasing into production and monitoring the damned application.

I pay a lot of attention to quality of code and maintainability.

Without these skills, I cannot be a proper Agile Technical Coach. I cannot help organisations achieve a state of Continuous Delivery. Everything I know, I learned through delivering working software in production.

Agile Technical Coaching

Based on the 20+ years of experience delivering software applications I help teams in adopting the practices that make Continuous Integration and Continuous Delivery.

I coach in working in Small Increments, having a Decoupled Codebase, Simple Design and Fast Builds and adopting Test Driven Development, Refactoring, Expand-Contract, Pair Programming, Test Automation, Collective Ownership and Hiding Unfinished Functionality.

Continuous Delivery

I help organisations and teams achieve a state of Continuous Delivery, i.e. being able to release product increments sufficiently reliably and quickly to satisfy customer demand.

This means first and foremost adopting a series of both technological and organisational changes that will help teams deliver significantly faster at a sustainable pace, with higher quality and lower costs. Which changes to adopt and in which order is specific to the unique circumstances and constraints of your organisation. There is simply no fixed roadmap to the adoption of Continuous Delivery.

Continuous Delivery is not a tooling problem. The tooling part is the easy part to solve. It is really about a change of organisational mindset.

I'm available for online Continuous Delivery coaching at the rate of 200 EUR per hour excl. VAT. You can check my availability here.

Talks

The Practices That Make Continuous Integration


Continuous Integration is by itself already a practice. It is one of the most critical to adopt to enable the fast flow of work through the value stream. However, many teams believe Continuous Integration is just a tooling problem, to then say they practice Continuous Integration.

I Have 99 Problems - Where Do I Start? The Theory of Constraints Applied


Your IT organisation is surrounded by problems preventing it to satisfy market demand on time with the required quality. Where do you start?

From twice a year to twice a month: the story of No More Majors


The Belgian Federal Pension Service (SFPD) has a large IT department with more than a dozen teams working on the same application. Over the course of a few years, these teams developed an agile way of working at the team level but were struggling to work effectively on a larger scale.

Continuous Delivery in 4 months for 15 teams and their 1 monolith


15 teams, 1 shared monolith, 1 release every 6 months, and product demand for 1 release every 2 weeks. How do you know where to start with Continuous Delivery, when you’re surrounded by technology and organisational challenges?

Feature Branching considered Evil


Feature branching is again gaining in popularity due to the rise of distributed version control systems. Although branch creation has become very easy, it comes with a certain cost. Long living branches break the flow of the software delivery process, impacting throughput and stability.

Continuous Delivery is more than just Tooling, It's a Mindset


So your organisation wants to implement Continuous Delivery. But is your organisation ready for this ? Does it have the right mindset ? To be successful with Continuous Delivery, you have to adopt the proper mindset as a whole organisation. Just throwing tools at it will not do the job.

3M EUR later: Moving a team to become Agile in a Company with Too Much Money


How do you go from a ragtag of people having no idea what it means to be Agile, stuck in eternal maintenance and operational work, applying none of the basic software engineering practices to a team of DevOps delivering value for their customers in sprints of 2 weeks ?

Facts and Fallacies of Continuous Delivery


Continuous Delivery brings a lot of value to your organisation. It will allow you to reduce your time to market for new features and bug fixes. It is a significant predictor of company performance.

Experience

Belgian Gambling Commission Elia Johnson & Johnson Thomson Reuters BPost KBC Inventive Designers SWIFT Bru Textiles BNP Paribas Fortis ACA-IT Solutions Barco BlueSquare World Health Organisation La Chambre - De Kamer SFPD - Belgian Federal Pension Service La Croix Rouge de Belgique PaxFamilia

Articles

The Practices That Make Continuous Integration - Building for Continuous Integration


In part 1 - Team Working for Continuous Integration we looked into the team practices that make Continuous Integration. In part 2 - Coding for Continuous Integration we explored the engineering practices for Continuous Integration. In this last part, we investigate the required practices for a team to succeed with Continuous Integration, i.e. which are the building practices and how to improve builds to support the team practices - especially Agree as a Team to Never Break the Build - and the coding practices - in particular Make Changes in Small Increments and Commit Frequently.

The Practices That Make Continuous Integration - Coding for Continuous Integration


In part 1 - Team Working for Continuous Integration we looked at all the necessary practices to achieve team work around Continuous Integration. Now, we investigate the critical engineering practices individuals, pairs or ensembles should adopt to attain Continuous Integration as a team.

The Practices That Make Continuous Integration - Team Working for Continuous Integration


This first part of this series investigates the practices that enable teamwork that in turn enable Continuous Integration. Continuous Integration is a Team Practice. We achieve it as a team and not as a set of individuals. Most of the time, practices are defined for individuals. When most team members apply them, the team does well. However, with Continuous Integration, most team members have to implement other practices before the team can say they practice Continuous Integration.

The Practices That Make Continuous Integration


Honestly, it feels a bit awkward to still write about Continuous Integration. It has been over 20 years since Kent Beck introduced Continuous Integration in his book Extreme Programming Explained. But, when looking around me, I realise teams and organisations still struggle with adopting Continuous Integration.

On the Evilness of Feature Branching - How To Avoid The Problems?


In part 4 of this series - The Problems I dived deep into the problems introduced by feature branching. But, what can we do about this? How can we avoid the problems introduced by feature branching altogether?

On the Evilness of Feature Branching - The Problems


In part 2 of this series - Why do Teams use Feature Branches? - and part 3 - But Compliance!? I went into all the possible reasons teams mention themselves to why they use feature branches. This time I want to go deeper into the problems introduced by the use of feature branches.

The Fallacy of the 100% Code Coverage


Is pursuing 100% code coverage a good or a bad thing? Code coverage is an interesting metric. However, 100% code coverage is a crappy target. It encourages gaming.

On the Evilness of Feature Branching - But Compliance


In part 2 of this series - Why do Teams use Feature Branches? - I examined all the possible reasons teams mention for why they use feature branches. There was, however, one reason, I did not mention that people referenced as the ultimate reason: “We use feature branches and pull requests to comply with regulations”. I would like to explore this and show there are other options to comply that do not have the same drawbacks.

A Tribute to Self


A breath of kindness to remind me of the lovely people who appreciate me.

On the Evilness of Feature Branching - Why do Teams use Feature Branches


In part 1 of this series - a Tale of Two Teams - I introduced two quite different teams. One novice team practising trunk-based development, the other experienced but being used by GitFlow. Now I would like to explore why teams use feature branches. What are their reasons? What problems are they trying to solve with long-running branches?

On the Evilness of Feature Branching - A Tale of Two Teams


On the experience of working with two totally different teams: one novice practising trunk-based development, the other very experienced being used by GitFlow.

Testable IAM Policy documents


Pulumi is the new kid on the block in the cloud infrastructure as code arena. I was relieved to find Pulumi. Finally, we have testable Infrastructure as Code. We can write fast unit tests that we can execute locally without needing the cloud. However, I was a bit disappointed. Pulumi does not have a full representation of IAM Policy documents. Fortunately, it was relatively easy to build a library that did this!

Hiring Questions


A set of questions I use during the occasional times I have to run an interview to hire engineers inside an agile team.

Shades of Conway's Law


Over time, different people have articulated Conway’s Law in various different ways. This is an overview of the variations I found when recently going over Conway’s Law literature.

On the Evilness of Feature Branching


Branch creation became very easy with the advent of Distributed Version Control Systems. However, it comes at an unquestionable cost. Long living branches break the flow of the IT delivery process, impacting both stability and throughput.

Five Years of Public Speaking


It has been five years since I started with public speaking. I wanted to share my journey into public speaking. My highs and my lows. Maybe my experience as a shy, introverted person can help others.

Scrum Master Toolbox Interview - Continuous Delivery for Scrum teams


Back in October 2019, Vasco Duarte wanted to perform a bonus series on Continuous Delivery for the Scrum Master Toolbox Podcast. By chance, I got part of this series.

Continuous Integration is Not a Tooling Problem


There is this commonly accepted, hard-grained belief in the software industry. By dropping a build server in a team, they get Continuous Integration magically for free. This belief is further incentivised by the marketing of build server vendors.

Interview with Thierry de Pauw — about his journey with Continuous Delivery


In this post, Leena interviews Thierry de Pauw, a Software Engineer who coaches on Continuous Delivery and other Software Engineering Practices. His focus is helping teams to improve the flow of software delivery.

Notes

An Agile Data Warehouse by Ron Ballard


Data Warehouses are normally seen as big, expensive, lengthy, waterfall projects, using complex and costly tools. They don’t need to be. As someone who has helped several teams to build successful data warehouses, I know that an Agile approach is much better, and in this talk I will explain how we do this. We can deliver incremental, useful reports and applications within weeks of starting the project and can continue to consolidate an organisation’s data, improving its quality and the meaningful insights it can deliver. At the same time we develop wider understanding of the data, often leading to improved business processes.

Diversity as a non-negotiable of Business Agility by Claudia Pellegrino


This talk explains that D&I is the main asset organisations have, to thrive in a complex world. It explains how D&I is a real catalyst to achieving Agility, and that to solve complexity, Diversity and Agility must go hand in hand

Closing Keynote - How to get out of (technical) debt! by Sally Goble


We’ll discuss what debt looks like, and how easy it is to get into debt in the first place. Then we’ll put a plan into action,

Keynote - One for all and all for one - What does culture really mean? by Vimla Appadoo


The world has turned itself upside down the past two years - there’s no doubt about that. With it, our relationship with work has shifted, team dynamics have changed and how and where we work is up for constant debate. With that in mind, Vimla will be taking the stage to speak about conscious culture and intentional team design - how can we help our people be their best selves so that they design and deliver products and services that are fit for everyone. Sounds easy right? It’s an ambition that most companies strive for, but very few achieve so join Vimla’s talk to see what role you can play in changing the world.

The Excellence Paradox by Gareth Thomas


Great products come from great passion, not technical excellence. The products with the best market fit, beloved of users, will often be held together with love and damp string. In their murky codebases you’ll find every example of bad practice. These products of passion grow quickly, but often fail when the technical limits of their poor implementation start biting. Exceptionally high running costs, high costs of change, and increasing fragility can damage the customer relationship.

How to create the conditions for an awesome DevEx by Hibri Marzook


This session will explore the conditions needed to facilitate developer autonomy and create an awesome DevEx. What makes a good developer experience? What are the common stumbling blocks? How to architect to manage risk, governance and autonomy? How to build modern team topologies that don’t hinder progress and ensure long term sustainability? How to build a culture that is transparent and breaks down silos?

OKRs - the good, the bad and the ugly by Neha Datt


A quote from a recent client: “We don’t do the important stuff…because we won’t do anything that is NOT our OKRs”. Also: “OKRs give me performance anxiety :-(”

You Build It You Run It sounds great… but it won’t work here! by Steve Smith


Since You Build It You Run It was outlined in 2006, on-call product teams as an operating model has gone from being a controversial idea… to being a controversial idea. Enterprise organisations don’t do it, but they do talk about why they don’t do it.

Architecting for Testability by Emily Bache


If you are a developer you are probably working on a large and complicated codebase. Unfortunately a lot of existing code lacks automated tests and adding them can be challenging, particularly if the code is old or poorly structured. Testability has always been an aspect of architecture that people have said is important but all too often I see this aspect ignored. Approval testing is a technique that helps you to get a difficult codebase under test and begin to control your technical debt. Approval testing works best on larger pieces of code where you want to test for multiple things. Because of this, the architecture of the system is really important for success with this testing technique.

You can do better than the Spotify Model by Joakim Sundén


Let’s put aside the ‘bubblegum and unicorns’ of the Spotify Engineering Culture videos and talk about what doesn’t quite work at Spotify, and how we’re trying to solve it. This is a failure/learning report intended for coaches and other change agents who need encouragement that it’s always hard AND it’s always possible to improve.

Continuous Delivery - Sounds Great but It Won't Work Here by Jez Humble


Over the last 7 years I have heard lots of reasons on why people can’t do Continuous Delivery. This is my summary of these reasons and why they are wrong.

Keynote - Quality vs/and Speed by Ian Larsen


Clarke Ching organised the online conference ToC Down-Under Summit 2021 at Sydney time. I was able to attend the first two presentations of each day. These are my notes of the keynote of day 2 given by Ian Larsen.

Keynote - Three big questions in ToC by Justin Roff-Marsh


Clarke Ching organised the online conference ToC Down-Under Summit 2021 at Sydney time. I was able to attend the first two presentations of each day. These are my notes of the keynote of day 1 given by Justin Roff-Marsh.

Conway’s three other laws by Mike Amundsen


Most of us know about Conway’s adage “Any organization will produce a design which is a copy of the organization’s communication structure.” But Conway coined four laws in his 1968 paper “How Do Committees Invent?” What are the other ones? Why are we not talking about them? And what do they tell us about optimizing teams in a distributed world? – Mike Amundsen

How Do Committees Invent? by Melvin Conway


This is the paper behind Conway’s Law. I’ve assembled some snippets from the paper that triggered me and added some thoughts.

Nine ways to fail at Cloud Native by Holly Cummins


Cloud native is the perfect recipe for innovation, adaptability and engineering excellence – when it goes right. When it’s not right, it can be a monster spaghetti, a quality headache, and frustratingly inflexible. Why so negative?

Accidental Architects - how HR designs software systems by Matthew Skelton


Who designs the architecture of your software systems? Conway’s Law suggests that HR may be strongly shaping software architecture by deciding how teams are composed and interrelate. Do you want HR designing your software architecture?

Maturity Mapping or how to tailor capability adoption to your existing culture by Marc Burgauer


One of the issues with the maturity models we often use to assess teams is they are context free. They don’t take the environment into account, missing the challenges and the specific needs we have in our context. We will explore an alternative: Maturity Mapping. How can Wardley Mapping, Social Practice Theory and Cynefin be applied together to develop situational awareness and build a shared understanding of the practices you use and the unique challenges you face.

Turbulence - Thinking Flow Again by Jabe Bloom


Thinking about flow from some new perspectives. Find opportunities to think about flow. Talk about turbulence: how flow is both good and bad.

Autopilot, but never let go of the wheel by Simon McCartney


From TOIL to Continuous Delivery of Infrastructure, our tail of migrating our existing Infrastructure as code tools & wrappers so that they can be used in a CD system, but with all of the control grey-beards, enterprises & governments expect.

Evolution from #NoProjects to Continuous Digital by Allan Kelly


We are trying to tell something positive about #NoProjects instead of just saying No.

Analytics rebooted - a workshop by Anand Bagmar


My notes from the Anand Bagmar’s Analytics workshop I followed at AADays 2018 in Poland.

Kickstart your Performance Testing by Konrad Marszalek


My notes from a performance testing workshop I followed at AADays 2018 in Poland. It was my very first encounter with performance testing.

Continuous Delivery and Conway’s Law by Allan Kelly


This is a full transcript of Allan Kelly’s “Continuous Delivery and Conway’s Law” at the LondonCD Meetup. It gives an in-depth overview of what Conway’s Law is, how it impacts organisational and system design and how it relates to Continuous Delivery.

Feature Branches and Toggles in a post-GitHub World by Sam Newman


Why I got interested in micro services? Because from my early days at ThoughtWorks was actually helping people ship software more quickly. I spent lots of time looking at Continuous Integration, Continuous Delivery, cloud automation, infrastructure automation, automated tests, and all these sort of things. And realise that actually it was the architecture of these systems that made it hard to ship software more quickly.

Make the agile transition work! And what HR can do to support it... by Maike Goldkuhle


These are my notes on Maike Goldkuhle’s session at XP2017 on HR and Agile. I wanted to attend this session because there is very little said about the role of HR in agile transitions.

Measuring Continuous Delivery by Steve Smith


This is a full write out, almost word for word, of Steve Smith’s presentation ‘Measuring Continuous Delivery’ at Pipeline Conf 2017. I’ve written this presentation down, together with the first version of this presentation at the LondonCD meetup, to be better prepared to review Steve’s book Measuring Continuous Delivery.

Acceptance Testing for Continuous Delivery by Dave Farley


Dave Farley describes approaches to acceptance testing that allow teams to work quickly and effectively, build functional coverage tests and maintain those tests throughout change.

You Are What You Eat - How Branching Affects Team Culture by Dave Hounslow


Your branching strategy is an extremely important choice to make. In this talk I hope to show how a change of branching strategy can actually change your team’s mindset. Specifically I look at a shift from a feature branching strategy to a trunk based strategy affected the team. In my view these changes were for the better and I guess most at PIPELINE will agree but I leave that for others to decide on this occasion.

Beautiful REST + JSON APIs by Les Hazlewood


Les Hazlewood, CTO @ Stormpath gives an in-depth overview of what makes a RESTful API. The original video on which these notes are based is not available any more. I fell back on the video of JAXConf.

Contact me


Thierry de Pauw

Continuous Delivery Coach - Software & Operations Engineer

Business details

ThinkingLabs
hello@thinkinglabs.io

Gent, Belgium

It doesn't matter what you improve, as long as you're improving something.
Make experiments.
Fail Fast.