Zonar Systems // Dual Track Agile

Building a culture of collaboration between Engineering, Product, & Design

The problem

Zonar Systems is very much an Engineering-focused company. So much so that product roadmaps would typically only account for the implementation of features in code, and never for the research, design, or validation of those features. Together with my Director of Design, Chris Hannon, we set out to change that by introducing a process of dual-track Agile that would account not only for delivery of what we have built, but discovery of what we should build.

My solution

Over several months, we worked together with our Product Management and Engineering leadership to build not a one-size-fits-all solution, but a collection of discovery activities that could be combined to particular needs within an allotted timeframe.

My Contribution

Cross-team collaboration
Workshop facilitation
Process mapping
Process management and optimization
Stakeholder management
Documentation

Two tracks, one process

Dual Track Agile is a methodology that has been around for many years. Its main goal is to help integrate cross-functional workflows into the Agile Methodology, which has historically neglected to account for non-engineering disciplines like UX.

Introducing the Discovery Track

Getting design / UX activities tracked within the Agile process has long been the white whale of project management. While the solution we’ve arrived at is certainly not the only solution possible, it was the solution that was flexible yet effective enough to solve our needs.

What is “discovery” in dual track agile?

Depending on what we know already about our customer’s needs, the starting point of the Discovery Track can be assessed and uniquely configured for each project. For example, we may choose not to do some activities because we have enough knowledge, or are comfortable working off a set of assumptions.

Managing Risk

There are trade-offs for removing steps, of course, which usually means increasing project risk. This can be acceptable so long as cross-functional teams are all agreed to the risk and how we choose to mitigate it, when and if it should arise.

Story Mapping

Story mapping is an integral part of the planning process. It gives multi-disciplinary teams an important opportunity to gather together and collaboratively define the scope of the release they’re planning, whether its an MVP, or larger release.

A standardized story map template we developed to ensure consistency across varied product teams.

A completed story map with clearly defined work items arranged in releases.

After story mapping, work items can be blocked out into loosely defined sprints. Typically, Design teams start about two sprints before Engineering teams.

Does the Discovery Track end once a Delivery Track backlog is built?

The short answer is “no.” Nobody likes doing more work than needed, so Discovery Tracks typically only seek gather just enough understanding to get cross-functional teams organized and moving forward. There is generally additional Discovery work needed to generate a fully realized design solution.

Transparent planning

Scheduled activities are translated into timelines so progress can be easily shared out to a variety of audiences. Dependencies are clearly denoted so as timing shifts, downstream work can adapt quickly, and delays are minimal.

Gantt charts in Asana provide a great visualization of project plan

Tracking and managing discovery work

An important factor to keep in mind is Discovery Track work often consists of activities, like research studies, that are larger in scope to fit in a typical Agile sprint. Instead, we opt to organizing into Kanban for tracking and load-balancing.

Swim lanes have statuses assigned to them to add more granularity to ticket progress.

Tickets should have clear descriptions and acceptance criteria to provide needed context, and reduce potential misinterpretations.

Discovery work in Agile sprint ceremonies

Daily standup

Discovery work should follow the typical pattern for a standup. The important part is that all disciplines are present and that stand ups are happening throughout the Discovery Track, even before a backlog is created. Additionally, designers leading a Discovery Track can use stand ups as a chance to expose any blockers or dependencies to their work earlier than end-of-sprint meetings.

Backlog refinement

It is necessary to include Discovery work is properly accounted for in the sprint (even if Kanban is being used to track Discovery work), and that tickets are properly groomed from a UX / Design standpoint. This means ensuring tickets have design documentation, links to design files, and final sign-off from Design and Product Management.

Sprint planning

In addition to accounting for Discovery work in the upcoming sprint, teams should also plan for any testing activities as needed, include Design’s estimates on Design / UX tickets, and aligning Design and Engineering priorities to the sprint’s goal.

Sprint demo

Demos should include a review of any ready-for-testing prototypes, review initial Discovery Track research / testing findings, and review design deliverables with Product Owners.

Retrospective

For Discovery Track work, the end of a sprint means identifying areas where the Discovery Track can be improved for the next round across all disciplines.

Learn more about how I work with these other case studies.

Zonar - Dual Track Agile