Transitioning to Trunk-Based Development

I understand that many teams might find moving to trunk-based development challenging due to a number of reasons (environmental and cultural factors included).

It can feel like too big a shift from long-lived branches and traditional post-development code reviews. However, it does not need to happen all at once. In fact, it should be treated as an agile project: the key is to adapt gradually, breaking the process into small, manageable steps and refining it over time.

As a general guideline, the agile roadmap could be split into a few major milestones:

1. Reduce branch lifespan: If your team currently works with long-lived branches, start by shortening their lifespan to a maximum of 1-2 days. This enables continuous integration and reduces merge conflicts.

2. Embrace social programming (team-focused development): Work collaboratively in pairs, quartets, or mobs so that most code review happens during development. This allows the final review to either be removed entirely or reduced to a quick pre-merge check.

3. Shorten branch life further and remove them if possible: With a reliable local commit and acceptance-phase testing strategy, reduce branch lifespan even further, ideally to just a few hours, with the goal of removing them entirely. This brings the team even closer to continuous integration.

4. Adopt test-driven development: This increases confidence in frequent commits and eliminates the need for lengthy review cycles. A pair or quartet should be able to commit and push small, fully-tested change sets at the end of every red-green-refactor cycle, ideally every few minutes.

5. Improve knowledge sharing and ownership: For teams used to working in fixed pairs or independently, introducing rotating pairs or quartets may feel like a significant shift, but it is highly beneficial for TBD. It enhances knowledge sharing, reduces dependencies, and improves code quality before it reaches the trunk.

Start with voluntary rotations, allowing engineers to switch partners at natural points, such as the start of a new feature. Then establish a regular cadence, aiming for pair rotations at least once a day or after major commits.

Expand to quartets, where two pairs collaborate, further strengthening knowledge-sharing and enabling collective ownership.

Each of these steps above can be implemented as agile iterations. At regular intervals, the team can reflect and adjust. Every successive step can inform the previous, and step 5 can continuously cycle back to step 1 to further refine the process (Kaizen!)

The idea is that small and short is always good (at least in software!).

Orignally posted on LinkedIn.