I just hosted my first webinar, talking about the relationship between Agile development and UX. It was a good talk, but to someone used to live audiences the experience of speaking out into the great ether is slightly unnerving. I made like an old-time radio announcer (do they still have those?) and it was fine.
I talked about the relationship of Agile to UX, something I was tossed into about 8 years ago and have been working on ever since. I wish I could say that things have changed a lot in that time, and I guess they have, around the edges, but for a lot of teams the story hasn’t changed that much. Sure, Agile has matured a lot, and we have more UX designers working with Agile teams than ever before. But I’m still hearing the same story too often—teams applying Agile in a way that’s both too rigid and rules-based, while simultaneously failing to implement the core elements of Agile. As a result, they miss many of Agile’s benefits.
The three core elements of Agile, as I see it, are: develop in short increments; test each increment with real users every sprint; and iterate based on what you found out. Of the three, only the first is really widespread. Most teams I hear from are now implementing in small stories organized into short sprints pretty successfully.
The second element of Agile is much harder to achieve. Getting good user feedback is always a challenge. The Agile literature doesn’t help—many of the standard texts don’t recognize that getting good feedback is a problem at all. They tend to prescribe an end-of-sprint demo, assuming that’s enough to check progress. So even though UX designers have the tools needed to provide valid user feedback, often the Agile experts don’t know to ask for it, or value it when they get it.
And the third point is also hard for many teams to achieve. This should be surprising—isn’t iteration the whole point of Agile? But I know a lot of teams that treat it as a major disruption if user stories have to change from the plan they came up with at the beginning of the release. Rather than treat change as expected, they operate from their old habits. If every story doesn’t get implemented in the sprint it was planned into, they (or their management) think they’ve have slipped and that’s bad; if they have to introduce new stories halfway through or re-implement a story that’s been rejected, that’s rework and that’s bad.
Does any of this sound familiar to you? Is your organization doing some of this? If so, be comforted to know that you’re not alone. And there are ways to talk into the organization so that a team that’s trying to be Agile can hear that they can be user-centered at the same time.
The main content of the talk was to discuss ways to do this. I don’t have the space here to cover everything, but the key is for UX people to learn the language, values, and mindset of Agile and communicate UX needs and contributions using that language. This can be done because Agile development is naturally user-centered—it is naturally driven by an understanding of users, and guided by user feedback.
For example, Agile proponents have developed the concepts of “architectural spikes” and “programmer’s holidays” to make time to step back and think about aspects of the whole system coherently, freed from the constant grind of quick sprints and small stories. UX designers can build on these concepts to make room for coherent thinking about the user experience: “We need a UX design spike to consider that new feature area.” Similarly, Agile developers talk about “refactoring” as additional work needed to keep the code structure clean (architecture on the fly). UX teams can talk about UX refactoring to normalize and simplify the UI across the whole product—with the natural implication that the refactoring will touch many different interfaces across the system.
Or again, Agile has developed a number of (engineering-centered) methods of dealing with Agile’s limitations. “Epic” stories, for example, provide a way of thinking about the design more systemically and coherently than is allowed by single user stories. UX designers can borrow the concept to talk about stepping back and approaching the high-level design of the system as a coherent whole. And the concept of a Sprint 0/Phase 0 to get started is becoming more accepted in the Agile world.
Those are just some of the concepts that I presented in the webinar. If they sound interesting, give me a shout—and I’d love to hear from webinar participants about your reactions and thoughts. I’ll be writing in more detail about the individual ideas here. And there will be more webinars in the future—send me a line and I’ll make sure you hear about it!