Posted on
by

I attended the May 2009 CHIFOO presentation today on the subject of what happens when design meets Agile development processes. Here are my rough notes from the meeting.

The speakers were:
Lane Halley (lane at cooper dot com)
Cooper
principal design consultant, and teacher at Cooper U
Jeff Patton (patton at acm dot org)
designing and developing using Agile
2007 award winner for Agile Alliance’s award
If you are familiar with Agile, you may want to skip to the 2nd section.
  • What is Agile?
    • Common myths: no planning, no up front design, no documentation, no handoff, self-managed teams, a fad that will go away soon, undisciplined, only works with small teams, an excuse for poor quality.
    • Software development has always been difficult.
      • There’s a long history. Standish Group’s Chaos reports still report most projects fail or finish challenged.
      • Agile’s strongest themes in response to years of failure in death march projects following waterfall-style processes.
    • Agile ideas germinated during the 1980s and 1990s.
      • 1986: Brook’s “No Silver Bullet” describes iterative and incremental development.
      • 1995: Schwaber and Sutherland document Scrum
      • 1997: Cockburn describes Crystal Methodologies.
      • 2000: Beck publishes Extreme Programming (formerly at Tecktronics)
    • These “lightweight” development processes had an image problem. à People with tough problems wanted strong processes, not lightweight processes.
    • Around this time, we start to see the design community and the agile community start to butt heads.
    • The term “agile” coined by lightweight process reps
      • Feb 2001: Agile Manifesto created, a common set of values among methodologies. Created by 17 representatives of different lightweight processes.
      • Since then, attracted other groups, such as lean development.
    • Manifesto for Agile Development
      • Link to it: http://www.agilemanifesto.org
      • Four values
        • Individuals and interactions over processes and tools
        • Working software over comprehensive documentation
        • Customer collaboration over contract negotiation
        • Responding to change over following a plan
      • “While there is value in the itoms on the right, we value the items on the left more.
      • For some, these were mom and apple pie statements.
      • See also the 12 principles in the manifesto.
    • Agile values motivate agile process
    • Agile success is measured through value alignment, not process compliance.
      • You can follow almost any process, and it can be agile, if your core values are agile.
    • What has emerged is a common process framework
    • Today Scrum dominates as the simple agile process framework of choice
    • Scrum describes only 3 simple roles:
      • The Product Owner: Describes that the product should be, and is ultimately responsible for its success
      • The Team: Everyone responsible for constructing the product
      • The Scrum Master: Makes sure the process is working, and all roles are collaborating effectively. Not responsible for making the product finish on time (that’s the product owner and the team), they just focus on making sure the process is working smoothly.
    • Scrum process framework (sometimes called the snowman diagram)
      • Product owner identified a potential product idea
      • Product owner supported by others creates the product backlog
      • In sprint planning the product owner and team plan the next sprint or iteration
      • The team works towards the iteration/sprint goals in a 1-4 week timebox
      • The team keeps progress visible with burndown charts and task boards
      • In the daily planning meeting / daily scrum, the team synchronizes daily in a short morning standup meeting
      • In a product review the product owner and team gather to review the results of the last sprint and reflect on how the product and process could improve
    • Today’s agile processes mix and match techniques from many agile methods: user stories, product backlog, planning poker, burndown chart, task board, test driven development, refactoring.
    • The scrum mantra “inspect and adapt” applies to the product and the process.
    • Agile process is tailored to the organization and team within the organization
      • Venture funded startup versus Large internal IT organization.
      • Mature consumer product companies versus venture startups.
      • Small collocated teams versus large distributed teams.
      • Everyone implements differently. Each implementation is a specific vertical implementation of process that works (or is intended to work) for the specific business environment. Since adaption is a key value, even if they started with the same process, the processes would evolve to become tailored.
  • Bringing UCD (user centered design) design techniques and Agile together
    • Some aspects of Agile cause frustration
      • Agile lacks tools to define business and customer needs and measure product success
      • An agile “product owner” may not accurately represent the user needs. It’s hard for one person to represent all the needs.
      • It’s hard to see the “big picture” when you’re building incrementally
      • Finding the right level of design documentation
