When I first start working with an Agile product team, one of the most common situations I find is where the teams have long and frustrating Sprint planning meetings because backlog items are poorly defined and not well understood; they have slow velocity as well as poor design because details are still being worked out during the Sprint; and the amount of waste and rework is very high because backlog items have not been validated.

Remember that our higher order objective is to validate our ideas the fastest, cheapest way possible. Actually building and launching a product idea is generally the slowest, most expensive way to validate the idea.

Which is why I’m a big advocate for what is sometimes referred to as Dual-Track Agile (aka Dual Track Scrum, Fake It Before You Make It, Build Things That Don’t Scale/Build Things That Do Scale, Move Fast/Don’t Break Things, Continuous Discovery/Continuous Delivery, etc.).

I used to refer to this as simply Discovery Sprints, but that has an implication of time-boxed Discovery, and also serialization of phases. Jeff Patton first shared with me the term “Dual-Track Scrum” and I prefer this term because it better captures the parallel nature of Discovery and Delivery.

The Discovery track is all about quickly generating validated product backlog items, and the Delivery track is all about generating releasable software.

Another reason I like the Dual-Track Agile metaphor is that I find many people essentially doing little mini-waterfalls within their Scrum framework. The product manager does some kind of “requirements” work, and that is passed to a designer that does his designs and generates his artifacts (usually annotated wireframes), and then that is handed off to the delivery team to build and test.

In contrast, in Dual-Track Agile, the work flow is not characterized by each role delivering artifacts on to the next step; rather it is collaborative – the product manager, designer and lead engineer are working together, side-by-side, to create and validate backlog items.

Readers of these articles know how important I consider user experience design, but one of the difficulties for many Agile teams is that the rhythm and pace of Agile can be very difficult on traditional UX teams. This is why I’m a fan of Lean UX. Lean UX and Dual-Track Agile are made for each other. Rather than focus on artifacts, we focus on prototypes and validating those prototypes in Discovery, with the added benefit that the prototype serves as the spec for Delivery.

Most importantly, unlike a Waterfall process where the validation happens after release, in Dual-Track Agile, we are validating during Discovery. In the principle of validating as fast and cheap as we can, much of the time we can in fact do our validation before we write any production code, in the spirit of “fake it before we make it.”

So if your product team is frustrated by the amount of waste and the slow pace in achieving actual business results, consider trying out Dual-Track Agile. See if this can inspire a level of collaboration, rapid iteration and validation that results in much better work.

Source: svpg.com