Branching is Killing Your Delivery – Try Trunk-Based Development
We’ve seen many Agile and Scrum teams struggle with complex branching strategies, often leading to bottlenecks in delivery. With a strong technical background, we’ve helped teams simplify their workflows, improve automation, and adopt practices that enable fast feedback and higher-quality engineering.
A recurring challenge we’ve encountered is the reliance on complex branching strategies – not because they are the best choice, but because they mask deeper issues in automation, feedback loops, and quality engineering practices.
In many cases, these branching strategies contribute to hidden technical debt, slowing teams down over time. Instead of enabling agility, they create friction, making even small changes risky and time-consuming. Teams unaware of this growing debt often struggle with slow releases, frequent production issues, and brittle systems. Here’s how technical debt silently threatens agility.
While Trunk-Based Development (TBD) is the preferred approach for high-performing teams, there are cases where GitFlow or other strategies make sense – particularly in open-source projects where maintainers need stricter control over contributions. However, many teams default to feature branching or pull request-heavy workflows as a workaround for missing technical excellence rather than addressing the root cause.
The Pitfalls of Complex Branching Strategies
Branching is often seen as a safeguard, but long-lived branches introduce several problems:
- Merge Conflicts Waste Time – The longer a branch exists, the more painful merging becomes.
- Delayed Feedback Leads to Defects – Isolated development prevents teams from catching issues early.
- Code Becomes Harder to Change – Working in silos makes integration and refactoring challenging.
- Release Coordination Becomes a Nightmare – Managing multiple branches creates overhead and delays.
- Cycle Times Increase – Work sits in branches instead of being continuously integrated and tested.
Trunk-Based Development (TBD): A More Efficient Approach
Trunk-Based Development (TBD) eliminates the bottlenecks of long-lived branches by encouraging frequent integration into the main branch. Instead of managing multiple feature branches, developers work in small increments, committing directly to the trunk (main branch) or using short-lived feature branches that merge quickly.
Key Benefits of TBD
- Faster Feedback – Immediate integration surfaces issues early.
- Fewer Merge Conflicts – Small, frequent commits reduce complexity.
- Higher Stability – Continuous integration ensures the code is always deployable.
- Simpler Release Management – No need for complex merges before shipping.
- Encourages Clean, Modular Design – Forces teams to keep code loosely coupled and testable.
Real-World Example: Eliminating Branching to Unlock Agility
We’ve helped many teams transition away from complex branching strategies like GitFlow, which often mask immaturity in Continuous Integration (CI) and DevOps practices.
One team we worked with believed they were “doing Scrum” for three years. But when we asked, “Which environment are you deploying to at the end of the Sprint?”, they had no answer. Their process involved a testing Sprint after development, with teams unpicking code when they wanted to release.
The root cause? A complicated branching strategy that allowed them to manage multiple things in flight. This made even small changes difficult to merge, delayed feedback, and created fear around releasing. Their release was a big event, requiring coordination and heavy preparation.
Meanwhile, a neighbouring team in the same department with the same tech stack but a slightly different product had a 15-minute deployment cycle to a production-ready environment. We had been coaching this team for two years, helping them adopt a single trunk-based product with three teams working on the same codebase. Their releases were an activity, not an event – something they could do multiple times a day with confidence.
Another common branching strategy we often encourage teams to move away from is feature branching, especially when paired with pull request workflows. While short-lived feature branches may seem harmless, they often introduce slow feedback loops, excessive gatekeeping, and delays in integration. Most teams we’ve worked with that transition to Trunk-Based Development tend not to use feature branching at all because they simply don’t need it.
Our solution was to eliminate long-lived branches and adopt Trunk-Based Development. But this wasn’t just about removing branches – it required:
- Fixing separation of concerns and SOLID violations. The system needed proper modularization and APIs that delivered real business value, not just CRUD operations.
- Investing in CI/CD pipelines. Their pipeline was constantly red or ignored by the team. We made it a first-class citizen.
- Improving feedback loops. Teams needed fast, local feedback before remote check-ins. We reinforced green CI builds as a priority and encouraged a mindset shift toward continuous improvement.
- Encouraging Pair and Mob Programming. Instead of relying on code reviews after development, teams benefit from working together in real time. This increases knowledge sharing, reduces the need for long-lived branches, and fosters a collaborative engineering culture.
These practices form the foundation of technical excellence – the key to high-performance engineering teams. Strong automation, modular code, and clean architectural patterns don’t just enable TBD; they remove the friction that makes feature branching feel necessary.
We cover these essential skills in our Technical Excellence Training, helping teams improve code quality, reduce waste, and accelerate delivery.
GitFlow: Why It’s Not Ideal for Most Teams
GitFlow introduces unnecessary complexity for teams practicing Continuous Integration and Continuous Delivery (CI/CD).
When GitFlow Works Best
- Open-source projects – Suited for teams with multiple contributors.
- Strict gatekeeping requirements – Helps manage external contributions.
- Limited automation – Works for organizations relying on manual approval processes.
Why Trunk-Based Development Excels
- Enables business agility – Frequent integration allows teams to adapt quickly and deploy value faster.
- Reduces deployment risk – Smaller, frequent releases minimize the chances of large-scale failures.
- Improves engineering culture – Encourages collaboration, clean architecture, and automation over manual gatekeeping.
- Accelerates time to market – Eliminates delays caused by merge conflicts and lengthy approval processes.
- Scales DevOps effectively – Supports fast feedback loops and Continuous Integration, making it easier for teams to grow while maintaining high quality.
How to Transition to Trunk-Based Development
Shifting from GitFlow or feature branching to TBD isn’t just about merging faster – it requires investing in key technical practices:
1. Feature Toggles (Feature Flags)
- Allows teams to commit incomplete work without exposing it to users.
- Reduces the need for long-lived branches by enabling controlled rollouts.
2. Continuous Integration (CI) and Automated Testing
- Every commit should trigger automated tests to ensure system stability.
- Without strong test automation, TBD becomes risky.
3. Pair Programming & Mob Programming
- Encourages real-time feedback instead of relying on delayed code reviews.
- Eliminates the need for developers to work in isolation on long-lived branches.
4. Deploying in Small Batches
- Small, incremental deployments reduce risk and improve stability.
- Large releases introduce complexity and increase failure chances.
5. Modern Architecture for Deployment in Isolation
- Clean architecture and well-defined service boundaries enable independent deployment.
- Avoids the pitfalls of poorly implemented microservices that fail to align with real business problems.
Capturing the 3 Ways of DevOps
The shift to TBD aligns with The Three Ways of DevOps, emphasizing:
- Flow (Fast, Continuous Delivery) – Reduce wait times and move small changes quickly through the pipeline.
- Feedback (Rapid Iteration) – Shorten feedback loops to catch and resolve issues early.
- Learning (Continuous Improvement) – Embrace experimentation, measure performance, and evolve practices over time.
By following these principles, teams can increase velocity, reduce risk, and improve product quality.
The Future is Trunk-Based
GitFlow had its place before modern DevOps practices, but today, Trunk-Based Development (TBD) aligns with high-performing teams that prioritize speed, automation, and rapid feedback.
- Eliminates delays – No more long-lived branches, merge conflicts, or release bottlenecks.
- Enables Continuous Delivery – Seamless integration, automated testing, and rapid iteration.
- Drives Business Agility – Helps teams adapt quickly to market changes.
- Powers high-performing teams – The standard for organizations focused on innovation and speed.
That said, there’s no one-size-fits-all approach. If your team isn’t ready for TBD, start by investing in automation, testing, and feature flags to ease the transition.
As Jez Humble said: “If it hurts, do it more often.”
The best teams don’t manage branches – they continuously deliver value.
Next Steps: Move Toward Continuous Value Delivery
If your team struggles with slow feedback loops, painful merges, or complicated release processes, Trunk-Based Development is the path forward.
🚀 Want to avoid the hidden costs of technical debt? Read how technical debt slows teams down.
🚀 Looking to improve technical practices and engineering culture? Check out our Technical Excellence Training.