As a UX manager I have found one of the stickiest challenges I face is fully integrating design and development teams. The pace of each discipline is different, so is their vocabulary, the information that drives their work, and their intermediate goals. I developed the no-handoff agile method to address these challenges, and one of the most meaningful changes is getting your agile team into a dual-track formation as quickly as possible. It’s a game changer.
Dual-track agile, sometimes called dual-track scrum, is an agile framework that recognizes two distinct but concurrent workflows: discovery and development. These tracks run in parallel and support and feed into one another at regular intervals.
Each discipline is indispensable in this management philosophy and communication between disciplines is not only scheduled, the project cant function without full involvement from both. Here is how Desiree Sy illustrated dual track in her 2007 article “Adapting Usability Investigations for Agile User-centered Design”[1], and we can see how ahead of her time she was:
Lets replace “cycle” with the more modern term “sprint”. In each sprint we generate the next iterative deliverable that the other track depends on. They are interdependent on — and indispensable to — one another.
Note that in no-handoff we replace cycle 0 with a prototype sprint (the prototype sprint primer is here) but in this article I want to focus on how transformation dual-track agile is for design.
A game changer for designers
Gone are the days when you pour your heart into a design, throw it over the fence, and let out a deep deeply sad sigh six months later when you see the results! The dual-track process transforms the way UX and UI interact with development. Dual track agile is one of the key patterns to avoiding project handoff in the no-handoff method.
One of the implications is that design no longer needs to spend time advocating for its own existence. It’s indispensability is a given, and that frees everyone to simply get to work.
The dual-track process also brings clarity for developers to the sometimes opaque creative process. Trying to understand the project design and purpose can be like reading a manual written in a foreign language or, in the words of an astute internet comment-leaver, “like a sausage factory hidden within an ancient temple of magic.”
In a dual-track the mystery gives way to the light of frequent communication and incremental updates. Dual-track brings the iterative agile approach to design, and brings iterative creative and customer feedback to development. Results are also presented within the framework of the prototype itself. In this way design is not a separate process at all, but fully integrated into every stage of the project.
From the developers perspective the dual-track process brings clarity to the sometimes opaque creative process. Often trying to understand the project design and purpose is like reading a manual written in a foreign language. Or, in the words of an astute internet commenter, it’s “like a sausage factory hidden within an ancient temple of magic.”
“It is like a sausage factory hidden within an ancient temple of magic.”
hilarious commenter FUBAR on cioinsight.com
What the discovery track brings to the table
There are two types of work in every web project: development and discovery. If the process is pressured into shifting discovery into a design sprint before the project build, or into a skinning process at the end, the project is essentially making the decision to offload the difficulties and relatively reduced risk of integrated discovery in favor of building software unimpeded by reality. That’s a relatively easier process, but also fundamentally uninformed by the user research data and user-centered design that ensures the work will meet it’s purpose.
Keeping in mind that the goal of agile is to minimize risk by validating our ideas in the fastest, cheapest way possible, discovery brings validation and reality checks to a process that can all too easily operate in a vacuum. The worst possible time to ask if your project works is when its done. As Marty Cagan puts it “Actually building and launching a product idea is generally the slowest, most expensive way to validate the idea.”[2] The discovery track brings in the necessary research and validation, and all work is communicated via the shared language of the prototype, to incrementally improve and validate the end product alongside development.
“Actually building and launching a product idea is generally the slowest, most expensive way to validate the idea.”
Marty Cagan
In dual-track projects all work feeds the prototype. Accomplishing a deployable prototype involves frequent research, discovery, and visualization (the discovery track) to created validated backlog items. It also clearly involves programming the actual software (the development track). It’s all too easy for discovery to be swallowed up by the immensity of the development track, which gives us our product after all. But a strong discovery track makes sure it’s actually worth our time.
What dual-track looks like for designers
Dual-track offers designers a different way to engage in an essentially code-based process. The changes are profound and come in all shapes and sizes but below are a few that have stood out for me:
One marked difference is that, at each sprint on the discovery track, you are testing and evaluating the real product — the prototype itself — and not a visualization or a mockup that may or may not be what users eventually see. Testing the actual code across multiple devices and with assistive technology becomes a matter of course.
Another profound change is working in small, digestible increments rather than aiming for a big reveal. For design to actually be of use in an agile project it needs to shift from a siloed design process that hands off a precious final product to development, to an incremental one broken up into sprints. Lean UX [3] is a great option in a dual-track workflow. As Marty Cagan wrote “Lean UX and Dual-Track are made for each other”:
“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”
A dual-track method puts the design, the interface, in theleadership role. Note that this doesnt mean the designers are leading the project, nor are the developers. The prototype itself leads in a language all team members speak. Designers are able to translate user data into requirements in that shared language, greatly reducing miscommunication with developers. In a study by Forrester Consulting of over 100 application developers “42% of application development and delivery professionals are unable to keep up with new and changing requirements, and 40% struggle to understand unclear requirements”[4] resulting in significant loss of productivity. The dual-track method is an opportunity to significantly improve the clarity and relevance of requirements.
And lastly a dual-track project has a profound effect on how and when UX research takes place. What drives user-centered design in a dual-track process is user data. Instead of relegating UX research to windows at the beginning and end of the project, it takes place in incremental stages suitable to the product’s development. By adjusting the way discovery gathers and reports UX data it too can harness the power of the agile workflow: speed, responsiveness, reduced risk, increased value, and collaboration.
Conclusion
All development work breaks down into two types of activities: development and discovery. Dual-track recognizes that reality and offers a way for the two processes to interact and move forward together. As Jeff Patton puts it: “Two tracks, not two teams.”[5]
References
- Desiree Sy, PDF publication, “Adapting Usability Investigations for Agile User-centered Design”, https://uxpa.org/sites/default/files/agile-ucd_0.pdf
- Marty Cagan, website article, “Dual Track Agile”, https://svpg.com/dual-track-agile/
- Interaction Design Foundation, website article, “A Simple Introduction to Lean UX ”, https://www.interaction-design.org/literature/article/a-simple-introduction-to-lean-ux
- Forrester Consulting, PDF, “The Impacts Of Missed Requirements In Agile Delivery and Practices That Can Reduce Them”, http://www.internationalinsuranceforum.com/prop/wp-content/uploads/2016/05/4-Bernd-Wertz-NTT-Data-.pdfx_.pdf
- Jeff Patton, website, “Dual Track Development”, https://www.jpattonassociates.com/dual-track-development/