Dual Track Scrum

The aim of this post is to give readers a flavour of how I implemented Dual-Track Scrum in a previous workplace. There has been much hype about Dual-Track Scrum, but not much about how it has been put into practice. I hope this post gives you some idea of how the concepts can be applied in your place of work.

What is Dual-Track Scrum?

This is a framework in which a product development team is continuously discovering what their customers needs are, and validating those needs using evidence and prototypes. Once an idea or need is validated, the need is then represented in the form of user stories and added into the product backlog.

Dual-Track Scrum advocates that the product owner/manager, the lead developer, and the UX/UI person constantly spend their time in the discovery space, while the rest of the team concentrates their efforts in delivery. So, in a nutshell, there are two tracks, each with a different focus but with one aim: to build products customers will love. Sounds good in theory, but it can be hard to find the right balance in practice.

I think it’s important to note that the driver for wanting to adopt Dual-Track Scrum came from the product team. This is the way they wanted to work, and I and the other delivery managers helped the product team bring this change into the company. It’s also important to note that everyone, from the exec level right through to people in marketing, knew that this was how we were going to work. It was important that they understood our process and also knew where they fit into that process. This is where ScrumMasters, delivery managers, and Agile professionals, who work with teams and stakeholders, can really help.

One thing I was very skeptical about when I first read about Dual-Track Scrum was how it advocates mastery, autonomy, and purpose, if the lead developer is always in discovery. Did that mean that everyone else who sits within the delivery track just becomes a user-story consumer and has very little say in how they would perceive a feature to be developed?

What did we do?

We agreed that we wanted people from delivery to be able to rotate freely into discovery. Our tech stack was complex; we had a lot more specialists on the team than generalists, technically, so it made sense for us to rotate people in.

We decided that there would be two backlogs. The discovery backlog contained items that were hypotheses, which would need to be validated to work out whether something should then go into the delivery track to be worked on by those in delivery. The way in which we validated hypotheses included doing things like AB testing, looking at data, talking to customers directly, and story mapping. The delivery track still had its own product backlog; once hypotheses were validated, a user story or stories were created in the delivery backlog, with a link to the discovery backlog item, so that we could link stories back to their origin. It was important that we did that because, once a feature was worked on in delivery and released, we would then revisit the discovery backlog item to further validate whether we had solved the problem we had identified initially. This was very important, as just discovering a problem and pushing user stories into delivery isn’t the end. We need to be constantly discovering, even on items that had started in discovery and been pushed out to delivery.

A Scrum team’s main goal is to satisfy a customer’s need. We found that with just our usual Scrum release cycles, the time from identifying an idea to actually releasing a fix for it would amount to a minimum of six weeks. Dual-Track Scrum gave us a different way of looking at our product development process, where we now had dedicated people in discovery. We didn’t want there to be silos created throughout the development team, so one way of bringing people in discovery and delivery together was through the refinement sessions. We wanted to be able to get feedback from the delivery team when we felt that hypotheses in discovery were validated, and we didn’t want to wait around for six weeks before we could get our validated hypotheses to delivery. We all agreed then that in order to get user stories properly fleshed out, we would have 30-minute refinement sessions every day, straight after the stand-up. Then from 11 a.m. on the delivery team was left alone to work on delivery.

One point to note here is that we had three of each skill set within the team, which allowed us to rotate people in from delivery to discovery. We had our usual delivery stand-up, and everyone attended that (including people in discovery). We noticed that because we validated our hypotheses and refined stories well with the team in delivery, the delivery team didn’t need much input from the PO or UI/UX people. We also held discovery stand-ups and encouraged those in delivery to come hear what was being discussed.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s