found drama

Jeff Gothelf’s Lean UX (O’Reilly, 2013) is, to my eyes, an outline for the principles of the Lean UX philosophy, and a handbook for integrating it into Agile teams. “But wait,” you ask, “what exactly is Lean UX?” A serviceable definition from the text:

Lean UX is the practice of bringing the true nature of a product to light faster, in a collaborative, cross-functional way that reduces the emphasis on thorough documentation while increasing the focus on building a shared understanding of the actual product experience being designed.

“But wait,” you continue, “isn’t that basically Agile and/or Scrum?”

And I say: “Maybe?”

frame of reference

Before I dig into Lean UX and its teachings in earnest, I feel it’s necessary for me to briefly outline the frame of reference that I had when I approached this book.

I am an engineer on Scrum team within a company practicing the Scaled Agile Framework (SAFe). The company has been practicing SAFe for a little over a year and a half; the Scrum team I am on is a little over a year old. ¹ As an engineer, I tend to specialize in user interfaces and front-end code. I also did a nine month tour-of-duty as our team’s ScrumMaster. ² I have seen Scrum work well.

So when I heard that Lean UX was making the rounds at the office and some teams would be piloting the practices proposed within, I was (1) curious but also (2) skeptical.

“What,” I asked, “could Lean UX offer us that we’re not already doing?”

Lean UX + Scrum

More or less right off the bat, Gothelf aligns Lean UX almost perfectly with Scrum by giving us the following bit of provocation:

The biggest lie in software is Phase II.

It isn’t so much that this is needlessly provocative, as it is illustrative about the real life attitudes in software development. “Phase II” does not exist. You release, and if you’re organization isn’t dysfunctional, you learn and iterate. Lean UX is big on this, but the idea isn’t new to Lean UX. Two of the four cornerstone statements in the Agile Manifesto are deeply entwined with this idea; you know the ones:

Customer collaboration over contract negotiation
Responding to change over following a plan

There are many criticisms of Agile out there, and many of them focused on the Scrum approach in particular. One that I’ve heard a few times that seems relevant here goes something like: “Scrum is very developer-focused. It doesn’t have a brain. Where’s the room for design?” ³

The implication is that despite constant iteration, Scrum leaves no room for refining things, that design and user experience are not valued, that developer-centric Scrum enables developers to prioritize “the wrong things” for refinement. And while Scrum allows developers to have some influence over the contents of a given sprint, it also emphasizes customer (and/or business stakeholder) collaboration, and so if the development teams are focused on the wrong things then those conversations need to happen. After all, Scrum is about continual improvement.

Which brings us back around to Lean UX making the rounds. At this point we’re a year-plus into our “Agile Transition” and although it has brought us a long way from where we started, we are seeing some places where we could do better. We don’t see this as a failing of Agile; if anything it’s a great success: we looked for places to improve and recognized them. And when we looked to take action on those potential areas for improvement, Lean UX stood out as a great candidate.

What we know of Lean UX positions it as a good guiding philosophy to get us where we want to be. And where we want to be is not just a bunch of top-notch engineers; we want to be thoughtful designers, too.

Lean UX: the good

The short version: Lean UX is focused on continuous learning, which makes it naturally compatible with Scrum ⁴, and basically layers a couple of elements on top of it, the best of which is “Design Studio”.

I realize that I keep mentioning that Lean UX is all about “continuous learning” and/or “continuous improvement” — but it’s the absolute truth. The foundations for Lean UX that Gothelf lays out are predicated on asking data-driven questions and measuring everything you release. There’s an easy argument here that Scrum already prescribes this but the truth is it doesn’t. Scrum would have us go and seek feedback, and Scrum would have us incorporate that feedback into our next iteration, but Scrum does not command that we as data-driven questions. In Scrum, asking those kinds of questions is implicit, but with Lean UX, it’s a mandate. Lean UX insists that we run tests, that we conduct interviews, that we collect and analyze our application usage metrics. And with Lean UX, it isn’t enough to just have the data, you must respond to it, you must iterate. ⁵

The way I read it, the major way that Lean UX brings this spirit of “measure-assess-respond” to sprints/iterations is through a new process: Design Studio ⁶ for collaborative design. One way of looking at Design Studio, is as a new ceremony that it adds to Scrum — except that whereas Scrum ceremonies like backlog grooming can wind up feeling like “meta-work”, Design Studio feels like real work. Design Studio does a fantastic job of including everyone, of drawing out the best ideas, and of building team consensus around a set of things that everyone thinks will really work.

