A Few Things I’ve Learned About Dual-Track Agile
Photo by Andrew Karn on Unsplash
January 2019 Update: This gracious tweet from John Schrag, Director of XD for Autodesk (whose UX team pioneered dual-track Agile in the mid-2000s) made my day!
As one of the co-inventors of dual-track Agile UX (along with my then-boss Lynn Miller and my colleague @DesireeSy) I heartily endorse this article by @mariaanicholas, with great tips for putting it into practice. https://t.co/pIoPSey4le
— John Schrag (@jvschrag) December 28, 2018
This post has been on my to-do list for far too long. As such, it describes learnings gleaned from my time working in a principal design capacity as part of a small (two pizzas’ worth) software development team. These days, like many others, I’m involved in conversations around how dual-track Agile product development can work effectively at scale and/or with distributed teams. I do think that much of what I reference here still applies today, and it’s something I continue to think about a lot.
As for the frequency — or lack thereof — of my blog posts, I’ll go ahead and blame the usual suspects (life, etc.) for causing my little blog to atrophy, and hope that now that I’ve finally published this entry, I can update just a little more frequently!
Dual-track Agile: A very brief history #
There are tons of articles and case studies on dual-track Agile out there these days. But where did the term originate?
The earliest reference to the concept appears to have been made in 2005 by Lynn Miller, then Director of User Interface Development at Alias (later acquired by Autodesk), who referenced “interconnected parallel design and development tracks” (or “dual tracks”) in her paper/case study presented at the Agile Development Conference in Colorado, three years after the organization’s adoption of Agile. (The Agile Manifesto was written in February 2001.) Miller’s paper detailed her team’s efforts to combine Agile development with user-centered design, both of which “stress collaboration between customers and product teams, but getting these methodologies to work well together is not easy” (from the paper’s abstract).
In 2007, Lynn’s colleague Desirée Sy wrote a paper published in the Journal of Usability Studies in which she referenced “Agile UCD methods” involving an interaction designer track and a developer track operating separately but in parallel, with design working one cycle ahead of developers and research working two cycles ahead.
And in 2012, product development thought leaders Jeff Patton and Marty Cagan talked about “dual-track scrum” involving separate but intertwined discovery and delivery tracks, where the outputs from discovery are the inputs for delivery. Discovery answers important questions about what to build, while delivery determines how to build it well. Crucially, discovery stays ahead of delivery to make sure there is time for those important “what” questions to be answered. (Here is a recent great article written by Jeff on the subject.)
It’s a great setup in theory, but as many of us know, it hasn’t necessarily been as smooth a ride in practice.
Agile + UX: Strange bedfellows — not #
Agile development and UX design are like a couple in an arranged marriage—a relationship between two strangers who are expected to coexist, develop trust and respect, and eventually, love each other.
—“Agile Development Is No Excuse for Shoddy UX Research”, Atul Handa and Kanupriya Vashisht, UXmatters, November 2016 #
I laughed when I read this relatively recent characterization of the relationship between Agile and UX. However, I think it also encapsulates why it remains a controversial topic. And although the statement gave me a chuckle, I don’t know that I agree with its premise. If the basic purpose of Agile is to build better quality software through creating value, getting frequent feedback, and responding to change, these goals are not at all incompatible with UX (especially Lean UX practices as introduced by Jeff Gothelf and Josh Seiden). In fact, I would argue that the two share a very similar spirit, and that it’s more a matter of adapting the principles in ways that work best.
Intentionally deciding to work beyond assumed boundaries between Agile and UX is a crucial first step towards meaningful collaboration between user experience and development teams. It’s probably also safe to say that as far as Agile itself goes, people have discovered that there’s an optimal way to do Agile and any number of suboptimal ways to do it, and that the optimal way has to do with making it work for you.
Here, then, is what I’ve learned about working within dual-track Agile environments as a user experience practitioner (research/design) who’s been privileged to help launch a number of impactful product solutions over the last several years.
Location really does matter #
Photo by Ben White on Unsplash
In my experience, the ability to operate as a (mostly) co-located team within a dual-track Agile framework is essentially a pre-requisite. Certainly, there’s more technology/tools available than ever before to help with offshore or distributed team communication, and our team was actually not together all of the time (we were a part-remote organization) — but we found it overwhelmingly accurate in practice that a team that sits together communicates together, learns together, and bonds together.
So many times, I’ve experienced first-hand the greatly reduced risk of miscommunication as a result of just being able to go over and talk to someone. In the absence of being able to do that physically, I’ll always strive for a quick video or phone call ahead of written communication (especially email). I find the immediacy, clarity and impact of face-to-face communication absolutely cannot be understated.
Team makeup probably matters even more #
This was the makeup of our team prior to the incorporation of dedicated UX resources and a few other structural changes that took place with the support and sponsorship of executive management. Technology and product management roles were mostly co-located, along with some offshore resources.
For our dual-track Agile reincarnation, we augmented the team with a range of UX skills, a dedicated front-end developer, and a dedicated product owner (previously, the PM was responsible for two different product lines). All these core team members were co-located, with the exception of our offshore contractors.
We"d often say in presentations that our team was rounded off by subject matter experts who were part of the broader business unit, and it was not at all far from the truth. Though not part of the core everyday team, our SMEs interacted with us frequently, and joined us for targeted design and research activities on a regular basis (see below). This model worked really well for us and was key to broader team buy-in and alignment.
PO & UX: Two sides of the same coin #
I was extremely fortunate to work with an amazing product owner during my time on the team, and I’ve realized since what a difference this makes. She had an intimate understanding of the business, serious tech chops, totally owned the product backlog and user story mapping, and was highly skilled at balancing big picture product vision with daily prioritization, decision-making, and communication. Above all, she was wholly committed to user-centered product design and unapologetically customer-focused.
We quickly became partners in crime. Here was someone I could not only rely on for critical business and technical knowledge, but who was a true design collaborator in every sense of the word. Our close partnership enabled us to achieve transformative results together, including measurable process and culture shifts, that wouldn’t have been possible otherwise.
We talked together. A lot. We established an organic, informal rapport early on that got better and better over time. We communicated every day over multiple channels. I could rely on my PO to do everything from help me understand an aspect of an existing product (see below left), to answer prioritization questions (below center), to share a UI idea (below right). She was my first go-to, and we were constant gut checks for each other.
We drew together. A lot. We continuously checked in with each other on strategic and business goals, and utilized visualization techniques to help us work through our constantly evolving priorities. There was almost never a time that we were not sketching or brainstorming together, and it proved instrumental to our being able to keep plans moving in the right direction.
There’s a lot of overlap between product and UX, and that’s good. Silos are unconducive to effective product development, particularly when they exist between product and UX. This does not mean that specific areas of expertise aren’t utilized on either side. But there is much overlap between PO and UX, particularly around understanding the customer— and in my experience, embracing that overlap is what helps create powerful product solutions.
Changing the Conversation about Product Management vs. #UX#fromthearchives #prodmgmt #uxhttps://t.co/YUOkq4nuVC pic.twitter.com/yoJKCPRbLl
— Melissa Perri (@lissijean) October 6, 2017
Some time after the PO and I started working together, I came across this great diagram by Melissa Perri, which I thought encapsulated our working relationship really well. I highly recommend the accompanying article.
UX: Involved and committed #
Photo by Mike Wilson on Unsplash
Although Agile process has formally done away with The Chicken and The Pig fable, the distinction the metaphor draws between being involved in a project versus being committed to it is still relevant. As a UX practitioner, I’ve found that in order to create every opportunity for success, I need to artfully vacillate between both participation states. It’s not an easy thing to do, but embracing the duality pays dividends—and in my opinion, it’s part of the job.
UX is a bridge. As user experience professionals we are natural connectors, interfacing both with business and development and alternating between high-level product strategy and day-to-day implementation work. Instead of worrying about specific Agile procedures, soon after our team started working together, I began doing whatever UX work was needed to help the team succeed. I paired with whomever I needed to depending on what was going on, which allowed me to stay flexible while keeping the continuous sequence of sprints going as seamlessly as possible.
UX needs to attend (and enhance) Agile ceremonies. As a UX lead, I considered myself part of the Scrum team, even as I wasn’t assigned stories or estimating them. I was in on every single meeting — release planning, daily standups, backlog grooming, retros, you name it. I’d give brief updates during standup even if they didn’t pertain to a specific story; I’d talk about a recent customer interview, where I was with a design, or upcoming user testing sessions.
Was I was met with a few mildly incredulous looks when I first started doing this? Sure. But over time, I found that developers and QA started to really appreciate the updates I provided. Through my input, they were able to gain a broader perspective on our product initiatives, better understand our customers and their needs, and stay informed about what was coming down the pike. And I’d still be available during implementation, providing input, clarification, or whatever else was needed to keep things moving.
In short, if you’re in UX and are asked to work within an Agile stream, my advice would be to get comfortable joining ceremonies and providing your perspective on a regular basis.
Yes, UX must stay ahead #
This is the other pre-requisite. The process needs to allow time for the right types of activities to happen with which to effectively fill a backlog.
In effect, within an Agile team, I don’t actually work with developers or QA on active stories (other than for clarification or updates – see above). Rather, I produce work on a separate, parallel track (roughly 2 sprints ahead) to provide needed answers to shape stories before the team is ready to fully implement them.
How and where does this planning happen? It’s a continuous process involving close PO, UX, and Dev collaboration and both short-term and long-term regular prioritization exercises — everything from quarterly adjustments to a weekly, sometimes daily, prioritized backlog. It’s not easy, but it’s achievable as long as there is a commitment to constant communication and transparency on all sides.
How do you manage the backlog? Our team employed two separate JIRA boards. The UX board maintained stories for research, design, and experiment/validation work, while the “regular” Agile (delivery) board contained sprint stories in flight as well as the implementation backlog. Only validated discovery stories would enter the delivery backlog, and discovery and delivery stories were usually linked so that development could reference the full arc of a particular initiative.
Who writes the stories? Everyone. Our UX board contained research, design, prototyping, and/or user testing stories written by myself, the PO, or our front-end developer. For validated customer-facing designs, I would help write stories after collaborating with the PO on story breakdown. I would routinely enhance delivery stories, attaching screenshots and links to prototypes. The PO would take the lead on a good chunk of stories, while our Tech lead wrote additional architecture, database, and/or API stories. Stories would often be written in teams.
How do you time it so development has enough work to do? In my experience, I have found it’s usually a matter of creatively balancing customer-facing stories with tech stories, and that a resourceful PO and tech lead are absolutely crucial in this regard. When I worked in an Agile team, there was almost always something the engineers could focus on for a relatively short time to allow for important discovery work to occur. Early on, it was possible to work on architecture/infrastructure stuff that had little to no UI; later, during customer discovery, the team could tackle tech debt or automation stories to set them up for scalability. Our tech lead always had a backlog of tech stories to draw from, and we were usually able to prioritize sprints in a way that gave me cascading runways I could work within.
Getting creative with tools and ceremonies #
Components as pivot sizes: In JIRA, a component is defined as a subsection of a project, used to group issues across different categories. Our delivery manager created “iteration size” components that we started to use on the UX board to measure our pivots between user testing sessions. The ultimate goal was to tie them to development points and report out on how much money we’d saved. Unfortunately we never got to seeing this all the way through, but it was just one example of how an Agile tool could be utilized to track an important product metric.
Backlog grooming re-imagined: In Agile, backlog grooming is defined as a process that, quite simply, is used to “make improvements to the product backlog”. With such a general definition, there are any number of ways this activity can be leveraged to include UX. Our PO repositioned backlog grooming sessions as “design dashes” where we worked as a team through an upcoming story’s flow, especially for complex/involved features or UI. The entire team would be present at these sessions, and in addition to regular whiteboarding sessions, we’d often focus on story breakdown and initial prioritization as needed. Any boardwork would be uploaded to Slack and used to augment stories and other documentation.
Engage, engage, engage #
Engagement is something I also see as a UX responsibility. The more I’ve actively engaged others within a dual-track Agile framework, the more it’s paid off — besides, it’s inherent to the discipline. We should strive to involve developers and other colleagues in research, because research is part of the work. We should strive to involve developers and other colleagues in prototyping, because prototyping is part of the work. We can and should be the resource that guides developers and others down the right path.
Full Team Involvement: Design Sprints Conducted ahead of large product kickoffs near the beginning of discovery, design sprints have been a great success story for the product initiatives I’ve spearheaded. I’ve been lucky to have strong product partnership and executive support in demonstrating the value of these types of activities, and they have proven to be transformational. You know you’re doing something right when developers and QA are asking you if they can be included in future sprints! I won’t go into detail in this post, but you can read a detailed account of my foray into design sprints and associated takeaways here.
Full Team Involvement: User Testing Though not always feasible, my PO and I worked hard to encourage developers, QA, and members of the broader organization to observe user testing sessions as often as possible. We kept involvement lightweight, requesting observation of 1-2 sessions per major round and asking for 3 quick takeaways per session. Through this process, the team was able to hear directly from customers and learn together without needing big readouts, which saved time on my end. Later on, when I’d give updates during standup, developers who had listened in on sessions were able to share their own observations and insights, which greatly helped with team alignment and trust.
Look to provide the why #
We conducted story mapping sessions as regularly as we could. It went a very long way towards aligning work to customer outcomes and business goals, so everyone knew the purpose behind what they were working on. I highly recommend it! The artifacts above are from an all-day release planning session that included both story mapping and sprint planning; we aligned themes to epics in JIRA.
Always be communicating #
You guessed it — another core UX responsibility. The more you do it, and the more ways you do it, the more it pays off. Particularly in dual-track Agile, the importance of communicating with developers and QA as much as possible can’t be understated.
A technique that proved particularly productive for me in communicating with my Agile teammates was “protocasting” (a term coined by author Robert Hoekman Jr. back in 2008). Using a prototype as my main communication tool, I would make screen recordings of my interaction with the prototype while I spoke out loud about what I was doing, why I was doing it, and anything related I wanted dev or QA to know. This became a much easier way to detail the multiple states of a single screen, and was a handy reference tool particularly for our offshore developers in different time zones who could not always participate in real-time team discussions or presentations.
For certain projects, I would also provide annotated screens detailing use case functionality. Developers and particularly QA loved these, though they were laborious to produce and difficult to maintain. Importantly, I never provided annotations without already having a fully-functioning prototype available first!
The secret weapon: Design-literate front-end development #
Bringing on a talented, user-centered front-end development expert shortly after forming our core Agile team became a huge part of our success. Sometimes called a UX developer or UI engineer, this function bridges design and technology and is different than the role of a traditional developer. (The best encapsulation of the role I’ve come across is “rooted in engineering, part of the design process”.)
True front-end devs can be a hard sell in legacy corporate environments where “full stack” developers (who are often more middleware and back-end focused) are the norm, but the all around benefits of having expert focus on the presentation layer are immeasurable. Through leveraging our front-end engineer’s talents, we were able to get to a state where the final UX deliverable was code. This was not only more compatible with Agile/Lean practice, which favors live code over static design comps, but the front-end code was set up as optimally as possible for flexibility, scale, and the best user experience.
Our developer maintained pointed stories on both the discovery and the delivery JIRA boards; some weeks would be more UX-focused (working on prototypes, participating in design sprints, or even listening in on user testing sessions), while other weeks were implementation-heavy, involving code integration into the back end. Managing the flow of work depending on what was needed was accounted for in capacity planning by our delivery manager in collaboration with our PO and myself.
The process was ultimately sped up from all sides, allowing for more efficient distribution of the work that needed to happen, and allowing the dual tracks to intertwine much more smoothly and naturally over time.
Recognize it’s a balancing act #
Photo by Johnson Wang on Unsplash
Lest you think my rah-rah accounts of collaboration and alignment mean our team had it all figured out, we most certainly did not! There were stumbles: our first MVP ended up being a mad rush, leading to some burnout that took us a while to recover from, and we misestimated our quarterly release planning a couple times and paid for it later. But we were persistent, and we got better as we went along.
From a UX perspective, I think it’s important to remember that when working in dual-track Agile, there’s no way you can do everything yourself. The best thing you can do is to get your cross-functional partners to help you, particularly in discovery and user research (but also through ideation in design sprints, because good ideas can and should come from anywhere). When everyone pitches in, the reward is greater understanding, a greater sense of ownership, and increased speed because everyone is learning together in real time.
There is no single right way (and that’s what makes it great) #
In the end, we learned that dual-track Agile worked best when we made it work for us. So hold on to the essential principles related to incremental, iterative building that delivers value, but don’t be afraid to do things differently otherwise, particularly when it comes to incorporating user experience. At the end of the day, it’s about people working together and learning from each other so they can build the right thing for the customer and the business, and build it well. Dogma and labels don’t matter as much.