Trunk-based development might increase burnout? 🔥 My thoughts on the 2023 State of DevOps Report 🤔

Introduction

Hello, developers! 🚀

The 2023 State of DevOps Report was released in October 2023, you can find it here: it’s the annual update to the research on which the book Accelerate was based on in 2018. Every year, the research continues and the update is released, but this time, for the first time (as I can remember, at least) a real concrete negative effect has been registered after one of the Agile Practices considered in the research - in particular, it’s Trunk-based development.

Let’s reflect on the research!

The 2023 State of DevOps Report

On the 18th of November, I attended the Italian Agile Days 2023 Conference in Milan as a speaker, at the Politecnico University; my talk was just right after the lunch break, and I talked about Continuous Integration and Trunk-based Development, how those two practices are related and which benefits they bring - the video is not available, but you can see the slide deck here.

During the Q&A session, one of the questions came from Ruggero:

What’s your opinion about the last State of DevOps Report, where it emerges an increase of burnout due to Trunk-based Development?

At that point, I hadn’t read the report yet, only a quick recap article that didn’t highlight much of this burnout topic - so I was a bit surprised, and I responded that it’s hard to have an opinion on this without having more context. For example, if the practice is forced on the team, or it’s not supported by proper training, I can imagine that at least in the first weeks it can be an overhead for people used to long-living branches. Still, my experience is similar to Ruggero’s: CI and TBD make life easier, and I’ve seen this for both average and above-average skilled developers!

So, I left the conference with this question in mind and decided to look for the complete report, and for more complete articles about it, to see what it states and reflect on it - this article is the sum of my thoughts!

Side note: after writing this article, I also had a podcast episodes with Ruggero itself to discuss about this topic. If you know italian (or feel like reading Youtube subtitles) you can also listen to it on YouTube, Spotify or Spreaker.

Some key insights from the report

The article from the DORA team highlights 5 key insights:

A healthy culture matters: teams with generative cultures have 30% higher organizational performance
User in mind: teams that focus on the user have 40% higher organizational performance
Documentation has an impact: high-quality documentation leads to 25% higher team performance
Work distribution is not fair: women and underrepresented people have higher levels of burnout
Cloud used effectively: leveraging the characteristics of the cloud, like rapid elasticity and on-demand self-service, teams can get the most value out of the cloud: this flexibility leads to 30% higher organizational performance

The first thing I noticed was that the recap/announce article from the DORA team does not emphasize much about burnout increase related to TBD. At this point, without reading the report yet, I had 2 hypotheses: either there is something more in the report that makes them not give that much weight to that, or they are trying to ignore it for now to avoid controversy.

While the second is still an option (it can even be for a good reason: it’s the first time that shows up, so we still need some confirmation before actually worrying about it), I couldn’t avoid approaching the report hoping to find something supporting the first option: “there must be something more”, I thought.

And finally, I started reading it.

Burnout can increase with TBD?

The technical capabilities considered and analyzed in the report evolve year after year, so it’s important to consider that these are the 5 technical capabilities considered this year:

AI
Trunk-Based Development
Loosely coupled architecture
Continuous Integration
Rapid code review

As always, the report considers 2 types of impacts: performance measures (team, organizational, software delivery, and operational performances) and indicators of people's well-being (burnout, productivity, job satisfaction).

Focusing on Continuous Integration and Trunk-Based Development here, the impact on performance measures overall is quite good, as always: both practices showed minor increases in team, organizational, and software delivery performances, with a minor decrease in operational performances for TBD.

On the other hand, looking at people's well-being’s indicators, it looks like there is no effect directly from this two practices in most cases, but with minor increase in job satisfaction thanks to CI, and a substantial increase on burnout because of TBD.

And here we are! Let’s deep dive into this part of the Report to find out something more: we have two sections to discuss, the first one being this data with some additional info and comments, while the second one being a note on the benefits of Continuous Delivery from Dave Farley.

Before looking at the conclusions and answers we can take from the report, one side note from me: I’m not sure that those practices should actually be considered separated. I mean, CI embeds TBD - it is the actual topic of my talk at IAD 2023 - so focusing on TBD means focusing on 1/6 of CI. As always, discover more about this and my other personal thoughts in the next section, Dan’s take.

Back to the report: about performance measures, no particular comments worth highlighting here - they basically consider it all positive. To be honest, they treat as pretty positive also the people's well-being’s indicators - quoting the report:

Additionally, these capabilities and processes don’t show a detrimental impact on the well-being of the individuals doing the work. In fact, most of these predict improvements to the individual’s well-being.

A lot more focus is on highlighting how much all the indicators increase positively than on asking why one decreased - I’m not sure if it’s correct from the scientific approach point of view, but for sure it looks a bit surprising for me.

