Dual track Scrum, it’s the future ive tasted it…..

Article written by Bryan Rees


I had a junior designer on our team ask me the other day how he was to balance the constant need for micro-improvements, optimization and team needs within their sprints with more big-picture thinking and discovery. This was a very astute question and one all designers, no matter their level of experience, struggle with in an Agile environment like ours. In the moment I simply responded that this is an issue of time and roadmap management and he was to do his best to communicate with his product manager the time necessary to include product discovery in the equation of delivering a final product.

It was pretty serendipitous to stumble upon an article a few days later entitled, “Fitting Big-Picture UX Into Agile Development”. I thought, “Bingo! This should shed a bit more light on the situation.” The author’s proposal for larger, time-boxed “Design Spikes” outside of the development team’s sprints was intriguing. It wasn’t until I was halfway through the article and hearing my own similar feedback in someone else’s words that I came to the realization how wrong we both were.

Always be Discovering

I personally don’t know the author of the article, but given the topic and how well thought out his proposal of Design Spikes is, I can gather that we work in similar environments and he has developed a system that he’s seen work for his team and organization. Upon reading his proposal and thinking through my own issues with UX Design in an Agile world, I realized the downfall of most popular design methodologies within Agile development—they assume you know when discovery needs to happen. The problem is, discovery should always be happening.

Whether you’re talking about Sprint Zero, Design Spikes, or Discovery Sprints, the notion seems to remain the same—discovery happens in isolated chunks, outside of and distinct from delivery. A designer’s time is then split between the two phases based on the tasks at hand and the two entities never intersect. The designer is therefore responsible for analyzing the backlog or waiting for a lull in development work to switch back to discovery—a dangerous game to play and one I’ve not seen successfully carried out over an extended period of time.

These Agile Design practices sound good on the surface, but are much more difficult to execute on in a well-oiled Agile environment.

Why Dual-Track is On The Right Track

Enter Dual-Track Scrum. In Dual-Track Scrum the Product Owner, Designer and Lead Engineer are continuously in discovery mode, creating and validating stories that will then be added to the development team’s backlog. From my experience, that validation is the key to a happy development team and a well-groomed backlog. I first heard this term fromMarty Cagan and he has a good bit to say on the matter. As he mentions inone of his articles on the topic, the first time he heard the term from Jeff Patton is the same as my response here—the term “Dual-Track Scrum” sums up nicely the parallel nature of Discovery and Delivery.

A simplified view of Dual-Track Scrum.

In an ideal Dual-Track world the discovery team is continuously in discovery mode and the development team is continuously delivering product to the end user. However, we still have a problem. What happens when the development team has questions or needs resources related to the current sprint? Inevitably in any organization—no matter how well-groomed or defined a story may be—no mock, annotated wireframe or high-fidelity prototype will ever truly suffice to ensure a quality product gets out the door. Oversight and constant communication from the designer to the development team is crucial in product delivery—even more so in an agile, continuously delivering environment.

A True Balancing Act

The balance of Discovery versus Delivery is a tricky one. The recipe for which only each designer will be able to create for his/her own specific needs and relationships with the development team. This balancing act is crucial to the release of successful product. Get to know your developers and establish an open line of communication within the team. Be sure your stories are as well-defined as they can be however, so you can focus the majority of your time discovering and validating the next big win for your business.


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

%d bloggers like this: