Anders Ramsay was really an unknown entity for me as I got to day three. Like the other two workshops, this one was based on his book of the same name, though this one is yet-to-be published in 2013. The nice thing about Anders’ workshop is that, where the other two focused on ways of improving existing designs or those in progress, Designing with Agile was really about turning traditional initial design approaches on their collective heads.
While putting everything in his approach to work in my present environment would be virtually impossible, I made several small discoveries that I think I can begin to use in future projects. I say making our process completely agile would be impossible because, a) going there has to be a team sport, with everyone on board, and; b) it needs some level of top-down support and drive to happen. Each time I build a new large requirements document for a new application, I vow I will move from needs analysis more directly to sussing functional specs out of a more rapid, iterative prototyping process. However, it simply doesn’t seem to happen, in part as some team members have a strong penchant for overly detailed requirements before they begin doing anything, and in part because the rest of the business often can’t take the time to go through multiple, rapid group sessions to collaboratively design features. But I digress, and I know I can begin doing some of my UX work using some of the techniques from this workshop.
As with Lou’s session, I’ll include a presentation below – the exact one Anders used, in fact – that demonstrates what we covered, then I’ll outline a few things that were key for me from the day.
The Agile Manifesto
Written some time ago (the date escapes me) by several software developers, the Agile Manifesto has four key points:
- individuals and interactions over processes and tools
- working software over comprehensive documentation
- customer collaboration over contract negotiation
- responding to change over following a plan
Whereas most of us still produce software and web designs via a standard waterfall approach, Agile says you need to become more collaborative, where regular and meaningful communication lead to product iterations much more quickly. Make the documentation appropriate for the project – nothing more, nothing less. I guess my take on this is to try to inject it where I can (for example, using brainstorming and design studio techniques very early, to create UX elements more rapidly), but that completely changing how we develop by expecting programmers to do many, many more refined alpha cuts earlier and without comprehensive documentation, is a much longer sales pitch. I’ll keep making it though, because I personally find constantly revising a large requirements document from the earliest stages of a project to be a complete waste of time, and largely a Cover-Your-Ass (CYA) exercise. It pretty much never gets used later, and it’s just as easy to use a solid prototype with a good interaction spec to determine if, for example, user testing demonstrates it’s meeting client and user needs.
Relay race versus rugby scrums
I think the comparisons between relay running and waterfall, versus a rugby game and agile, were very apt for me. A relay team works together, but each member still does their own work in isolation and most communication happens via the handoff (baton OR documentation). Whereas, in a rugby scrum it’s intensive, continuous and direct and you cross the finish line more frequently together (points OR iterations), until you eventually win the game.
Lean versus Agile
I often tire of hearing the terms Lean and Agile used interchangeably, but in all honesty I’ve had a hard time myself, separating one from the other. This probably comes from the fact that in normal language, they can mean largely the same thing. If you’re like me, you immediately think quick and slim. It now makes more sense to me to think of Lean UX as the kind of design approach a startup will take, where they move much more quickly to get a somewhat imperfect product to market – it’s a necessity to prove a concept. Agile UX, then, is more a paradigm shifting concept. In a nutshell, Lean asks if we’re making the right thing, whereas Agile is about how we make it, and becoming more collaborative to deliver better products more quickly. In both cases, if you’re doing it right, you’ll develop less documentation (but the right documentation for the situation) and become more productive.
We ended up doing more collaborative group exercises in this workshop than the other two, in fact once we discussed definition of Agile and relative advantages over more traditional processes, the day played out with mostly group work. I guess that’s to be expected given the subject. However, I also thought the workshop might have benefited from a deeper dive into one or two exercises, with a little more digestion space. Any one of these could, and perhaps should, take several hours, as opposed to the 15-30 minutes we gave them. Throughout the paragraphs below, I’ve bolded and italicized the naming conventions for the various Agile design techniques we used.
While the exercises did give me the flavour of doing some key Agile UX group work, they felt a little hurried, and I sensed most of us had a little information overload. And overall, trying to cram as much as we did into the day, meant the Q&A session at the end took a bit of a hit. We couldn’t explore whether the workshop answered the questions we all wrote down about Agile UX (and dotvoted into key groupings) at the beginning of the day. I thought doing this was a great exercise and glossing over it at the end diminished its value IMHO.
After discussing collaborative project chartering briefly, we jumped into persona development. Personas begat user stories (again, covered at a very quick pace), which then begat storymapping. I liked the way this process flowed, and again, just wish we could have delved a bit more deeply into storymapping, as it’s a valuable group exercise. I loved writing as many features/stories as we could in a three minute timebox and then moving into a card chunking exercise to begin shaping them into a story. Once we had various stories mapped, we used dotvoting to refine them into one agreed upon storymap.
As we moved our storymapping into a UI exploration exercise, I was a little relieved to hear Anders talk about the fact that these kinds of rapidly developed design concepts really aren’t dev-ready. If you’ll recall my earlier point that expecting developers to move into rapid alpha app builds and embrace Agile, then you’ll know I believe they also need a more developed piece of documentation to hang their hats on. It’s essentially a process that goes from extremely low fidelity feature stories to medium fidelity UI explorations, through to higher res developer stories.
While I still don’t think the process would satisfy some devs I know (though, Anders does admit getting everyone to embrace this approach is a broader org shift), we used a design studio technique to refine the storymapping exercise into an application flow with rudimentary layout and interaction approach. I found this worked remarkably well. Essentially you decide on an area of focus and begin to iterate, with everyone sketching out interfaces in short timeboxes, perhaps for an assigned part, then voting, then repeating. While a little bit longer exercise would have been a joy, it was easy to see how quickly you could obtain pretty good design results by using a design studio approach. This may be one of the key things I try on my next larger project. The key to getting developer buy-in, from my perspective, is that they are sitting around the table as one of the key stakeholders and are doing this activity with you.
Effectively, you do most of the design activities in fairly rapid iterations, with everyone contributing and use dotvoting or a similar technique to continually refine. Once you’ve done so enough, you can do a storymap refresh and you’ll eventually get to a point where a developer can use what’s been produced to begin building early alpha apps.
Who (or what) is your MVP
While it may indeed be your Most Valuable Player in an Agile UX design approach, in this case we’re talking about Minimum Viable Product. This is another concept that comes up continually at work as we often try to deliver the core element the client wants, without building all the stuff they’d like but don’t really need. My own example is a project I’m currently working on that began life as a somewhat bloated mini-CRM application. To enable us to build it, we’ve scaled it back to what has effectively become a mailing list subscription notification system. It’s removed all the management features to become automated and still do the core thing the client wanted.
However, as opposed to long development cycles, once you’ve gone through the UX crowdsourcing I’ve outlined above, you need to go through a relatively brief prototyping and coding exercise to get something usable out the door. It can be hard to get your head around this, when your normal approach is to get something as close to perfect as you can before delivering, as this is about getting a basic thing that works in the hands of users as quickly as possible – a Minimum Viable Product. You’re not necessarily finished for some time, because as with the design process, you’re likely going to iterate this into ever-more complete applications.
Anders spoke through a number of Agile approaches, including Painkillers (killing big pain points with the least amount of effort – well connected to the other two workshops), Fast Money (removing features the client isn’t paying for to kill bloat), Turk It (using manual backend processes that appear automated to users), Go Ugly Early (functional but hardly pretty), and Fake It ’til You Make It (typical start-up approach to appearing to have launched and gauging interest/feature desire while still developing). He also briefly covered the lifecycle surrounding sprints, but the core point of the workshop was how to use Agile processes in UX design, so these points were very high level, and more about project management than design.