Agile 2009

First, a sad fact:

• Trips I've made to Chicago: 2
• Trips I've made to Chiacgo where I eat Chicago-style pizza: 0

I’m hoping to make a third trip to rectify this injustice, but in the mean time, I wanted to share my experiences this past week at the Agile 2009 conference in Chicago. I had a good time, learned a lot, met some great people, and joined in with 1300 other geeks in cursing the lack of both cell coverage and wifi.

Keynote: Alistair Cockburn

I missed the first day of the conference, so my trip kicked off with Alistair Cockburn’s keynote on Tuesday. Alistair made quite an entrance with a bagpiper, and kicked off his talk with a recitation of Mark Antony’s funeral speech from Shakespeare’s Julius Caesar. He started with the assertion that Agile practices are now not only mainstream but are becoming the default practice for many. As a result, it’s more interesting to look at new and emerging practices than it is to dwell on the “core” ideas in Agile. He identified four emerging practices:

• Software development as craft
• Software development as a cooperative game
• The use of lean processes (from manufacturing)
• Design as knowledge acquisition

Craft: Alan Cooper also talks about software as “craft,” but I’m not sure I understand what he or Alistair mean by this. I think it means that software development has come to be seen as low-skill, assembly-line process, rather than a creative one. As a result, we need to re-focus on developing skills and techniques, and then developing our ability to synthesize and create new skills and techniques.

Cooperative Game: Software development can be seen as a cooperative game, where teamwork, good communications, and good strategies are required in order to achieve the goal of the game. However, not all software projects have the same rules, so a good part of a project consists of learning the rules. Furthermore, not all games are goal directed. Some are open-ended (IT systems development), and some are infinite (product line management). Recognizing which kind of game you’re playing can help you identify the appropriate strategies to employ.

Lean Processes: Agile process geeks have been paying close attention to the manufacturing process management methodologies like Kanban for inspiration for evolving Agile practice. These methods emphasize continuous flow through a development team in order to prevent blocking progress or creating bottlenecks.

Design: In a later talk, Jeff Patton said that Agile and UX have two different ideas on what “design” means. In UX it means figuring out what to build, in Agile it means figuring out how to build. I’m not sure which meaning Alistair was using here, but the message I got was that we need to optimize risk reduction vs. creating value.

The Big Picture & The Glass Wall

I went to two talks on creating product vision; Desiree Sy from Autodesk talked about the importance of a “big picture” for an Agile process, and Matt Roadnight and Una Walsh talked about a specific method they call the “Glass Wall.”

Desiree Sy: Doing experience design within an Agile team can lead to overemphasis on tactical design decisions, without regard for creating a cohesive design. We don’t want to get bogged down in big design, but Desiree made the point that big design and the big picture aren’t the same thing. We can create the big picture without a lot of upfront work. This happens at three levels: Product, Release, and the Sprint (Iteration).

At the product level we create a vision by answering two questions: who it’s for, and what it is. We can also create high-level principles that define the characteristics we want for the product. These vision statements and principles can be used to guide prioritization and acceptance of features in the product backlog. At the release level we focus on specific business goals. These goals help us select and re-prioritize features from the product backlog into a set of features for a given release. At the iteration level we focus on creating a definition of “done” for each story that aligns with our release and product visions.

Matt Roadnight & Una Walsh: The “Glass Wall” is a product vision documented in an experience map, showing touch points between the user(s) and the product. By incorporating information about the user, including their environment and emotional state, we can map out a narrative of the interaction that can identify areas for improvement and innovation.

The map starts with the users needs, goals, aspirations, and concerns. In essence, we’re building a persona, so we also want to add in some details to make this user real. Obviously, this is best when based on research. The next step is to tell this person’s story as it relates to the product. We start with the challenges the user faces in trying to achieve their goals. Each of these challenges is a story that we can map out, but we can only focus on one at a time. In our exercise, we focused on a grocery store, so we mapped out a day in the life of a suburban working mom. We then mapped out her emotional state at each moment in her day. On top of this we mapped out the touchpoints between our user and the grocery store — everything from making a grocery list, to cooking, to the actual shopping. Once we had the story mapped out we looked for places where we could better connect to our user, where we could make her day easier, and where we could improve the quality of the interaction.

Each of these connections basically becomes an opportunity to explore possible features and product ideas. In the end, the idea is to pick out the key features and ideas and create an experience map that defines the brand interaction for our product.

5 Users Every Friday

Tom Illmensee described his experience augmenting an Agile practice with user research by bringing in 5 users every Friday for testing. His team scheduled the users up-front, rather than on a week-by-week basis, in order to remove recruiting as a bottleneck, then figured out what to test based on the features they were implementing each week. The goal was to make testing part of their team culture, so they invited team members to each test as observers, and included the team in analyzing results. The practice removed testing as a bottleneck, but the planning and analysis (in addition to the design work) each week led to a good deal of fatigue.

