Part III. Making It Work
From 2007 to 2011, I led the UX team at TheLadders, an online job board based in New York City. During my tenure, the company began its transition from Waterfall to Agile. It was a developer-driven effort, but the company recognized that unless UX was included, the transition would fail. It was up to me to figure out how we would integrate Lean UX with this new style of working. In 2007, if you Googled “Agile UX,” the results page would be littered with blog posts, articles, and case studies that documented failure and frustration. The main themes seemed to be cries of “Agile sucks!” and screeds claiming “UX has no business working this way.”
Undeterred, I continued to search for collaboration and integration ideas. I came across Lynne Miller and Desiree Sy’s “staggered sprint” model—in which the UX team works at a sprint ahead of the developers—and gave it a try. Although it was helpful in getting us to think about our work in smaller bursts, it did nothing to increase collaboration between the disciplines or to reduce wasted effort on specs for features that would never be built.
We were convinced there was a better way, so, like good Agilistas, we continued to tune our process. After several months, I felt like we’d hit our stride. We had increased collaboration, started producing fewer documents, and increased our customer validation efforts. The internal cries of “Agile sucks” and “I hate this” had also subsided. I was feeling pretty good about our little team.
One Monday morning I walked into the office ready to start the week and found the diagram in Figure III-1 printed out and placed neatly on my desk.
It turns out things weren’t as rosy as I’d thought. My team had gone off and held their own retrospective (read: venting session) and produced this diagram as their “deliverable” to me. It caught me a bit by surprise, but as I dug into the details of the document and discussed the key pain points with the team, the holes in our process became evident.
Look at the diagram: if you’ve tried to integrate Agile and UX, perhaps you recognize some of these problems. The team felt there wasn’t enough time to do “gold medal” work. They felt their work wasn’t mission-critical. They felt that they didn’t have time to iterate. The list goes on. When I show this diagram to other teams struggling to integrate Agile and UX, there are always plenty of rueful smiles of recognition.
Finding this diagram on my desk was a humbling experience, but it touched off a dialog and engaged the learning process that is at the heart of Agile approaches. The dialog allowed us to begin a process of discovery that ultimately resulted in the cross-functional collaboration that made our Agile process a success, as described in Part II.
About Section III
How can you integrate the Lean UX process into your organization? That’s the question I’ll answer in Part III.
In Chapter 7, I’ll take the tactics discussed in Part II and show you exactly how they fit into a typical Scrum process and how they make it more effective.
In Chapter 8, I’ll dig into the specific organizational changes that need to be made to support this way of working. It’s not just software developers and designers who need to find a way to work together. Product managers, project managers—in short, your whole product development engine—is going to need to change if you want to create a truly Agile organization.