• Save
Making Sense of UCD and Agile
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Making Sense of UCD and Agile

  • 18,587 views
Uploaded on

This talk was originally presented at the Computer-Human Interaction Forum of Oregon (CHIFOO) May 6, 2009. ...

This talk was originally presented at the Computer-Human Interaction Forum of Oregon (CHIFOO) May 6, 2009.

Description below reprinted from the CHIFOO website, http://tinyurl.com/cphkwl

---

Love it or hate it, everyone seems to be talking about Agile. Agile is used at scrappy start ups that are iteratively defining their products and markets and at large companies with complex business problems working with internationally distributed teams. In each of these different settings, some folks are strong advocates of Agile, while some are still skeptics. Some people in the User-Centered Design (UCD) community dismiss Agile as a fad, others have embraced it whole-heartedly. Can these two worlds intersect?

In this talk, Jeff and Lane will draw on their personal experience to share the characteristics of successful (and unsuccessful!) blends of UCD and Agile techniques.

After this talk, you’ll be able to answer these questions:
• What do UCD people need to know about Agile?
• What do Agile people need to know about UCD?
• What are the pain points?
• How can Agile and UCD methods be used together?

More in: Design , Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
18,587
On Slideshare
18,128
From Embeds
459
Number of Embeds
14

Actions

Shares
Downloads
0
Comments
6
Likes
120

Embeds 459

