Make Agile work for UX research impact

Stand-ups, sprints, and backlogs. If these words sound familiar to you as a fellow UX researcher, then you’ve encountered Agile in your work. If not, you probably will since 94% of companies practice Agile, in some form.

Despite its pervasiveness, Agile poses challenges for UX researchers. You don’t have to look far in the UX literature to find examples of this Agile/UX research friction. Most commonly, researchers struggle to fit research into work rhythms that prize short, small batches of work with frequent outputs. Agile, it can seem, demands that we squeeze our research into short time windows. This can compel us to take shortcuts like reducing sample sizes or choosing less-than-ideal methods. Concerningly, these compromises may erode the integrity of our practice.

Agile isn’t going away anytime soon. And, honestly, it can work really well for many different roles and disciplines. To be effective partners, we need to reframe problematic assumptions about Agile and our place within teams that use it.

Understanding Agile is a prerequisite

The first step toward a healthy relationship with Agile is to nurture a productive understanding of it. This will empower us to engage, as researchers, in any Agile framework with confidence. The majority of companies use a Scrum framework to put Agile into practice, but there are many other Agile frameworks in use.

Additionally, we need a baseline familiarity with Agile team activities (or “ceremonies”). This will help us know know where and how to best represent our research insights.

At a recent UXinsight Meetup, my colleague Emily Cochran and I shared guidance on how we can make Agile work for UX research impact. In this article, I’ll summarize a few most essential ideas, and you can watch the recording for more practical tips.

Mindsets matter in Agile and UX research

Ask any Agile coach and they’ll tell you that Agile is fundamentally a mindset. The constituent parts of that mindset were formally articulated by software developers in the Agile Manifesto. But to translate them to UX research, it helps to ground ourselves in some important mindsets of our own:

1. Outcomes matter as much as outputs

An output is a thing that is produced. When Emily and I worked on a mobile app for electric vehicle drivers, an output we tackled was the ability to easily see in real-time if a charging station is available. However, an outcome is the consequence or impact of that feature. Some outcomes we strived for were giving drivers confidence and peace-of-mind knowing they can charge when they need to. Outcomes are the reasons for our work to begin with, so we have to keep our focus on them even as we feel pressure to make things (outputs).

As the Agile Manifesto states, “Our highest priority is to satisfy the customer”.

UX Research Tip: You may find your teammates and stakeholders lose sight of outcomes in the rush to meet deadlines and produce tangible evidence of their work. When you sense this happening, seize the moment to reorient them to what will make a difference to users. Have them reflect on how their work items track back to the larger user journey. Start a conversation about outcomes and outputs.

2. We can’t know everything upfront

The Agile Manifesto is pretty clear that change is expected and welcome, no matter when it happens. UX researchers know that we learn a lot as we go along, with sometimes surprising results. Good research enhances our capacity to make meaning of those learnings – it’s core to the value we bring. While it can be intimidating to disrupt what once seemed settled, don’t be afraid to voice new information or shake up a plan.

Not only are you not messing up Agile when you flag a potential deal-breaker, you’re actually embracing Agile in its fullest sense.

UX Research Tip: When you make a discovery, it can happen that the team won’t be able to act on it immediately. In Scrum, teams set a Sprint Goal, adapting as needed to reach that Goal during the Sprint (a work timebox that’s usually two weeks long). If your insights don’t line up directly with the Sprint Goal, you may need to put your ideas in the Backlog, which is a list of work items that the team will pull from in future Sprints.

3. Agile calls for strategy, not speed

Agile frameworks can fuel a false sense of urgency when teams think in terms of reducing work down instead of prioritizing and planning strategically. Neither the Agile Manifesto nor Scrum prescribes that projects be done quickly or rushed. Rather, Agile and Scrum principles encourage delivering work (value) frequently so that it can be inspected and adapted often. This allows teams to learn from their work and ensure it tracks back to targeted goals and outcomes. Thus, teams break large undertakings down into simple, manageable parts, which in turn makes it easier to predict when they’ll be finished.

Don’t blindly succumb to the pressure to wrap up your research as quickly as possible. Rather, think of Agile as an opportunity to examine what research activities yield the most beneficial insights.

UX Research Tip: Teams have to make tough choices about how to scope their work, and not everyone will be able to do everything they’d like. As UX researchers, we need to critically examine where research has higher potential for impact. And then partner with our teammates on how to best choreograph everyone’s efforts. When you’re assessing which research activities to prioritize, think about the following factors:

• Quantity and depth of unknowns – How much do you already know about the problem space? Give high-stakes deliverables with many assumptions or ambiguity higher importance.

• Dependencies – How many of the team’s upcoming decisions hinge on research insights? If your research is foundational for other work, weight it with a higher priority.

• Ability to correct – If you’re supporting work that will be difficult or impossible to undo easily and at low cost, advocate for investing in research to avoid expensive UX and tech debt.

Case study – Negotiating UX research in Agile

Once you’ve internalized these core mindsets, you can more confidently engage as a full Agile partner and teammate. I’ll share an example where my project manager, Emily, and I negotiated a demanding, time-sensitive project. We carved out space for research that proved instrumental for its success.

Our client tasked our team with a full redesign of an electric vehicle public charging app that allows users to locate, pay for, and monitor charging sessions. As we planned out the roadmap, we quickly flagged a concern. Developers needed to start building out the payments functionality as soon as possible because it was time-intensive and a dependency for many other features. However, we knew payments was a major pain point for customers, and the client needed clarity on which payment technologies we would support. Unfortunately for research purposes, this payments functionality was slotted for the very first sprint.

There was no question that this payments decision was high-stakes. If we got it wrong, we ran the likely risk of making our users confused, angry, and distrustful – the exact opposite outcomes we strove for. Not only that, but once built, there was no going back to try an alternate path.

How we made UX research work in Agile

We weighed our options. We could try to squish some amount of research into that first sprint to get barebones directional information to designers and developers. Or, we could challenge some assumptions and priorities baked into the roadmap to resequence activities and free us to complete the field study we believed we needed to adequately settle the question. We negotiated the latter option. Our client agreed that we couldn’t construct the app around an uninformed decision that could risk their customer relationships just to save a few weeks worth of time.

Developers conceded to moving work that was originally planned for future sprints up to the first few sprints. This gave me the freedom to get ahead of their work to plan and execute a payments-focused research study. Not only that, but because our team understood what work lay ahead, we anticipated additional questions and gathered relevant information from users on those topics too. That one research activity effectively paid dividends throughout the project, and no work was ultimately held up waiting on research. On the contrary, we expedited the work thanks to having better user data readily available.

Direct your research focus to your (Agile) teams

During the meetup, some participants questioned how to apply this when their teams may not be (fully) Agile. The most practical step forward is to simply understand your team’s current state and partner to make everyone’s work transparent. This means directing your research focus to your teams to understand why things are the way they are.

Ask your teammates to write or draw their mental processes, workflows, and tasks so that everyone can visualize them. Once you can see work activities (on sticky notes, ticketing systems, virtual whiteboards, etc.), you can gain a collective understanding of your true situation. This shared knowledge will then allow you to chart a path forward together based on indisputable facts and concrete ideas of where you’d prefer to be.

As the Scrum Guide authors put it, “Transparency enables inspection. Inspection without transparency is misleading and wasteful”.

More important than “being Agile” is being a productive team. Many teams have adopted Agile and related frameworks because they help them to do just that. As UX researchers, it’s wise to leverage these ways of thinking to be better coordinated with our organization’s rhythms and practices and, in turn, be powerful user advocates.

Cover photo by Tim Gouw on Unsplash