An Answer to the Pains of Integrating Agile and UX

Review of Lean UX: Applying Lean Principles to Improve User Experience

I recently attended UXPA 2013 in D.C. Although I was attending as a sponsor/exhibitor for Indigo Studio, I did manage to break away to go to the “There’s more than one way to skin a cat: Integrating UX into an Agile environment” session. It tied in quite nicely with the book I’m reviewing here.

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.

Tags:

Posted in Book Reviews | 12 Comments »

12 Comments

  • Putting people first » Book: Lean UX

    August 15, 2013 at 8:40 am

    [...] Review by Ambroise Little: [...]

  • What I've been reading lately (week 33), by Samuel Ericson

    August 19, 2013 at 7:16 am

    [...] An Answer to the Pains of Integrating Agile and UX « Boxes and Arrows Review of Lean UX: Applying Lean Principles to Improve User Experience [...]

  • Irith

    August 29, 2013 at 4:37 am

    Would love to tweet this… but no share button :-(

  • Stew Dean

    September 5, 2013 at 6:15 am

    I read Lean UX and have my own thoughts on it. I will have to reread it as I didn’t quite see how it cured the Agile / UX issue. Agile is an implementation process, not a design process and comes from manufacturing – that is implementation. Even developers should not use Agile to design the overall technical solution!

    The other big issue with Lean UX and Lean Start Up in general is its poor approach to evidence based design, that is good quality User Research. This can be fixed by pointing out that feedback should not be trusted and good quality sessions where team members see real users use the device are always needed.

    More on this see my blog http://uxstew.tumblr.com/

  • An Answer to the Pains of Integrating Agile and UX - User Experience - UX - Mobile - Design - Jerry Lieveld

    September 5, 2013 at 5:37 pm

    […] boxesandarrows.com/an-answer-to-the-pains-of-integrating-agile-and-ux/ […]

  • amro

    September 6, 2013 at 9:15 pm

    This can be fixed by pointing out that feedback should not be trusted and good quality sessions where team members see real users use the device

  • mohaarar

    September 6, 2013 at 9:16 pm

    I read Lean UX and have my own thoughts on it. I will have to reread it as I didn’t quite see how it cured the Agile / UX issue. Agile is an implementation process, not a design process and comes from manufacturing – that is implementation. Even developers should not use Agile to design the overall technical solution!

  • An Answer to the Pains of Integrating Agile and UX « Agency Geek

    September 19, 2013 at 6:58 am

    […] See Article […]

  • An Answer to the Pains of Integrating Agile and UX | UX.MWEPRIN.COM

    September 30, 2013 at 4:11 pm

    […] Boxes and Arrows […]

  • The UX Professionals’ Guide to Working with Agile Scrum Teams | UX.MWEPRIN.COM

    October 3, 2013 at 3:56 pm

    […] Many UX professionals seem stymied by the challenge of effectively integrating UX within an Agile development framework–but there are others in our field who have encountered the same problems yet are finding […]

  • Foxfield

    October 24, 2013 at 8:23 am

    Working as a UX Research in an Agile process, I have experienced some of the problems above. However, the most successful approach is to be less prescriptive about front end research – Agile and Research are complimentary if the front end (discovery and requirements gathering etc.) research is are not initially ‘part’ the Agile process. Findings are then feed into the first Sprint. Research for the later Sprints should be low documentation and use innovative techniques (forget lab based) such as walk up interviews, telephone/remote testing and guerrilla testing etc. focused on your target audience. UX Research has to learn to be as flexible as everyone else in the Agile team! As a UX Researcher working within an Agile team, I build trust through a close working relationship with the team’s Designer, we ‘design’ together so that UX best practice and findings from face to face research activities are immediately feed into any iteration. Think about using traditional methods such as lab based research pre-launch to pick up any final issues. Combining UX Research into Agile is about being a better Researcher and not sticking to ‘old ways’. I love working in an Agile way, I can immediately see user feedback feed into the design and I learn more and more everyday about other disciplines. As a UX’er I say embrace Agile – it makes a project more immediate and interesting from my perspective and ultimately makes the project/interface better for the end user.

  • Applying a Startup Environment and Developer Principles to the Library UX Lab | ANTELOPE AS DOCUMENT

    December 4, 2013 at 6:07 pm

    […] Little, A. (2013, October 13). An Answer to the Pains of Integrating Agile and UX. Boxes and Arrows. Retrieved December 2, 2013, from http://boxesandarrows.com/an-answer-to-the-pains-of-integrating-agile-and-ux/ […]

Sorry, comments are closed.