Introducing Dual Track Agile
Introducing Dual Track Agile
A product manager provides insight on how to create products customers love based on the ideas he's been implementing in his team for the past month.
Join the DZone community and get the full member experience.Join For Free
Whatever new awaits you, begin it here. In an entirely reimagined Jira.
Last July, I had the chance to follow a two-day training called How to Create Products Customers Love, held by the Silicon Valley Product Group. The workshop was really intense and information-rich (I strongly recommend it) with a lot of useful suggestions for my 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 with my personal experience soon.
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 reach the team.
Launching Features That Don’t Solve Problems Isn't Useful
Regardless of whether 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.
Nobody Has the Answers
Making products is not like solving equations. Let’s say that 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. Your previous experiences, your skills, your gut, etc., can be useful, but you won’t know that your solution works until you really release it and test it.
Many Quick Iterations
Imagine that you need six tests before reaching the correct solution (in reality, it could be much more than this.) If it takes one month to release something and make a test, you will need six months to find the correct solution. You cannot afford this. You need to make many more tests in a shorter amount of 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. It’s fundamental to create prototypes and Minimum Viable Products until the idea is validated. These are the principles of the Lean Startup approach.
Scrum Sometimes Can Be an Obstacle
As you know, Scrum divides the process in Sprints, normally of two weeks (sometimes more). 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 one and two times per month, not very often. Second, in each release you add too many 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 with my team. This is one of the main reasons that pushed me to test new methods.
Dual Track Agile
The proposed solution is a methodology called dual-track Agile, that divides the daily activity of a product team in two 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 so that only the right solutions are developed during delivery.
Story Maps Versus Backlog
Another suggestion is to use a Story Map as a starting point, which is a list of all the possible ideas that 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 starts the discovery of those features.
This book by Jeff Patton will tell you more about the concept of Story Maps.
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.
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.
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!
Published at DZone with permission of Emanuele Bolognesi . See the original article here.
Opinions expressed by DZone contributors are their own.