UX & Agile: Dream Team or Odd Couple?

Are UX specialists satisfied with their experiences in Agile projects? While participating in a recent panel discussion, I asked the audience this question and, judging from a show of hands, only about half were satisfied. These mixed reviews are consistent with what I’ve heard from UXers in various organizations over the past 10+ years and from what I’ve read in books like Lean UX.

While UX staff sometimes adopt an “us vs. them” perspective, we should start from the position that both UX and Agile have the same goal — to deliver great software that delights users. Problems can arise because each community has its own ideas about how to get there. To succeed as a team, these communities need to establish common ground and make some accommodations: UX staff need to ensure their practices are Agile-friendly and Agile staff need to make some of their practices a little more UX-friendly. When UX and Agile harmonize their practices, we can call the result a Dream Team. And when they don’t, we can call the result an Odd Couple team.

Let’s see what a dysfunctional, or Odd Couple, team looks like. Non-UX staff engage in practices such as:

  • keeping UX outside the core team (that is, “us” or “the team” is understood to include only developers),
  • doing a poor job applying Agile best practices (for example, writing user stories that don’t effectively articulate the user value), and
  • failing to allocate project resources (people, money, time) to UX activities like user research and design evaluation.

For their part, UX staff on an Odd Couple team engage in practices such as:

  • working part time on multiple projects, rather than being dedicated to a single project,
  • taking a long time to produce elaborate design artifacts to hand-off to developers, and
  • treating developers as “them” and not taking an interest in their work beyond UX.

This article identifies the topics where UX needs to find common ground with their Agile teammates to form a Dream Team. We’ll examine collaboration challenges for each of these aspects of UX in turn:

  • Understanding users, that is, conducting user research
  • Large-scale UX design, that is, overall project design direction
  • Small-scale UX design, that is, design in an individual sprint story
  • Evaluating designs

UX leaders can use these topics as a checklist to assess the health of their team and identify areas for improvement.

Understanding users

A tenant of UX is to develop a solid understanding of target users as a foundation for design. The quotes below illustrate the difference between a Dream Team and an Odd Couple project:

The key topics where UX needs to find common ground with Agile are:

  • How much UX research is enough, in the context of limited project resources?
  • How should that UX research be aligned with the project schedule?

Generally, UX staff feel that more research is needed than project leaders do, so both parties need to find common ground on how much is enough.

Given agreement to conduct research, the next point of discussion is how to schedule it vis-a-vis the agile sprint schedule. Models I’ve seen projects use include:

  • Up front — before project kick-off (Sprint 0)
  • Concurrently with sprints, but outside the sprint schedule
  • Integrated into the sprint schedule

The models above are listed in increasing order of logistical difficulty.

Large-scale UX design

It’s useful to divide “design” into large-scale vs. small-scale aspects. Here “large scale” design refers to:

  • Project direction, UI architecture, and visionary design concepts
  • Sprint planning and content definition

For this aspect of UX, the difference between success and failure looks like this:

Success from a UX perspective means having a “seat at the table” as one type of project leader and having adequate opportunity to develop and present a vision of the UX to guide the project.

Common topics of negotiation include:

  • What portion of sprint story content (i.e., project resources) will be devoted to delivering UX quality vs. feature quantity?
  • How much is the project team willing to revisit (refine, iterate on) designs from early sprints?
  • How much of the UX team resource will be allocated to large scale design vs. keeping the Agile story teams supplied with detailed UX designs?
  • How willing is the team to start planning 2–3 sprints ahead so UX can get a head-start?

Small-scale UX design

Here “small-scale” design refers to design to support individual sprint stories. One thing that UX staff say they like about Agile is its fluid back-and-forth between design and coding, rather than a formal hand-off from a design stage to a coding stage. However, not all teams have achieved this ideal state:

Aspects that have to be optimized include:

  • ensuring the user stories clearly articulate the problem being solved in terms relevant to UX,
  • getting developers engaged and collaborating in the UX design work prior to coding, and
  • getting developers being receptive to UX staff providing input and feedback during coding.

Evaluating designs

Another tenant of the UX discipline is the importance of evaluating designs with users. As with the other aspects of UX, success varies:

Aspects that have to be ironed out between UX and the Agile project leads are:

  • In the context of limited project resources, how much design evaluation is enough?
  • What are the expectations for fixing issues?

The first challenge is simply getting the opportunity to conduct evaluations. Opportunities can be limited due to staff resources, schedule, or access to users. The second challenge is getting issues fixed. The larger the fix, the harder it is to get it addressed.


We’ve identified several friction points between the UX and Agile parties in a project team. The more that the UX and Agile staff succeed in finding common ground and making accommodations on these points, the better for everyone — including the users of your software.

Further reading

For more quotes and case studies, see my recent article UX in Agile projects: Taking stock after 12 years.

For a practical book on this same general topic, see Lean UX.

For a deep dive on UX research, see the article Agile Development Is No Excuse for Shoddy UX Research.

For a recent scholarly treatment, see the edited book Integrating User-Centred Design in Agile Development.

To improve your empathy with software developers, I recommend the book Team Geek: A Software Developer’s Guide to Working Well with Others.

Finally, if you’re looking for something completely different and you’re a history buff, you might like the novel The Siege by Ismail Kadare.

Paul McInerney works in a UX research and design role at IBM in Toronto. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.