Since Alan and I attended Agile 08 last August, I’ve had conversations with a lot of people about their impressions of Agile. I’ve talked with people working in a variety of settings, from scrappy startups who are iteratively defining their product and market to large companies with complex business problems working with internationally distributed teams. In each of these settings, some folks are strong advocates of Agile, some are still skeptics. It’s a broad field, and I’m still very much formulating my opinions, but I’d like to share some thoughts and observations I’ve had along the way. I also have a few ideas about how Agile and interaction design might be able to work in concert.

Some aspects of Agile create tremendous value

The people who are successful with Agile realize that it’s not just a set of techniques; Agile is about creating better products, and making the process less painful along the way.

  • Agile is about shared responsibility. As Alan says “Someone is going to design your product, it can happen accidentally, or on purpose.” Instead of an indirect cascade of responsibility, Agile makes developers partners with other people in the organization. Instead of delivering software that meets specifications, developers engage with the rest of the organization in a more collaborative way to create products.
  • Agile is about effective communication. By changing the language of product definition from “features” to “user stories” Agile helps people focus on the value the product delivers to real people, rather than the technology used to deliver that value. By bringing people together to play the planning game, Agile makes it possible for developers to ask product managers “what do you mean by that?” and for product managers to ask “this seems easy, why will this take so long?”
  • Agile helps you fail quickly. A focus on working code helps Agile projects stay honest. Instead of working for months on something that may or may not work, there’s a focus on providing smaller parts that are available for feedback and refinement.
  • Agile is a more humane way to work. Iterative development helps development teams work at a sustainable pace, and stops the death march. Agile development recognizes the fact that human resources are finite, and you don’t get something for nothing. By considering the implications of a user story, developers and product managers can have a well-informed conversation about trade-offs.

Some aspects of Agile cause frustration

Agile’s roots are in the product development world, not the product creation world. A successful product is more than well-executed technology delivered on time. As Alan likes to say “The operation was a success, but the patient died.” Most Agile techniques (e.g. peer programming, integrated testing, refactoring) are focused on effective development. Many Agile projects are staffed entirely with people who write code. At a company where everyone isn’t a coder, it can be challenging to fully integrate the contributions of business stakeholders, such as executives and product managers and other team members such as business analysts and interaction designers.

  • The Agile process does not provide tools to define key business or user experience objectives. A clear product mandate makes it easier for everyone on the project to share the same vision and contribute to a shared objective. Somewhere in the process, it’s necessary to define “What does this product do?” “Who is the customer and what does she value?“ and even “What should the experience of using this product feel like?” Many people assume that these things are determined before the Agile development effort starts, or can be figured out iteratively as development continues.
  • An Agile “customer” may not be the same as the “user.” An Agile customer is often the business stakeholder who paid for the project, not necessarily the “user” of the system. When an Agile team does have a chance to show work-in-progress to actual end-users, their feedback can be difficult to interpret or prioritize.
  • You can lose sight of the big picture. Developers need user stories to be small so they can be tested and built in a single iteration. Even when a team starts with some idea of the overall experience they want to create, once it’s broken into granular user stories, it can be difficult to identify useful interaction patterns and maintain a coherent product framework. Using Agile techniques, it’s possible to come up with solutions for every user story, and still fall short on making a product that’s a pleasure to use.
  • It’s hard to integrate visual interface design. Visual interface designers who produce static pixel-level screen mockups can find it hard to integrate their process with an Agile development team. When responding to the needs of the evolving product it can feel like they are always playing “catch up” and trying to rework visual and interaction design decisions that were made by developers as they built the product. Developers can feel that designs of this nature are “brittle” and that visual designers are not responsive to their needs.

Interaction design can help

These challenges seem to suggest areas where interaction design techniques can help. Interaction designers can partner with product managers and developers to evolve Agile from a development process to a product creation process. Although some people have the impression that interaction design is solely a “waterfall” method, in reality a highly iterative, sketch-based approach to interaction design can be quite nimble.

  • Interaction designers can partner with product managers and other business stakeholders to understand and balance business and user goals. Interaction designers can clarify and articulate the product mandate through stories and sketches that create conversation and consensus.
  • Interaction designers are experts in observing and understanding user behaviors and making this information available to the development team in the form of personas, mental models and scenarios. Depending on the timeline and project scope, this work can be done in a very compressed timeline, or successively as new insight is needed.
  • By thinking about the design problem at a higher level than user stories, (I’ve heard some Agile teams call this a “big story” or a “narrative”) interaction designers can help developers understand the underlying interface patterns and framework of the design and assist with the sequencing of user stories as they are implemented.
  • Interaction designers can facilitate design brainstorm sessions where everyone on the team can contribute ideas and jointly understand the implications of design decisions. Interaction designers can also take these varied inputs and create coherent design solutions that people can understand and use.
  • By working through interaction problems in low-fidelity sketches, interaction designers can quickly iterate on different design solutions, which helps developers save time and make good decisions.

From reading other blogs and discussion groups, it's obvious that a lot of people see the potential that Agile represents for the interaction design community (and vice-versa), but there are also a lot of questions about how this combination should work. I look forward to hearing your stories as we figure out how to best develop this opportunity. Please feel free to comment on this article, or drop me a line if you want to talk about your experiences. As I continue my research, I’ll share further thoughts on this Blog.