(WEH: Isn’t it just common sense that if you see a gap, then you create a solution to that gap?)
    • There are best practices to overcome all these problems
    • Common ground: Interaction designers share many values with agile practioners:
      • Desire to build successful products
      • Focus on providing what people value
      • “user stories” instead of “features”.
    • Agile work styles have many benefits
      • Agile is about shared responsibility
      • Agile is about effective communication: you write things down to achieve clarity and because it will be useful, not just for the sake of writing documentation. [WEH: Using a wiki encourages this behavior.]
      • Agile helps you fail quickly
      • Agile is a more humane way to work: everything is done at a sustainable pace. Have retrospective, measure the rate at which work can happen.
    • Agile processes lead to good partnerships
      • No edicts: a user story is an invitation to a conversation, not an edict of what will happen.
      • …
    • Two different sets of expertise when Interaction Designer and Developers get together
      • Ingrid, interaction designer
        • HCI degree
        • Works on paper
      • Dave, Developer
        • CS degree
        • Ruby, Pivotal Tracker
      • Ingrid: focuses on the probable: what might we do?
      • Dave: focuses on the possible: what can be done?
      • Designer and developer need to be able to talk about both the big picture as well as the nitty details
    • If you’re a designer
      • Be a facilitator: Help people collaborate and evolve ideas in the room together. Don’t go off and develop a vision on your own. You need to bring everyone along with you.
      • Have conversations, not directives
      • Use visual communication: More time on whiteboards, sticky notes, paper. Less time on heavy weight design documents.
      • Help the team understand user needs, behaviors, and attitudes. You are the specialist in this, so you need to help other people. Again, not dictate the solution, but give them the tools to arrive at the solution themselves.
      • Question from audience: when can you challenge the developer?
        • Answer: you can challenge on what is possible. Your role is to prioritize what is really important. Where do we need to push the development boundary of what is possible, versus we can we live with it?
    • If you’re a developer
      • You are not the user. (Unless you are those guys at 37 signals and what you are building is a tool that you will use yourself.) We need to have a shared understanding that it is not us, and a shared understanding of who it is, not an idiosyncratic personal view of who the user might be.
      • Look for the common case
      • Learn design principles and patterns
      • Ask the questions “who is this for?” and “what problem does this solve?”
    • Changing role of interaction design
      • Before:
        • interaction design is a specialized role
        • interaction design done at the beginning of the process
      • With agile:
        • Interaction design integrated in agile process
        • Interaction designers participate in new ways
          • Front end UI development alongside developers
          • Work with product owner to articulate and validate the product concept
        • More frequently, seeing interaction designers as a hybrid role…
          • Interaction designers become product owners
          • Interaction designers become coders who implement the UI front end
    • The role of the interaction designer
      • Facilitate brainstorm sessions where everyone on the team can contribute ideas and jointly understand the implications of design decisions
      • Quickly iterate through different design solutions as low-fidelity sketches to help developers save time and make good decisions
      • Be the team member responsible for user experience.
  • Patterns for Success
    • Put UX in the navigator’s seat
      • UX is an important part of the product owner team
      • Become a design facilitator
    • Do just enough research and design to get started
      • Research, model, and design up front, but lightly
      • Plan for continual ongoing user contact for research and validation
      • (Prioritize the target users: “of the 12 users we eventually want to target, we’ll start with these 3”
    • Focus on the big picture
      • Identify and communicate the overall story of the interface so you can work on smaller parts while maintaining context
      • Be able to answer the questions of “Why are we in business?”, “What is this software for?” Be able to describe the context. What does this product do, and how does it do it, so that the users can accomplish what they need to accomplish? They take just enough time to see, they evolve it as they see more, and they help everyone else to see it.
      • Designers need to be able to operate with a low-fidelity big picture
    • Use good UX practices to support product development
      • Use parallel track development to stay ahead and follow behind
      • Buy design time with complex engineering stories (give the developers some tough problems to solve, so that the designers have time to work on other stuff. It’s balancing of resources, not just narrow focused on business priority.
      • Use RITE to iterate UI before development (you can iterate UI with paper prototypes, mock up tools, etc – so that what goes into development is known good UI.)
      • Prototype in low fidelity. Use paper if you can. Use code if you need to. Use the right level of fidelity. Start low, and move high only as needed.
      • Treat prototype as specification. Don’t add more documentation for the sake of documentation. Have a discussion about the prototype if needed.
    • Engage users continuously
      • Cultivate a user group for continuous feedback.
        • A pool of people I can go too, to show prototypes, get feedback. My pool is big enough that I don’t go back to the same person all the time. I should cycle through so that I am not testing with the same people, not more often than every couple of months.
      • Commit to regularly visiting, listening to, and collaborating with your users.
      • Leverage user time for multiple activities.
        • Example of bad case: you may have user research people who are different from your design people. This should be merged. Leverage the time to its fullest extent.
  • Questions and Answer session
    • What is the ideal seating arrangement?
      • Ambient communication is very important because there is less formal communication. The people who work together should sit together. Information flow is a property to be tuned. Information moves like heat through the room. Organize people in pods, or in big large tables.
    • Any successful teams that are not collocated?
      • Thoughtworks has development in Hong Kong and US. They rotate staff between locations on a regular basis. A couple of weeks each month.
      • Cross country Healthcare: Brought team of engineers from India into the US for a year. Colocated India and Florida engineers for a year, then moved the engineers back.
      • Have constant phone connections.
      • Have video cameras.
    • How do we engage with clients (we’re an agency)
      • Ideally you would want the client to participate to the extent that they can. Join you at your location.
      • Look at “innovation games”, a process to facilitate this kind of involvement.
      • Develop with the client a communication plan: how much do we communicate, what are the checkpoints?
        • But how far do you invite them in? You are making them breakfast, they don’t want to see you making sausage. (there will be some hard tradeoffs.)
        • But the more you engage, the more they want to get involved. The more they get involved, the more changes they make. In the end, they will usually be happy with something simpler and less expensive to build.