Lean UX, 3rd Edition

Chapter 16. Integrating Lean UX and Agile

Ask anyone at any organization what the default way of working is for them, and the answer will invariably be “We’re doing Agile!” Follow that question with “And how’s that working out for you?” and in most cases they’ll raise their hand and shake it from side to side in the “meh, it’s just OK” gesture.

Agile was born of developers, 17 of them in fact, representing emerging ways of working that had emerged from their frustration with older engineering processes and the unpredictability of software development. At a weekend gathering in Utah in 2001, these software developers put together a series of principles they called the Agile Manifesto.¹ If you haven’t read it (you should, it’s short), you’d be surprised to find there isn’t much prescribed “process” in the Agile Manifesto. There’s nothing in there that says, “You shall stand up every day at 9:15 with your team” or “You will work in two-week cycles called sprints.” Those are techniques taken from specific Agile methods, like Scrum and Extreme Programming (XP), methods that were invented by many of the folks who came together to create the Agile Manifesto itself. Instead of capturing specific practices, the authors of the Manifesto listed values and principles for highly collaborative, customer-centered software development. The most compelling line in the entire manifesto—and in our opinion the basis for true agility—is “[We value] responding to change over following a plan.”

That’s ...