http://www.7ux.nl 331
https://twitter.com 32
http://iatealady.posterous.com 29
http://www.slideshare.net 23
http://www.agile-school.com 18
http://www.techgig.com 9
http://clickwatchlearn.blogspot.com 7
http://www.linkedin.com 3
http://115.112.206.131 2
http://www.health.medicbd.com 1
http://clickwatchlearn.blogspot.sg 1
http://twitter.com 1
http://koffie.roberteijlander.nl 1
http://127.0.0.1 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Making Sense of UCD and Agile Jeff Patton Agile Product Design [email_address] Lane Halley Cooper [email_address] Chifoo, May 6 th , 2009
  • 2. What is “agile?” iStockPhoto.com/GeorgePeters May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 3. Things you may have heard about “Agile”
        • “ no planning!”
        • “ no up front design!”
        • “ no documentation!”
        • “ no handoff!”
        • “ self-managed teams!”
        • “ a fad that’ll go away soon!”
        • “ undisciplined!”
        • “ only works with small teams!”
        • “ an excuse for poor quality!”
    May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 4. Software development has always been difficult
    • There’s a long history of software project failures
      • 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
      • Yourdon’s 1997 book “Death March” characterized under-staffed under-budgeted projects doomed to failure
    May 6, 2009 http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS Image of the Bataan Death March, US Gov National Archives © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 5. Agile ideas germinated during the 1990s
    • 1970: Royce’s paper describes waterfall process and explains missing feedback loops
    • 1986: Brook’s “No Silver Bullet” describes iterative and incremental development
    • 1994: DSDM published (Dynamic Systems Development Methodology)
    • 1995: Schwaber & Sutherland document Scrum (based on 1986 HBR Paper)
    • 1997: Cockb u rn describes Crystal Methodologies
    • 1998: Coad describes FDD (Feature Driven Development)
    • 2000: Highsmith describes Adaptive Software Development
    • 2000: Beck publishes Extreme Programming
    May 6, 2009 These “lightweight” development processes had an image problem. © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 6. The term “agile” coined by lightweight process reps
    • February 2001: 17 Representatives gather at Snowbird Ski Resort in Salt Lake City
    • The outcome wasn’t a common process, but a common set of values: The Agile Manifesto
    • Since then the manifesto has attracted other
    • like-minded groups
      • Lean Software Development
      • Product Management
      • Portfolio management
      • Non-software projects
    May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 7. Manifesto for Agile Software Development
    • We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
        • Individuals and Interactions over Processes and Tools
        • Working Software over Comprehensive Documentation
        • Customer Collaboration over Contract Negotiation
        • Responding To Change over Following a Plan
      • That is, while there is value in the items
      • on the right, we value the items on
      • the left more.
    Agile Manifesto Collaborators, Feb 2001 http://www.agilemanifesto.org May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 8. Agile values motivate agile process
    • Agile values are articulated in the Agile Manifesto and 12 Principles
    • Agile success is measured through value alignment, not process compliance
    May 6, 2009 Individuals & Interactions Working Software Customer Collaboration Responding to Change Sustainable Development Technical Excellence Simplicity Self-Organizing Teams Reflection Early and Continuous Delivery Welcoming Changing Requirements Business People and Developers Work Together Motivated Individuals Face-to-Face Conversation © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 9. 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
    May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 10. The Scrum process (snowman) May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved Daily Planning Meeting (the Daily Scrum) The team synchronizes daily in a short morning standup meeting or daily scrum Product Owner identified a potential product idea In Sprint Planning the Product Owner & team plan the next sprint or iteration The team works towards the iteration/sprint goals in a 1-4 week time box 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 Product Backlog Product Goals Sprint Backlog Working Evaluated Software Product Owner supported by others creates the product backlog Iteration or Sprint 1-4 week cycle The team keeps progress visible with burndown charts and task boards.
  • 11. Today’s agile processes mix-and-match techniques from a growing agile buffet
      • You may hear people using these agile techniques
        • User Stories
        • Product backlog
        • The Planning game
        • Planning poker
        • User stories
        • Burndown chart
    May 6, 2009
        • Task board
        • Test driven development
        • Refactoring
        • Daily Stand-Up
        • Retrospective
      • The Scrum mantra “inspect and adapt” applies to your growing product , your project plan, and the process you follow
        • Teams add and remove techniques flexibly
    © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 12. Agile process is tailored to the organization and team within the organization
      • Consider a Venture-funded startup
        • Developing a product from scratch
        • Small team of developer/generalists
        • Work together in the same space
        • “ Customer” is the Founder/CEO
        • Users hard to identify precisely
    May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 13. Agile process is tailored to the organization and team within the organization
      • Consider a Large internal IT organization
        • Maintaining/extending an existing system
        • Large team with more specialized roles (developers, BAs, UE, PMs, QA, etc.)
        • Some members co-located, some remote
        • “ Customer” is a business owner
        • Users are well known and accessible
    May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 14. Agile process is tailored to the organization and team within the organization
      • What’s different about these contexts that would require specific process changes?
        • Mature consumer product companies
        • Large multi-national banks
        • Small collocated teams
        • Large distributed teams
    May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 15. Bringing UCD and agile together iStockPhoto.com/eyeidea
  • 16.   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 to see the “ big picture” when you’re building incrementally
      • Finding the right level of design documentation
    May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 17. Common ground
    • Interaction Designers share many values with agile practitioners:
    • Desire to build successful products
    • Focus on providing what people value
    • “ User stories ” instead of “ features ”
    May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 18. Agile work styles have many benefits
      • Agile is about shared responsibility
      • Agile is about effective communication
      • Agile helps you fail quickly
      • Agile is a more humane way to work
    May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 19. Agile processes lead to good partnerships
    • No edicts – “A user story is an invitation to a conversation”
    • Visual communication – “working code over comprehensive documentation,” prototypes, wireframes, mockups
    • Transparent process – stand ups, backlogs, information radiators
    May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 20. Two different sets of expertise
      • Ingrid, Interaction Designer
      • Dave , Developer
    May 6, 2009 HCI degree Paper, Visio, Axure Knows UI design patterns Likes to spend time with users
      • CS degree
    • Ruby, CSS, Pivotal Tracker
    • Knows Web dev. best practices
    • Likes to write code
    iStockPhoto.com/snapphoto iStockPhoto.com/Buretsu © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 21. Two different comfort zones
      • Interaction designers and developers each have a different “comfort zone” when solving problems.
      • Designers focus on the probable
      • Developers focus on the possible
    May 6, 2009 iStockPhoto.com/snapphoto iStockPhoto.com/Buretsu © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 22. Some tips for a good working relationship
      • If you’re an interaction designer
        • Be a facilitator
        • Conversations, not directives
        • Use visual communication
        • Help the team understand user needs, behaviors and attitudes
    May 6, 2009 iStockPhoto.com/snapphoto © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 23. Some tips for a good working relationship
      • If you’re a developer
      • You are not the user
      • Look for the common case
      • Learn design principles and patterns
      • Ask “who is this for?” and “what problem does this solve?”
    May 6, 2009 iStockPhoto.com/Buretsu © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 24. Agile has changed the role of testing
    • Before…
      • Testing was a specialized role
      • Testing was done at end of the process
    • Now…
      • Testing integrated in agile process
      • Testers participate in new ways :
      • Write code alongside developers
      • Work with the product owner to define acceptance criteria
    May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 25. How will agile change the role of IxD?
    • Now…
      • Interaction design is a specialized role
      • Interaction design done at the beginning of the process
    • Later?…
      • 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
    May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 26. The role of the interaction designer
      • Help product managers and other business stakeholders understand and balance business and user goals
      • Identify patterns of user behaviors and attitudes and model them through personas, workflows and scenarios
      • Help developers understand the underlying product framework and define interaction and visual design patterns
    May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 27. 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 throughout the process
    May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 28. Patterns for success iStockPhoto.com/rmfox
  • 29. 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
    • Focus on the big picture
    • Identify and communicate the overall story of the interface so you can work on smaller parts while maintaining context
    May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 30. Patterns for success
    • Use good UX practices to support product development
    • Use parallel track develop-ment to work ahead, and follow behind
    May 6, 2009 See Miller’s Case Study of Customer Input For a Successful Product: http://www.agileproductdesign.com/useful_papers/miller_customer_input_in_agile_projects.pdf © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 31. Patterns for success May 6, 2009 implement iteration 1 features
    • support iteration 1 development
    • design iteration 2 features
    • gather user input for iteration 3 features
    implement iteration 2 features fix iteration 1 bugs if any
    • support iteration 2 development
    • design iteration 3 features
    • gather user input for iteration 4 features
    • validate iteration 1 features
    implement iteration 3 features fix iteration 2 bugs if any
    • support iteration 3 development
    • design iteration 4 features
    • gather user input for iteration 5 features
    • validate iteration 1-2 features
    • planning
    • data gathering
    • high level design
    • design for iteration 1 features
    • development environment setup
    • architectural “spikes”
    iteration 0 Iteration1 Iteration 2 Iteration 3 feature design coded features feature design + bugs found in usability testing support dev support dev See Miller’s Case Study of Customer Input For a Successful Product:: http://www.agileproductdesign.com/useful_papers/miller_customer_input_in_agile_projects.pdf © 2006-2009 Jeff Patton, Lane Halley All rights reserved Product Owner Team time
  • 32. Patterns for success
    • Use good UX practices to support product development
    • Buy design time with complex engineering stories
    • Use RITE to iterate UI before development
    • Prototype in low fidelity
    • Treat prototype as specification
    May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 33. Patterns for success
    • Engage users continuously
    • Cultivate a user group for continuous feedback
    • Commit to regularly visiting, listening to and collaborating with your customers
    • Leverage user time for multiple activities
    May 6, 2009 © 2006-2009 Jeff Patton, Lane Halley All rights reserved
  • 34. Thank you! Lane Halley www.cooper.com [email_address] Jeff Patton www.agileproductdesign.com [email_address] © 2006-2009 Jeff Patton, Lane Halley All rights reserved May 6, 2009