Lessons Learned in Dual Track Agile
The Ups and Downs in Transitioning to Dual Track Agile.
How it all started and what was the result
Imagine a team that zips towards its goals with laser focus — every engineering manager’s fantasy, right? In fact, it’s what everyone on the team secretly yearns for. But let’s face it: maintaining that unwavering focus, operating at peak efficiency, and always knowing the next move? It’s virtually unattainable. Yet, aiming for this gold standard of excellence is not just aspirational, it’s essential.
In our team, the journey towards our goals was like navigating through fog. Clarity on progress and accurately gauging our distance from the finish line seemed like a constant challenge. Take our user stories, for example. A big chunk of them required exploratory steps, like discovery activities, to truly grasp what needed to be done. This phase often involves proof-of-concepts, a journey into the unknown where you might end up hitting a dead end and starting over.
Then there’s the age-old battle of spending time on technical debt, often sparking the classic business-versus-engineering debate. Such tasks might not seem directly linked to our immediate goals, yet they’re crucial. Neglecting them could spell trouble down the road. It’s like trying to build a skyscraper with a shaky foundation.
In summary, the drivers we had to implement Dual Track Agile:
- Missing well-refined stories ready for execution
- Difficult to assess our progess towards the goals
- Lack of focus on delivery due to many unknowns and/or accompaying tasks (e.g. maintenance)
The result? Our sprint velocity increased on average by 12% after implementing the Dual Track Agile. Hower, first things first.
What is Dual Track Agile and how to do it
Driven by the need to streamline our delivery, we decided to try out a methodology called Dual Track Agile. In my view, the Dual Track Agile is best described in this post by Marty Cagan as:
“The Discovery track is all about quickly generating validated product backlog items, and the Delivery track is all about generating releasable software.”
In practice, this means that you divide your work into two streams:
- Delivery — focus on having well-refined user stories that require minimal research and are basically ready to be developed and shipped i.e. feature development
- Discovery — contains all the user stories that typically require research, experimentation and maintenance or are perhaps not directly linked to your delivery goals (e.g. proof of concepts, architectural designs, maintenance, bug fixing, refactoring)
Our team is organized around scrum with a 2-week sprint cycle. The change to dual track agile was demonstrated by dividing our task board into two separate boards where the first, the delivery board, continued in scrum and the second, the discovery board, adopted a kanban style to better suit its continuous flow of tasks.
Here’s where it gets interesting: at the end of every sprint, there’s a dynamic shuffle. One of the two developers from the discovery stream joins the delivery team, and in a seamless swap, a member from the delivery side steps into the discovery stream. This ensures a fresh pair of eyes and ideas in both streams, maintaining a balance with always two developers delving into the discovery phase at any given time.
To strike the perfect balance between discovery and delivery, we’ve adopted a 30:70 ratio. This means that 30% of our team is dedicated to the Discovery track, while a solid 70% focuses on Delivery. Why this split? Simple: our main goal is delivery. But we recognize that discovery is a crucial enabler for this process. The work is depicted on the following schema:
Based on this separation of work streams and enabling clear focus, the majority of the team should be able to drive the progress fast towards the objectives as the uncertainties, unknowns and maintenance is cleared out of the way by the team members allocated to the discovery work stream.
What feedback we collected
We took a data driven approach to our change and started to collect feedback and data early on. Generally, the change was well received by the team and easy to implement. The following is an extract from one of our Sprint Retrospectives:
However, this approach wasn’t without its challenges. Over time, we faced a few stumbling blocks:
- Isolation in Discovery: Developers assigned to the discovery stream began to feel detached from the rest of the team.
- Duration Dilemmas: Some developers expressed that their stint in the discovery stream felt a bit too lengthy.
- Maintenance Overload: We noticed a trend where maintenance and bug fixing started to overshadow actual research, refactoring, and design in the discovery stream. This shift was like having a team of explorers spending more time fixing their ship than sailing new seas.
- Doubts About Knowledge Sharing: There was uncertainty among team members about the effectiveness of switching only one person between discovery and delivery at a time. Meaning, if it creates more complexity rather than ensuring continuous knowledge sharing.
Success or not really?
Recognizing these challenges, we knew it was essential to sharpen our focus on objectives and accelerate our progress. To gauge whether implementing Dual Track Agile was truly beneficial, we decided to measure its impact quantitatively. Our team uses story points for estimation, so these became the key metric for assessing progress.
We compared the number of story points completed in the three months before and after the implementation of Dual Track Agile. This comparison was like taking a ‘before and after’ snapshot of our productivity.
This resulted in our sprint velocity to increase on average by 12%.
While our story point analysis was a solid starting point, we quickly realized that relying solely on this metric could be misleading. There are numerous external factors that could skew the data, and it’s crucial to consider these outliers:
- Bug Surges: An unusual increase in bugs, which aren’t typically assigned story points, can affect productivity measures.
- Shifting Priorities: Significant changes in what’s deemed important can redirect team efforts and impact story point completion.
- CI/CD Pipeline Hiccups: Issues with Continuous Integration/Continuous Deployment pipelines that prevent smooth deployment can lead to delays.
- Stakeholder and Dependency Challenges: Problems with stakeholders or other dependencies can disrupt the workflow.
All these factors share a common trait: they’re tricky to quantify in the final calculation, especially when success is gauged by completed story points. It’s like trying to measure the speed of a car without considering road conditions or traffic.
There’s no one-size-fits-all solution to this challenge. The key lies in using your best judgement to assess the extent to which these outliers might have influenced the results. For instance, if there was a bug spike before implementing dual track agile, this could mean that the observed 12% increase in average sprint velocity doesn’t fully represent the method’s impact. It’s about reading between the lines of data to get a true picture of progress and efficiency.
What did we learn and what actions did we take
First and foremost, this methodology can indeed be a powerful tool, but it must be tailored to fit the unique needs of the team. Otherwise, it risks becoming more of a procedural burden than a benefit. To ensure its effectiveness, we integrated it into our retrospectives, creating a feedback loop after each process change to keep our approach dynamic and responsive.
We also acknowledged the concern that the time spent in the discovery stream sometimes felt too lengthy, and the transition between streams could be challenging. Therefore, we shortened the duration in the discovery to 2 weeks and both developers change to delivery instead of just one.
Most importantly, we learned that many developers relished their time in the discovery stream, especially when engaging in architectural design, proof-of-concept projects, and other experimental tasks. This enthusiasm highlighted a significant advantage of Dual Track Agile: when implemented effectively, it opens up opportunities for focused experimentation and innovation.
