An Answer to the Pains of Integrating Agile and UX

As sometime director of Design at Infragistics, I personally have had first hand experience trying to integrate UX into an existing, established Agile engineering process with large-ish teams. So I’m always interested in seeing how others are faring and what ideas they might have to address pain points.

Interestingly enough, in that session, all panelists identified a key pain point that resonated with my experience as well. They all attempted some flavor of the now well-known staggered sprints approach, and they all felt the pains that such an approach introduces, namely being torn in too many directions at the same time–trying to do research and initial design for upcoming sprints while supporting the implementation of the current dev sprint. Sadly, none of them really had solutions to that problem. It was kind of a “yeah, it’s painful, and we don’t really know what to do.” The strategies employed were coping strategies rather than success.

One of the attendees during the Q&A essentially went on a rant about how “Agile is a developer process,” essentially suggesting that we UX folks know better and shouldn’t even be trying to make Agile work. He used the term “developer” as if it were an epithet, and unsurprisingly, a lot of the audience cheered him on. Clearly, the problems of integrating UX practice into Agile are a common source of pain for UX people.

The real challenge with the standard approach to integrating UX into Agile is fundamental to the staggered sprint model. The challenge is essentially that it is not wholly effective to try to be working ahead on the upcoming backlog items while at the same time supporting the development team, answering their questions, reviewing what they’re doing, and providing ongoing feedback/microiteration with them. “Microiteration” is a term I coined at Infragistics—it is extremely timely iteration within a sprint where you work hand-in-hand with devs to review stuff right as they build it, provide feedback, and iterate.

When following this staggered approach, either research, evaluations, and up front/initial design suffers, or seeing through the implementation of the design suffers. One is always pulled in different directions, and that usually results in things falling through the cracks.

Enter the book

It turns out that Jeff Gothelf, author of Lean UX (the book I’m reviewing here) has also faced the same challenges. I liked his honesty in relating how he came to an epiphany when he, as manager, thought things were going along hunky dory, but then he got not-so-subtle indicators from his folks that his view of reality and the reality they were living were quite divergent. Jeff was different from the session presenters in that he offered a potential solution to the staggered sprint pains.

The answer situates itself within the Lean approach to product development. A lot of people seem to confuse Lean with Agile, and while they share some common characteristics, I would say that Lean is far more prescriptive. As Gothelf points out, Lean UX synthesizes the highly iterative structure of Agile with the creative and scientific methodologies of design thinking and Lean Startup (a set of concepts popularized by Eric Ries in his Lean Startup book), utilizing multiple frameworks to determine solutions.

Lean UX proposes a number of core principles and the ones that most directly address the key pain points mentioned above are:

• Cross-functional teams – have UX folks integrated into the teams, not external consultant-type model
• Minimize waste – few deliverables and handoffs

As Jeff relates in Chapter 4, the process is one that involves the whole team (as much as possible) in the user research and early design ideation. It goes further to have the team focused on the same problems at the same time. Together, this approach goes a long way towards eliminating the staggered sprint problems, and it also has other benefits around reduced waste and getting everyone on the same page more easily.

Lean UX has its own challenges

Of course, this collaboration model is not new with this book—the “movement,” if you will, has been gaining momentum for a few years now. And it has its own challenges—doubtless you’re thinking of some in your head now. A lot of them boil down to concerns around distinctions in competency—a concern of loss of specialness when UX folks already often have to help people understand the value they bring to the table. I think Jeff addresses most of the common ones in the book, so I won’t rehash it here.

I have been skeptical for a long time about the feasibility and value of involving “everyone” in design research. But I have also observed the negative effects and the waste in the process when, essentially, people can’t believe you because they did not witness the same things that you did. I’m now of the mind that if you can, involving more of the team in the research is beneficial, not just to solve this “belief” problem but also as a means to help establish a shared vision of the customer and to help generate more design ideas.

As Jeff points out, the UX designer becomes the leader and facilitator of design, rather than the sole source of it. Given that generating many alternatives is a key part of good design, this seems like a good thing—and having people who are generating be more aware of the research will only improve each alternative’s quality.

There are still solitary activities for designers to do in this model, but they are more about synthesizing and choosing design concepts (and of course coordinating and facilitating as per usual). The solitary type activities are reduced, and the increased participation from other team members means that on the design end of the process, everyone is focused on the same problems. And then on the back end, the UX role is more supportive—filling in blanks, answering questions, and doing microiterations.

Same goes for the eval side—getting everyone involved has similar benefits. And at the same time, the problems of staggered sprints and being pulled in multiple directions are ameliorated.

Summary

There is a lot more to Lean UX than I focused on here; however, this is a key area where I think Lean UX has a lot to offer teams that are trying to figure out how to integrate UX and Agile. Additionally helpful are topics like a more objective/experimental approach, having a more open and timely collaboration with customers, and establishing the vision, framing, and focusing on outcomes.

Jeff goes into some depth on Integrating Lean UX and Agile, and his final chapter on “Making Organizational Shifts” is helpful to anybody interested in pursuing a path along these lines. There are still questions I have (as well might you), but hopefully you’ll see at least some of those in a subsequent interview on B&A.

For anyone interested in improving their process and collaboration, specifically with integrating UX better into existing software development approaches, this book adds a lot to the discussion. I’ve recommended it to my colleagues, and I can recommend it to you too.