And that consensus is very important because it makes Design Studio emblematic of another very important point of Lean UX: banish “heroes”. ⁷ Again: Lean UX is about consensus building and data-driven decisions. Relying on “heroes” (whether they’re designers, engineers, or some “visionary” — doesn’t matter) just disenfranchises everyone else on the team. You wind up with lower morale, a weaker sense of “ownership”, and a poorer understanding of the product. Because of the emphasis on data-driven design, Lean UX urges team members to get their egos out of the design process. Questions go from “Do you think this looks good?” to “Will this help decrease the bounce rate by 20%?” ⁸

Lean UX: the critical part

After reading Lean UX, I’m largely positive on its foundations and overall philosophy. The little bit that I’ve been exposed to it in practice, it seems to be working well — but I’ve only seen a few bite-sized chunks, and aside from doing my damnedest to shoe-horn Design Studio onto my team, I’m not presently on a team that’s actively practicing Lean UX. So that being said, most of what I have had to say so far is largely academic; thus my criticisms are also largely academic. Just the same, here they are:

First, it’s hard to get a grip on how well Lean UX will play out in larger organizations. Most of the tenets seem geared toward smaller teams. And while SAFe really tries to orient an “enterprise” as a confederation of small, independent, agile ⁹ Scrum teams, the friction of large quarterly plans and release trains is still present. How to reconcile Lean UX’s mandate for tight iterations and micro-pivots based on recently collected data with those larger plans? There’s some suggestion in the text that this is manageable, but that doesn’t make it easy to imagine.

Second, despite the fact that Lean UX provides a “place” for UX Researchers and Interaction Designers within Scrum, it’s not always evident that it creates a “place” for one on each Scrum team. This is probably just fine; SAFe places user experience design at the release train level — a valuable commodity shared across collaborating teams. But as a text, Lean UX doesn’t seem to advocate for UX practitioners splitting time across teams.

My last critique is that the base template for Lean UX “hypotheses” seems… too affirmative? I can’t help but feel like the phrasing of the hypothesis statement template implies that you already know the answer and you’re just looking to get the data to back it up. Maybe this is an old school bit of training leaking through from my psychology undergrad days, but aren’t you supposed to introduce an experimental condition with the assumption that there’s no difference? Not that you’re not not-so-secretly hoping for a specific outcome to be demonstrated by your experiment — but still. That being said, if you can start with a good ol’ fashioned Agile User Story and build a solid Lean UX Hypothesis around it, you’re still better off than you were with the user story alone.

Conclusion

Lean UX provides a great introduction to its principles and foundational practices. If you’re already practicing Scrum, Lean UX is a natural progression. It adds a couple of excellent ideas that far outweigh the handful of nit-picky concerns that are easily flushed out with some discipline and self-learning. Design Studio alone is worth the price of admission. If you’re developing products, you want to at least have a look at Lean UX — it’s almost criminal to pack that many good ideas into a book that you can get through in an afternoon.

• Buy it now on Amazon.com; or
• get the book directly from O’Reilly.

Disclosure: I received an electronic copy of this book from the publisher in exchange for writing this review.

1. It’s also worth pointing out that for 3 years prior to that Scrum team’s formation, I had been on a series of teams that were part of one “Agile pilot” or another. In other words, I’ve seen Agile done a number of different ways, with varying degrees of efficacy.[↩]
2. Got my certification and everything.[↩]
3. If I’m being completely honest, I tend to call bullshit on this criticism. Scrum itself doesn’t have any prescribed ceremonies to deal with design, but disciplined teams that are dedicated to their craft and care about the products they’re producing will make “good design” happen.[↩]
4. Seriously, there are many annotations in my Kindle version that basically say: “JUST LIKE SCRUM!”[↩]
5. Two minor nit-picky points here though: (1) that a high-functioning Scrum team would be doing this anyway, regardless of whether they have a ceremony or systematic mandate for and/but (2) I also feel like this infinite cycle of “measure-iterate” is much easier for small teams (i.e., start-ups) that don’t have the weight of a big quarterly backlog of enterprise portfolio items backing up behind their infinite micro-pivots. (Granted, you could use my own line against me here re: “high-functioning Scrum teams” re: that latter point, but let’s engage honestly here: a start-up is a different world from a larger established company.)[↩]
6. I won’t go into a ton of detail about Design Studio in this post, but I’m pretty enamored with the process. It’s such a simple approach and yet it’s incredibly powerful, and the times I’ve had the good fortune of being part of a Design Studio session have all been very rewarding and enlightening. For more information, check out: “UX Meets Agile: Design Studio Methodology” (Dubakov, 2011), “UX & Collaboration techniques” (founderswiki.com), and “The Design Studio Method” (Warfel, 2012; video).[↩]
7. ”Banishing heroes” is another one that’s true of Scrum, but let’s gloss over that little point for now.[↩]
8. Again: compatible with Scrum, but not built-in to Scrum.[↩]
9. That’s “agile” with a lowercase “a” there.[↩]

About Rob Friesel