April 17, 2025
In Chapter 4: Tracking What Matters – KPIs and Dashboards, we explored how visualizing workflow and defining the right KPIs helped us spot bottlenecks and align our teams around value delivery. With better visibility into our DevOps pipeline, we began to ask deeper questions-not just where the bottlenecks were, but why they were happening.
In Chapter 5, we dive into one of the most significant technical and process-level shifts in our transformation journey: refining our branching strategy and enabling continuous deployment. These changes were pivotal in resolving persistent delays between development and production.
Identifying the New Bottleneck
Analyzing the flow of work and identifying bottlenecks where work is piling up has been a key aspect of achieving our DevOps transformation. This focus on flow is at the heart of how we applied the DevOps triangle-tools, architecture, and people-towards achieving faster, more reliable delivery.
As we made progress in improving testability with increasing unit test and test automation coverage, we found that code quality was improving, but the bottleneck was still in the scrum testing phase. Despite progress in test automation, work was still piling up, and the bottleneck moved from development to system-level testing. Key performance indicators (KPIs) showed that the work-in-progress per team during development was decreasing, but code was still getting stuck at the transition point into system testing. This delay ultimately prevented us from achieving a smooth flow.
The Root Cause: Branching Strategy and Delayed Merges
Analysis revealed that the root cause of the backlog lay in our branching strategy. Developers and testers were creating feature branches from the main branch when starting new features. As the code developed, engineers pushed their changes to remote feature branches to merge their work with others. However, this code was not being merged back into the main branch frequently enough.
The CI/CD pipelines were set up on the main branch, running automated tests and deploying to the cloud, followed by regression testing. However, since the latest changes weren’t being pushed to the main branch regularly, the pipeline executions were running on outdated code, making them redundant and ineffective.
The Fix: Short-Lived Feature Branches
To resolve this, we realized that fine-tuning the branching strategy was necessary. While there are pros and cons to different branching strategies, we decided to continue with the feature branch strategy, but with a key adjustment: short-lived feature branches that get merged back to the main branch more frequently.
The short-lived feature branch strategy offers several advantages, with the most critical benefit being improved flow and addressing the bottlenecks in the development cycle. Shorter-lived branches ensure that code merges are easier, faster, and less error-prone. This approach also enables faster feedback, which improves the overall quality and velocity of the development process.
Continuous Deployment: The Pipeline Challenge
Setting up robust continuous deployment pipelines is a complex task that requires a focused, incremental approach. In our experience, having a dedicated platform team to set up and maintain these pipelines is the recommended approach, rather than having each scrum team work on them individually. While the eventual ownership of continuous delivery pipelines must lie with the scrum teams, the initial task of setting them up greatly benefits from a dedicated platform team.
Platform Team: Reducing Cognitive Load and Enabling Focus
For inspiration in structuring our platform team, we turned to Team Topologies by Matthew Skelton and Manuel Pais. The book emphasizes the importance of having a dedicated platform team that is responsible for setting up and managing the infrastructure-in our case, the CD pipelines. This structure allows the scrum teams to focus on feature development, while benefiting from a stable and standardized pipeline setup.
As the book states:
“The platform team is responsible for building and maintaining the internal platform that stream-aligned teams use to deliver their work. The platform’s purpose is to reduce cognitive load for stream-aligned teams, so they can focus on delivering value.”
By centralizing the responsibility for the pipelines, we were able to create a shared, common platform that stream-aligned teams could depend on. This allowed us to reduce cognitive load on the development teams, enabling them to focus on delivering value rather than dealing with infrastructure concerns.
Evolving the Platform for Continuous Improvement
Having a platform team is not just about setting up the pipelines; it’s about evolving the shared infrastructure and tools over time. A dedicated platform team is in the best position to make incremental improvements to the continuous delivery pipeline, ensuring it stays aligned with the teams’ needs and adapts as we scale and grow. This ongoing evolution ensures that the platform remains reliable, scalable, and efficient-empowering our teams to work at their best.
Up Next: Automation and Feedback
With branching streamlined and deployments flowing, we turn to the final frontier in our DevOps journey: Automation and Feedback. In the next and final chapter, we’ll explore how closing the loop with automated insights and fast feedback transformed how our teams operate.
Stay tuned!
Category: