Why We’re Going Dual Track Agile
Building the right things, and building them right.
This post was co-authored by Morten Christoffersen & Martin Kristensen, while working at DR — the Danish Broadcasting Corporation.
DR — the Danish Broadcasting Corporation — is Denmarks largest public service media organisation covering both broadcast and on-demand TV, radio and digital content (a Danish equivalent to the BBC, if you will). DR employs more than 2500 people spread across various organisational functions and roles.
One such area is digital platforms and product development, an area that’s been on a massive organisational journey over the course of the last few years; transitioning from a classic delivery organisation to a true, cross-functional product organisation. This journey will form the essence of this blog post (and many more to follow), where we will share our insights into how we work, and the challenges we face.
The Difficulties of Marrying Discovery and Delivery
No matter how you approach it, creating digital products involves two kinds of work: discovering the right thing to build (Discovery), and building it right (Delivery). Much has been said and written about both these activities, yet many product teams still struggle to marry the two in a coherent process.
Like many companies over the years, we at DR have adopted Scrum as our main delivery model for building digital products. And it serves us well — the Agile methodology has improved product delivery focus; removing obstacles, increasing development velocity, and decreasing time to ship. However, while these practices have quickly matured what good product delivery looks like, product discovery hasn’t evolved at quite the same cadence — both for us at DR and, it seems, for many product teams in general. This gives rise to a series of potential issues that can detract from designing and building the best possible products.
The Discovery-Before-Delivery Fallacy (or Water-Scrum-Fall)
One such issue is detaching discovery from the Scrum process altogether. Traditionally, product discovery has often been treated as a time-boxed activity that occurs before the “real” development work begins. The focus has been on gathering ideas and requirements from stakeholders, securing funding for the project, and planning delivery efforts in detailed roadmaps.
While these activities aren’t necessarily bad (on the contrary, they can actually be important discovery activities too), this way of approaching discovery has a serious caveat: It promotes a largely project-centric way of looking at the world, that assumes we can predict the future; that our initial assumptions about the world are true (and will remain true for the duration of the delivery part of the project). On the positive side it gives an overview of deliveries needed by C-level, clients and other interested parties—but the problem is that in product development this is often, at best, guess work. DR is in this respect not different to any other part of the world.
Furthermore, treating discovery as something that happens before Scrum begins obviously goes against the core principles of Agile, and reduces our methodology to a Water-Scrum-Fall hybrid. As a modern product team, we want our products to be alive; there’s always a next phase, a new improvement, a new experiment, because we know that we never get it right the first time, and we know that we’re never “done”. Agile helps us embrace this by continually allowing us to adjust our focus, our work and backlog — and it’s essential that Discovery is embedded in this proces, not detached from it.
The Discovery-Within-Delivery Fallacy (or “Feeding the Beast”)
However, as many product teams can probably attest to, embedding product discovery activities within the traditional Scrum methodology has it’s own set of challenges. These challenges often revolve around getting UX and Product Designers to work fluently with their Developer counterparts. When UX and Product Designers are producing detailed UI and specs on features that are already validated, it usually is possible to integrate them in to the same sprints as the rest of the teams— because these activities are inherently delivery work! However, when it comes time to perform discovery activities (researching user behaviour, validating ideas through experiments, performing UX tests and optimisations), it gets tricky to do it within a single track of sprints.
Often UX and Product Owners get caught in a Sisyphean cycle of “feeding the beast” when working in Scrum. When they are placed into the same (delivery) track as the development team, it means they will be at the mercy of the delivery roadmap, and will always have to try to stay +1 sprint ahead of the ever-hungry “sprint monster”, by quickly designing out whatever features is coming up for development next in the backlog.
This is problematic for a number of reasons, but most of all because it’s a fixed game that at best involves a form of “pseudo” validation of the backlog items. If the UX designers don’t “validate” and design the features in time for the next sprint, the whole machinery potentially grinds to a halt, leaving the developers with nothing to develop, wasting valuable time and money. That means no real room for failed experiments or working on tasks that could potentially help redefine our product.
Creating Room For Failure
Dual Track Scrum is an attempt to addresses these challenges. It supports the delivery practices of Agile by promoting product discovery to a continuous and ongoing activity in its own right, thus resulting in “dual” tracks:
There seems to be some debate about the actual origins of the “Dual Track” lingo, however the process has largely been popularized and refined by Marty Cagan and Jeff Patton. The Dual Track methodology recognizes that discovery is a necessary part of product development, and as such should be practiced with the same Agile and Lean principles in mind. As a result, it creates two tracks that augment and play off each other:
The Discovery track is all about quickly generating validated product backlog items, and the Delivery track is all about generating releasable software.
— Marty Cagan, ”Dual Track Agile” (https://svpg.com/dual-track-agile/)
Scrum on its own is a bit lopsided towards Delivery. It is very focused on development velocity; it’s about predictably shipping high quality code. Discovery on the other hand is about learning velocity; it’s about finding the right problems to solve or opportunities to address—and validating potential solutions, before we start building them. Which incidentally is also at the heart of how we at DR want to build products.
By formalizing the idea that discovery tasks do not necessarily have to lead to a development task, we create room for failure. We want to be able to work with experiments that simply prove that a given hypothesis was wrong, extract the potential learnings from it, and move onto our next experiment. Obviously some of our discovery activities will (and should) lead to items in the development backlog — but the point is that discovery is no longer a slave of the delivery roadmap, but a partner to it. It’s important however to note that these are two tracks, and not two teams. Both discovery and delivery work should be handled by the same, unified, cross-functional team.
The Practicalities of Dual Track at DR
Currently, we’re working on a number of initiatives at DR to adjust our proces to the Dual Track way of thinking and working. As with any adjustment to proces, it’s not easy — and we’re approaching the whole thing as an experiment in and of itself, in order to find the best solution for our product teams and culture.
A few of the current activities going on include:
- Discovery (or delivery, for that matter) does not work without a clear product vision, goals and KPI’s guiding out product strategy and decisions. In order to visualize this for each team, we are working on a consistent way of creating product dashboards that will form an essential canvas for product discovery.
- Before adopting Dual Track, not every team had dedicated UX resources (we had more an an “internal agency” model). We are now working on dedicating UX resources to each of the product teams, in order to create fully cross-functional teams that can handle everything across the discovery and delivery tracks.
- Discovery is not only a UX discipline — we are working hard on underlining that product discovery also is a technical discipline where can mitigate risk and ensure early technical POC.
- We are experimenting with separate kanban boards for each team, so that the team has a board for discovery and a board for delivery in Jira. This will give both Product Owners and Scrum Masters one unified way to manage activities across the dual tracks while also allowing for a certain level of transparency.
What next?
The focus on this post has been to introduce you to Dual Track Agile, the impact it has on product discovery, and the transition that we are undergoing here at DR. In future posts, we will dive deeper into the details and questions that underlie this transition
- How we define product visions and KPI’s as a public service company
- The UX activities that go on in Product Discovery,
- The role of the PO in a Dual Track proces
— and much, much more. Stay tuned!
