Agile + UX: (un)Synchronizing UX and development
On “Six strategies for more agile user experience,” Dave Nicolette left an awesome comment. So, awesome, instead of responding there, I’m responding in a new post.
Unsynchronizing UX and development
Dave makes a good observation about how I advocate UX be unsynchronized with development:
A comment by Dave Nicolette on Six strategies for more agile user experience
What you call “Synchronize UX with development” actually strikes me as unsynchronizing them. A basic goal in an iterative agile process is that a work item is delivered in the same iteration in which it is started. This doesn’t mean the same iteration in which the work item is defined (that is, added to the Product Backlog); it means the iteration when work is started on it. Many agile teams track a metric called story cycle time… it simply means the average number of iterations it takes for the team to complete a story. When that number is above 1.0, the metric signals a problem. The strategy you describe … forces story cycle time to be greater than 1.0 every time.
Dave is correct: doing the UX work one sprint ahead of development is not really synchronized. They’re one sprint out of phase, and they should remain synched one step out of phase.
However, this isn’t a problem.
Keeping UX and development in synch assumes engineering and design are the same kind of work. This isn’t true. Holistic, contextualized user experiences require time to frame and synthesize the experience. This synthesis happens long before you can start coding features.
If story cycle times over 1.0 are a problem, then adjust expectations so story cycles should be over 1.0, or move UX to separate stories in a previous sprint.
To create good products, you need time to think about and iterate on the user experience, follow its rabbit holes, and communicate the experience to both product owners and engineers. There’s a lot of UX work that happens prior to sprint planning and the backlog.
Separate, but equal
The more I think about it, the more I think you must move user experience to separate stories and separate sprints. The story of how something is designed is different from how something is developed. Stakeholder participation is different, the process is different, the deliverables are different. Even the expectations are different.
If agile is a way to manage engineering, it’s silly to assume it would be a good way to manage the user experience. Design and architecture can’t be managed using agile methods. UX and engineering are on the hook for different things.
That’s kind of a 360 from where I thought I was on this topic. I didn’t think I’d end up here, but I think that’s the where the path leads: User experience can help agile teams build better experiences and better products, but you can’t manage design and architectural activities the same way you manage engineering and build activities.
Don’t ask me. Go ask Anders.
I met Anders Ramsay years ago at Asilomar. He’s a smart guy. This year in Memphis, while we moseyed from Beale up to the Peabody—ready to call it an early night—Anders persuasively explained some of his thinking on agile and UX.
I’m pretty sure Anders would disagree with me. That’s why you need to watch his presentation, “Agile for the rest of us”. It’s packed with good thinking about how agile teams work together, where they work, and how UX does and doesn’t fit in. He published a slidecast of the presentation on his blog.
Peter Drucker’s been ringing in my head for weeks now: “What gets measured gets managed.” Agile doesn’t measure experience.
I think that’s the million dollar question: how do agile development methods measure user experience?