Introducing Dual Track Agile

Last July I had the chance to follow a 2 days training called “How to Create Products Customers Love” held by the Silicon Valley Product Group. The workshop was really intense and information-rich, with a lot of useful suggestions for our product team and our product development process. In this post, I’ll try to give a recap of the points that I consider the most important ones. In the meantime, I have been trying to put the teachings into practice in my team, so I promise to write a new post about my personal experience soon.

1. Product development should be guided by OKR

Products should have a vision, and the vision should be declined into short-term objectives. Based on the objectives, you as a product manager should define which metrics will tell if you have achieved an objective or not. These metrics are called key results (O=objective, KR=key results). What is fundamental is all the team must be aligned with the OKR and everybody must be committed to reaching them.

If you want to know more about OKR I suggest the book Radical Focus by Christina Wodtke.

2. Launching features that don’t solve problems, it’s not useful

Regardless if you want to launch small or big features or even new products, you must know exactly why you are doing it. So everything you do should have the goal of improving a key result. If you don’t know which metric you are going to improve with that feature, you should not even start developing it.

3. Nobody has the answers

Making products is not like solving equations. Let’s say you have identified the problem and you want to develop something to solve it. The thing is nobody can possibly know what will be the correct solution. The first guess is often not the best one. Previous experiences, your skills, gut, etc, can be useful, but you won’t know that your solution works until you really release it and test it.

4. Many quick iterations

Imagine that you need 6 tests before reaching the correct solution (in reality it could be much more than this). If it takes 1 month to release something and make a test, you will need 6 months to find the correct solution. You cannot afford this. You need to make a many more tests in a shorter time. The faster you are, the faster you will find the correct solution.

Of course, creating a full-featured product or feature takes time, it cannot be done in a few days. So it’s fundamental to create prototypes and MVPs until the idea is validated. This is the base of all lean approaches.

5. Scrum sometimes can be an obstacle

Scrum divides the process into sprints, normally of 2 weeks (sometimes more) and before you start a sprint you need a planning that can require some days. This generates a few issues: first, you can only release between 1 and 2 times per month, not very often; second, in each release you add several features, which is a problem for testing, because you need to test one feature at a time; third, if you know the problem but not the solution, you will need a sprint just to decide what to do, and then an additional sprint (or more than one) to develop the solution, this makes things very slow.

I have experimented this problem many times and this is one of the main reasons that pushed me to test new methods.

6. Dual track agile

The proposed solution is a methodology called dual-track agile, that divides the daily activity of a product team in 2 tracks: discovery and delivery. The two tracks go in parallel. During discovery the team identifies problems and starts thinking about the solutions, designing prototypes and testing them as much as possible. Once the prototype is validated, the team can start the delivery of that feature, which means actually building it.

The idea is to test as many solutions as possible during discovery and discard all the wrong ones during this phase; this way only the right solutions are developed during delivery.

For more info about Dual Track Agile I strongly suggest the book Inspired: How To Create Products Customers Love by Marty Cagan.

7. Story Maps vs Backlog

Another suggestion is to use a Story Map as a starting point, which is a list of all the possible ideas you have regarding a product. This should not be the backlog because backlogs should only contain validated features, these are just ideas.

Periodically the team takes stories from the map and start the discovery of those features.

Have a look at User Story Mapping: Discover the Whole Story, Build the Right Product if you would like to know more about this.

8. Prototypes as specs

The result of the discovery process should be a validated prototype: something that has been carefully designed in all details and already tested and validated with qualitative testing. As your UX designers can tell you, there are many types of prototypes and many tools to create them, speaking about them would require a post on its own.

Once you have a prototype, you normally don’t need to write specs or descriptions of the tasks for the developers. Prototypes already show perfectly, and better than any specs, what the team needs to create.

9. The importance of the team

There is one requirement to all the above: the product team. A small, cross-functional, collaborative team of empowered and accountable people focused on the OKR. The whole team collaborates for discovery and delivery.

Normally the product manager and the product designers dedicate more time to discovery rather than delivery, while the engineers dedicate more time to delivery. But engineers are fundamental to discovery too, and they need to spend time on this. First, because solutions need to be feasible and second because engineers are a great source of ideas.

10. To recap. How is it supposed to work?

You know the key metrics you want to improve, and based on that you select the stories from the Story Map; you design and validate them creating prototypes and making qualitative tests. In parallel, every day the team takes one of the validated prototypes and starts developing it. New features are released as soon as they are ready. Once a feature is live, you test it with real users to see if you reached your goal, if not, you need to design a new solution.

Easy, right? At least this is the theory, we know reality is usually much more difficult. As I said my team and I started to apply these learnings one month ago. If you want to know how it’s going, stay tuned!