Even Dave Farley looks more surprised from the impact on performance measures (positive, but not as much as he expected) than from the people side:

I am somewhat surprised that continuous integration (CI) and trunk-based development didn’t have a bigger impact on software delivery performance.

And finally, two new metrics are added here: stability (change failure rate and failed deployment recovery time) for quality and throughput (change lead time and deployment frequency) for fast feedback and problem detection.

But most of all, the concept of mediators is introduced: CD, for example, is a mediator of many technical capabilities (including CI and TBD), meaning that those capabilities works because they create an environment that enabled CD.

Basically, Farley highlight something similar to my question above: we cannot just consider those capabilities as separated, they are connected to each other - one might be enabler for the other, and so on.

So, when we read at this data where TBD seems to be a (rather small) danger to burnout, we should consider that, for example, code review speed substantially decrease the burnout - and what’s a best way to reduce code review time than reducing the size of the review via TBD? 😉

I will share my thoughts in the next section, as always - but let me know what do you think by replying to this email or commenting the LinkedIn/Twitter post where I shared it!

Until next time, happy coding! 🤓👩‍💻👨‍💻

Dan’s take 🙋🏻‍♂️

I have to admit that the question at the conference made me panic a bit: Accelerate, the research behind that book, and the yearly updates to the research are one of the best tool we can use to support and proof the importance of the Agile Practices for a business, and while it is totally correct (and to be appreciated) that elements against the ideas are highlighted - if that happens, we need to be very very effective in communicating correctly because it’s already hard enough to make people understand the importance of this kind of technical excellence.

I really wanted to find something that justified that outcome, and at first I was also disappointed that the research never discuss the point directly - but then, I thought: “there must be a reason”.

I mean, is not that I want to justify something just because it’s coherent to my beliefs, but the entire research over the years is based on questioning our beliefs and understand their impact in a transparent way - I really couldn’t believe that they wouldn’t be transparent about that.

Luckily, I was right - even if it’s not addressed directly (they never say “TBD seems to lead to an increase in burnout, but…”) it is definitely addressed in the considerations an thoughts about the overall outcomes.

The main point, which is both my initial thought and also what they highlight multiple times in the report, is that even if they treat the technical capabilities separated for research purposes, they should always be seen as strictly correlated: if you think about it, 4 out of 5 technical capabilities examined (AI excluded) are needed to enable Continuous Deployment.

Quoting Dave Farley, page 24 of the report:

CD—the ability to release changes of all kinds on demand quickly, safely, and sustainably—is a substantial mediator of many technical capabilities.

[…]

The practice of CD, in turn, provides the mechanism through which these capabilities can predict stronger software delivery performance.

[…]

For example, how can we achieve high scores on Throughput if our code doesn’t integrate, and how can we be sure that our Stability is high if we haven’t checked it? For me, CI is how we know these things, and so it’s a key mediator of software delivery performance.

Look at the tables from the report:

Impact of the 5 technical capabilities on performance:

Impact of the 5 technical capabilities on people well being:

There are some points we can agree on:

72% of the impact is positive (4 decreases and 6 no effects on a total of 35)
Except for AI, the other 4 capabilities are strictly related to each other
Except for AI, the other 4 capabilities are together enabling even more technical capabilities and practices

I will use an example to express my feelings about all this: we can say that the impact on burnout of the 4 capabilities is a substantial decrease (no effect + substantial decrease + substantial decrease + substantial increase), and the 2 capabilities impacting positively are a faster code review speed and a loosely coupled architecture.

The things is: how do you increase code review speed? With TBD, because you reduce the batch work size, meaning the size of the review, making it easier and faster to both find a time span to perform the review, and also to do the review itself: if every team member creates daily (or shorter) PRs, they will more easily find the time for performing the review without too many interrupts, and review itself will be faster.

At the same time, it’s almost impossibile to achieve CI if we don’t have loosely-coupled teams, splitted by domains and without depending to each other for PRs and releases - and this open the chances to achieve a loosely-coupled architecture too.

As you can see, it’s all connected, so here is my final thought: we cannot just think to this results looking at the specific item, same as we cannot think about team performance by looking at the performances of a single developer - we need to think about the whole system, and in this case the whole research, the entire group of practices considered and their impact with each other.

But, I think we also need to face this in a correct way, and it looks that me and Dave agree also on this (see quote below): this is, in any case, an interesting and intriguing thing to keep a look at, and we will probably discover more in the next year State of DevOps Report!

I mean: we always keep “uncovering better ways of developing software”, right? 😉

Is this a problem of interpretation or something deeper and more important? Intriguing!

Go Deeper 🔎

📚 Books

Accelerate - How can we apply technology to drive business value? This book is the first production of the research that is now yearly updates with the State of DevOps Report.
Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation - This groundbreaking new book sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users.