So much has already been discussed about merging the seemingly unmergable: Agile, a software practice based on not even knowing what you will deliver when you start, but delivering it in small, validated, increments, and User Experience Design, which, like every design practice, is about delivering a complete, though-out, lovely, all-encompassing solution. Endless discussions in Agile about which practices to forget and how to convince your client to trust you without a set endpoint, and case-study after mock-up in UX circles about how micro-interactions are a place to shine and create cohesion between the end-to-end service experience. All I have to add to this topic are actual experiences of doing UX in Agile environments.
Agile always proposes People Over Procedures, so of course there isn’t one good recipe for making good UX happen in an Agile team. Here is my first example of a project that I thought went well.
Sprint 0 / Sprint Ahead
This was an agency project, in which the client did indeed have a specific goal in mind. While Agile classically does not like to have an end point truly fully specced and specified before you start, you can’t just tell a client “Give us your money and we’ll see what we will deliver at the end.” It requires a level of trust you just will not get at the start of a relationship. (It’s also counter-intuitive to any other transaction ever: give me your money and let’s see how much cheese I can give you. Give me your money and I will let you know when your bathroom is finished and what is in it. Give me your money and I may give you that much of a massage, or not. Yes, every project has unknowns and cost-overruns, but it is only in software that we so have no clue what we are doing that we cooked up a methodology where we explicitly state we are not quite sure what’s going on, but we’ll all do our best. And then try to sell it to clients. And it is considered best practice based on the bad results of previous methodologies. Software is truly terrible to make.)
This project had very high commercial value, and thus a lot of heavy weight stakeholders. While Agile is supposed to come with taking risks in releases and fixing them quickly, the client would rather first use the considerable star power they had hired to do Digital to give us in the agency good feedback on everything we did. We therefore made the following choices:
- The Design team consisted of a blend of digital graphic designers and user experience designers. Design would be one sprint ahead of Development. This required the Coding & QA team to trust us in Design not to finish a sprint with a design they could not possibly implement. We tried to manage this risk by including them in the scoping and pointing of Design sprints, and by giving them their own pointing and scoping process in their sprints. Looking back I would say that took a really big leap of faith from Development, and I am very grateful they did it, and that Design honored that leap.
- Sprints were three weeks, with a demo to stakeholders at the end of every week. The demos at the end the weeks were: sketches, which the stakeholders would help narrow down, for week one, further worked out half-comps for week two that could be further critiqued by the stakeholders, and fully finished and annotated comps in week 3 that the stakeholders had better sign off on at that point. Delivery management very quickly learned how to elicit the right feedback at the right time to keep sprints within their boundaries and not have to do emergency work after the last demo of a sprint.
- Before the first real sprint, Design was given a sprint to experiment, concept and research. While the graphic designers spent that time concepting and exploring the brand, we in UX explored various aspects of the funnel by sketching the extremes of how clients might make selections on various platforms, mocking them up in Axure, and formally user testing them. By involving the client in this phase, we created a shared understanding of the truisms and of what was actually false about retailing in this sector, and learned to work together. It is true that basically the client paid to receive knowledge they probably already had in their customer experience divisions, but it was only by exploring this area together, and in new ways from our fresh eyes, that we together could push the state of the art further with confidence. Erika Hall wrote a great article about how this works.
- We had also negotiated a week of international user testing before the last sprint so we could do major course correction if necessary. This did put significant pressure on the first two sprints to deliver something that could be quickly be made interactive to be tested (and yes, being responsible for that to happen did give me some bad nights) but it totally paid off when we could have really productive discussions about commercial realities vs user satisfaction regarding the amount of steps in the funnel, now with actual data instead of the guesswork and intuition during previous design.
(Although it pains me that even after this success, too many people in the agency considered user-testing so negotiable with clients such that I kept having to put my foot down again and again.)
The result was a high-quality front-end design and implementation that could be dropped in and wired up by the client to their back-ends.
Because Development was at the story-pointing meetings for Design, they had their say early and could help us create something they could deliver. Still, there were some moments were Design, and specifically UX, was called over to help out with something that simply could not be implemented as designed in the time available, and required re-concepting on the spot. But hey, real-time design is always my favorite.
This was a very specific structure for a new effort, with no Business-As-Usual to work from, and heavy on the stakeholders and experts. It went well enough that we stayed the course for the second brand we were contracted to design an experience for.
In my next post, I will discuss Agile and UX working together on a continuously developed project, and then a post on how Agile requires UXers to think in versions way far ahead.
Ask The UXer 