I was really happy Tom shared his experience with this approach, since it seems like a great solution for Agile teams looking to make user feedback part of their organizational culture. I also appreciated that he was frank about the challenges they faced.

The State of Agile UX

Jeff Patton gave an overview of 12 emerging practices in Agile UX —

• UX as part of the product owner team
• Research, model, design up-front, but only just enough
• Chunking the design work
• Using parallel tracks for UX and development
• Buying time with complex dev tasks
• Cultivating a pool of users for continuous feedback
• Schedule continuous user research
• Leverage time with users for multiple activities
• Use the RITE method
• Prototype in low fidelity
• Treat the prototype as the specification
• Designers learning development skills
• Becoming a design facilitator

While I feel many of these are well established patterns rather than “emerging” practices — at least I hope they’re not new to too many people — Jeff’s talk was a great way to recap many of the themes from the UX stage over the course of the conference.

Innovation Games

Lane Halley and Luke Hohmann led us through an introduction to “Innovation Games.” While some of the games were less game-like than I was expecting, many were similar in approach to techniques I think

of as “experience mapping,” using various facets (time, usage, location, etc.) to map out how users interact with products. The goal is to gain insight into customers needs, and identify areas for innovation. I enjoyed trying a game for myself, and see a lot of overlap with Una & Matt’s “Glass Wall” approach and techniques such as collaborative sketching for facilitating both strategic and tactical design discussions.

An Agile UX Adoption Story

Lily Cho led us through the story of Liquidnet’s adoption of Agile during the re-design of their core product. Lily’s story was interesting because they switched to Agile after they had already completed an 8-month research phase, which provided their design team with a great deal of background research to draw on during the actual design and development process. The lessons her team learned —

• Be prepared for changes in role (they went from owners of the spec to facilitators)
• Leverage familiar practices and tools (don’t throw everything out all at once)
• Process change needs to happen iteratively
• Integrate agile process into parallel tracks
• Increase transparency by sharing parallel sprint activities
• Upfront research to inform later design
• UX is not just a discipline within the project

The last point in particular resonated with me. It isn’t just the UX role that owns the quality of the product experience, it’s the entire team. I’m starting to worry that using “UX Designer” as the name of a role within a product team gives everyone else an excuse to abrogate their role in creating a good experience for the customer.

LiveAid

One of the more ambitious sessions at the conference was a 3-day interactive design and development sprint to build an iPhone-optimized website for the Mano-a-Mano charity. The UX and front-end efforts were led by Todd Zaki Warfel, Joe Sokohl, and Jonathan Knoll (aka Yoni), who led participants through a brainstorming and collaborative sketching workshop based on research they’d done before the conference. Joined by a team of developers, they produced a website that raised over $4000 dollars over the course of the closing banquet.

I was an observer more than a participant, but it was both inspiring and tiring to watch the team design, develop, and launch the site in three days.

Keynote: Jared Spool

Watching Jared Spool is always great fun, and even more so when he’s got a ballroom full of developers rolling in the aisles after his (brief) rendition of Beyonce’s “Single Ladies” dance. Rather than recap the entire talk, which will hopefully be made available online, I want to emphasize a point I’ve heard Jared make before. In order for a company to produce a great product, three things need to happen:

1. Everyone needs to have a shared vision for the future
2. You need to watch your customers use your or a competitors product at least once every six weeks
3. The company needs to embrace failure as a learning tool

Future Reading

Outside of the sessions, I came away with a list of things to read up on. After the keynote, I’ve got Kanban and Lean Development on my reading list. Two sessions I missed out on, but I wish I’d attended were on Story Planning from Jeff Patton and Blitz Planning with Alistair Cockburn. Finally, I’ve got the book Influencer by Kerry Patterson in my notes, but no idea where I heard of it.

Final Thoughts

Agile was an interesting experience for me, in part because I’m doing less work on Agile teams, but also because it was the first non-UX conference I’ve been to in a while. We talk a lot about collaboration in the UX world, but I saw more people working together at Agile than I’ve ever seen at a UX conference. There was an “OpenJam” area available to anyone who wanted to work together, chat after a talk, or even hold an impromptu session. At the end of the week the walls were covered in butcher paper, markers and tape were everywhere, and it was clear that this area had been put to good use. Similarly, the sessions I participated in were more interactive than any I’d attended at a UX conference.

Overall I’m glad I made the trip to Agile, but I learned a few things to keep in mind if I go back. First, I’d hit up more talks outside the UX stage. If I’m not making the effort to learn more about Agile process outside of my role, I can’t expect others to check out the UX talks. Second, I’d look for more opportunities to discuss Agile UX with other practitioners. The UX talks were interesting, but didn’t really give us a chance to have a conversation about our experiences.