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

In 2023 State of DevOps Report, an increase of burnout is related to Trunk-Based Development: is the first time, one of those practices shows a concrete negative effect, let’s reflect on the report!

A programmer facing burnout and screaming

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!

Some key insights from the report

The article from the DORA team highlights 5 key insights:

1. A healthy culture matters: teams with generative cultures have 30% higher organizational performance
2. User in mind: teams that focus on the user have 40% higher organizational performance
3. Documentation has an impact: high-quality documentation leads to 25% higher team performance
4. Work distribution is not fair: women and underrepresented people have higher levels of burnout
5. 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! 🤓👩‍💻👨‍💻

🙏 Thank you for reading this shortened version of the article: to read the full version, visit my blog here.