Trunk-Based Development Doesn't Work for Slow Teams
Iterative vs. Batched Delivery
TBD is great for a team that wants to move fast. Arguably the only way to move really fast.
From a strategic perspective it's not whether TBD is good or bad.
It's undoubtedly universally beneficial.
The pushbacks are usually mindset limitations of teams that don't have an incentive to go faster than they currently are - even though they might not be getting much done by their own account.
Batching
Some teams are optimised to run at their slow, batched pace. This kind of team will slow down when encouraged to speed up as they are rigidly tied to hand-off and hand-back rituals for moving this forward.
In short: Waterfall.
There are often organisational pressures combined with a lack of experience within the team encouraging that kind of process. Once a feature goes beyond its initial estimated scope, batched teams often abandon procedure and try to wing it to get back on track.
Such an attitude forces these teams to work every day with a mental handicap.
The root cause is generally a lack of iterative, feedback-focused thinking organisation-wide.
The strategic root stems from the higher organisation, while the tactics remain a problem to be solved by the engineers.
The manager is generally powerless here in my experience.
A team that does follow TBD is often vertically integrated to receive and pass on tangible feedback.
This perceived progress by the higher-ups encourages more collaboration while also demanding more discipline compared to a team doing git flow or long-lived feature branches cowboy style.
Common Example: A Story Feature
Here is the perspective of a batched team:
This feature is 3 days of work, I'll do it on a branch to not break anything, verify it doesn't break anything when I'm done then I'll integrate and deploy."
And here a team that follows TBD:
This feature is likely 3 days of work, I'll make sure every few hours of my work are deployable so that when it's done I don't waste time integration.
Did you manage to spot the differences?
They seem like small, silly details. From my work with hundreds of engineers and teams I found that the high-performing ones focus on small details done well and consistently.
Default, batch-mode teams often avoid the annoying bits, like eating the frog, pair programming, story slicing to 3-4 hour sizes, event modeling or TDD.
It Comes Down to Cognitive Stress and Fear
The iterative team is confident enough to merge things without breaking the main branch.
That is a downstream consequence of the technical discipline to remove friction (ie. technical debt) regularly by tidying as they work. The managers who hire me as a coach for themselves and trainer for the team generally aim to get this confidence back to the team.
TBD helps avoid slow, asynchronous Pull Requests (PRs). Once a team is there, you can reintroduce asynchronous fast PRs. But that transition period sucks.
The tactics of TBD are to keep the todo list of uncommited changes kanban-style and very short, ie.
you have "40 uncommitted lines of code".
at a certain peak you need to deploy before you can continue working
TBD aims to keep that short and fast. But a team that produces 2000 lines of code slowly within a week who then wants to merge it has no business doing TBD without splitting their work first.
This can be daunting for engineers as they don't know what to do when work drags on.
Once stuck in this loop, they default to batch-working, which creates the need for unplanned extra work at the end of the integration cycle.
And that's without extensive hand-backs caused by PR feedback or merge conflicts.
What Nurtures Productivity?
This post was inspired by a combination of things. A recent LinkedIn conversation I had, common questions arising in my coaching sessions working with tech teams and the recent white paper on DevEx: What Actually Drives Productivity.
The latter I recommend you check out in further detail if you want to learn more. I’m sure it will be circling around tech social media frequently in the next few weeks.