An Answer to the Pains of Integrating Agile and UX

Written by: Ambrose Little

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.

Drilling Into Lean UX

Written by: Ambrose Little

Overall I found Lean UX to be an incredibly insightful and helpful compilation of principles and suggestions for practice/improving process and collaboration as outlined in my review of the book. As I was reading, though, I had some questions come up that I felt weren’t answered–or maybe I missed the answer. Since others may have these same questions, we appreciate Jeff Gothelf agreeing to answer them for Boxes and Arrows.

Ambrose: In a couple places, you mention the value of keeping your teams small. I’m sure you are quite aware that there are some pretty large software projects out there, though.

Do you have any ideas/recommendations for those in that kind of situation? Are there ways of, for instance, breaking into smaller teams for Lean UX while still tackling larger solutions that you have seen work well?

Jeff: As team sizes grow, communication suffers. As communication suffers, the team increasingly relies on documentation to ensure nothing is missed. This increases the workload on the team, focusing them on tasks that add little value to the project and taking them away from tasks that move the team forward.

In these situations, look for logical ways to break the larger team up into smaller, more nimble groups. Keep those groups as cross-functional as you can and provide regular opportunities for them to coordinate with each other, such as daily standups, scrum of scrums, and the like.

Ambrose: In Chapter 3, one of the early activities you describe is “feature brainstorming.” I have seen a tension between thinking about features and thinking in terms of user stories. It is similar to problem vs. solution, and my experience has been that it is way too easy for team members to jump to solutions, often bypassing taking time to really understand contexts of use, actual users, and their desires. It felt like this was being short-circuited in favor of a focus on features.

Maybe it’s a terminology issue, but do you see value in capturing and starting from stories and/or storyboards rather than from features?

Jeff: The main focus of the team should be the outcomes the project or product is trying to achieve. These can initially be captured as user outcomes but should ultimately be translated up into business outcomes. Using our desired outcomes as a filter we can prioritize features more objectively–whatever technique gets you to the point where you have an objectively prioritized list of hypotheses fastest is the one you should use.

I’ve been in situations where bringing in some visualization artifacts has moved the process along faster. The goal is not to present them as “done deals” but more of conversation starters for the rest of the team to take inspiration from and to drive discussion.

Ambrose: One of the things that I loved was your treatment of MVPs as prototypes. “P” is for both Product and Prototype, right? I also liked thinking about MVPs as more of an MVF—Minimum Viable Feature, if you will.

I think the concept of Minimum Viable Product is challenging for new and potentially innovative products.There is the concern about competitors poaching ideas before you can get your full value into the market, but maybe more so there is the concern of being too minimal—not having enough value or just missing too much, and so exposing yourself to the potential for being prejudged by the market/users.

Do you have any advice for figuring out the Viable part?

Jeff: In our work, we define MVP as the smallest thing you can do or make to test your hypotheses. Sometimes that’s a workflow and sometimes that’s a feature. The scope of the experiments you run to test your MVP’s doesn’t have to yield statistical significance– just enough direction to let you know if you should continue exploring this path. This will inevitably require you to expose your work to your market.

Is there risk of having your idea poached? Sure, but it’s small. And even if it is stolen, that’s simply further validation that you’re on to something.

Ambrose: You advocate for involving the whole cross-functional team in research instead of having a dedicated team focused on research. When do you see this approach not working for product teams, and do you have any suggestions for maybe meeting halfway?

Jeff: The fastest way to gain insight from customers AND to build team-wide shared understanding of the customer and their needs is through collaborative discovery. That being said, there will come a time in the project where people must return to their core competencies at which time, reducing the number of people actively running the research is fine.

This does not, however, excuse the rest of the team from ignoring the findings of the ongoing research activities, nor should it keep them from being invited to continually participate.

Ambrose: In Chapter 7, you say, if “you work on packaged software, or embedded software, or deliver software to an environment in which continuous deployment is difficult or impossible, Lean UX may not be a great fit for your team.” As someone who has worked in such environments, I don’t like this answer.

Have you thought any more and/or discovered ways to bridge the gap to a more Lean UX approach for those sorts of environments?

Jeff: The concern here is that you don’t get to continuously improve the product. You get, for example, an annual release to correct and improve the experience. Of course you can still use many of the Lean UX techniques to build shared understanding and to inform the existing release cycle and plan and nudge the product in a more accurate direction, but until you can launch actual software into the market, the quantitative side of the puzzle will be missing.

Ambrose: In Chapter 8, you say:

“For some designers, Lean UX threatens what they see as their collective body of work, their portfolio, and perhaps even their future employability. These emotions are based on what many hiring managers have valued to date—sexy deliverables. Rough sketches, ‘version one’ of a project, and other low-fidelity artifacts are not the makings of a ‘killer portfolio,’ but all of that is now changing.”

What is the evidence you see for that changing?

Jeff: For better or worse, you’re seeing job descriptions now for “lean ux designers.” I know from our hiring experience what we’re interested in is the story a candidate can tell about their contribution to a project and how they solved challenging problems.

Other evidence has been largely anecdotal from conversations with hiring managers who are not impressed by a wireframe deck. They want to know the thinking behind the straight lines and drop shadows. That’s where the real insight lies.

Ambrose: What are you working on now that you feel is important to advancing the practice of Lean UX?

Jeff: The most recent thing that I’ve been working on and pretty pumped about is Lean Day: West (www.leandaywest.com). Would love for your readers to know about it and attend if they can!

Ambrose: Lastly, if there was one thing that didn’t make it into the book but that you have learned since and would now add, what is it?

Jeff: One thing we focus on a lot these days is transparency. Working in a lean way is new to many organizations as well as the managers in those companies. Change is always scary especially when other bosses are asking the same questions they always have.

If you’re trying these new methods and want to do as much as you can to clear the path ahead of you, be transparent. Make sure your colleagues and your managers know what you’re doing, what’s going well, what’s not, what you’re learning and what you’re planning on doing next. Make it public. Use monitors or printouts all over the office. Hold demo days and invite everyone (free food helps).

The more people know what you’re up to, the more interested they’ll be. In addition, the more informed your managers will be–which gives them comfort–which keeps them out of your way.