bringing user-centered design practices into agile development projects

Download Bringing User-CenteredDesign Practices intoAgile Development Projects

Post on 08-Sep-2014




2 download

Embed Size (px)


Bringing User-CenteredDesign Practices intoAgile Development Projects -This full day tutorial seeks to explain Agile Development\'s incremental release and iterative development strategy from the perspective of a user centered design practitioner. Practical advice is given on making Agile development more user-centric.


  • Bringing User-Centered Design Practices into Agile Development Projects Jeff Patton Thought Works [email_address] Please join a work group of 4-6 people thanks.
  • The Shape of Our Day
    • 8:30 5:30
    • Part 1: The Agile Development Context
    • Part 2: Project Inception and Planning
    • Part 3: Building and Validation
    • Part 4: Adapting and Thriving
    • Laced through the tutorial youll find tips to help you survive and thrive in an Agile environment
    • In your handouts youll find outside references and details on topics we likely wont discuss today
    • This is going to hurt [and Im only a little sorry]
  • Meta Tutorial
    • I dont think youre here to learn User Centered Design
      • If you accidentally learn something, I wont be held responsible
    • Agile-Dip
      • Youll be dipped in a Agility via an Agile Development Process Miniature
      • Observe Agile development lifecycle
      • Observe Agile collaboration and communications styles
    • Your new role: user centered evangelist
      • Learn to communicate user centered thinking throughout the design and development team
      • Adapt your current approaches to increase transparency and outward information flow
      • Adapt your current approaches to leverage the daily involvement of other development team members outside the UCD team
      • Today youll hear a lot of language that may help you better explain user centered design thinking back to an Agile team
  • Part 1: The Agile Development Context
    • 8:30 10:00
    • Agile Development from a distance
      • Rant: If I hear business value one more time Ill scream
    • Business Goals Via GQM
    • Using Collaborative Worksessions to Model Information
    • Our Business Problem
    • Modeling Business Goals
    • Communicating and Socializing Information in an Agile Environment
  • The Waterfall Model remains the traditional software development approach
    • Traditional design & development steps are separated into distinct phases
    • Workproducts produced at each phase & handed off to the next
    • Risks
      • Errors in each phase are passed to the next
      • Time overruns usually come out of final phases - development and test often resulting in poor quality
      • Poor quality on top of upstream problems in requirements and design often adds insult to injury
      • Most practitioners waterfall implementation lack Royces original suggested feedback loops
    * Winston Royce, Managing the Development of Large Software System, 1970 Requirements Design Development Testing & Validation Deployment & Maintenance
  • The Spiral Model Introduced Iterative Refinement in the 80s
    • Iterative elaboration from prototype to finished release
    • Important addition of planning & risk evaluation
    • Risks
      • Product remains prototype till final spiral revolution
  • The Origins of Agile Development Spring From Early Discussions on Adaptive Incremental Development
    • The Psychology of Computer Programming Gerald Weinberg, 1971
    • The Mythical Man Month, Fred Brooks, 1986
    • Scrum, Ken Schwaber, Mike Beedle, 1986
    • PeopleWare, DeMarco & Lister, 1987
    • Borlands Software Craftsmanship, 1994
    • Dynamic Systems Development Methodology, 1994
    • Crystal Methodologies, Alistair Cockburn, 1997
    • Feature Driven Development, Jeff DeLuca, 1998
    • Adaptive Software Development, Jim Highsmith, 2000
    • Extreme Programming, Kent Beck, 2000 (origins in 1996)
  • Coining The Agile Software Development Label
    • XPs success acts as a catalyst
    • Meeting of 17 at Snowbird, Utah, 2001
    • All participants disagree on specifics
    • All agree they have something in common
    • 4 principles of the Agile Manifesto
  • Agility is a Value System
    • The agile alliance is based on 4 core 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
    • 12 additional principles support the 4 basic values emphasizing:
      • Iterative development and delivery
      • People both individuals and teams
      • Collaboration
      • Technical excellence
  • No Rules
    • Theres no specific way to be or not be Agile
    • Agile describes an approach to a method, not the method itself
    • The Pornography Rule:
      • "I can't define pornography,
      • but I know it when I see it."
        • --Supreme Court Justice Potter Stewart, 1964
    • Use the 4 principles to evaluate a methodologys Agility
  • Agile Development Usually Follows a Predictable Lifecycle Iteration Plan Release Plan Product/Project Charter
    • Feature or User Story
    • Expressed from business or user perspective
    • Business value
    • Estimable
    • Feature List: prioritized features
    • (AKA Product Backlog)
    • Iteration
    • 1-4 week timebox
    • Incremental Release
    • 1-6 Iterations
    • Released internally or externally to end users
    • Product or Project
    • Perpetually released
    Product/Project Incremental Release Evaluate Iteration Feature Design Develop Evaluate Test Evaluate Plan Plan Plan
  • Agile Developments Carrot and Stick is Often the Creation of Business Value
    • User Stories or product features are generally prioritized by business value
    • Incremental deliveries generate business value
    • To understand a proposed software requirement, its common for an Agile practitioner to ask: How does the business get value from this?
    • However what the business is really trying to achieve is often not well understood
    • Use a simple model to communicate business goals and the metrics used to track their progress
      • Identify and prioritize user constituencies
      • Prioritize business stakeholder concerns
      • Prioritize suggested product features
    • A Business Goal Model allows us to validate subsequent product decisions
  • Use a GQM Style Approach To Identify Business Goals And Appropriate Goal Metrics
    • Leverage a simple approach from the GQM methodology
    • Identify and prioritize goals
      • To help identify goals consider these questions:
        • How will the organization improve after the delivery of this software?
        • What will happen if we dont deliver this software?
      • IRACIS - How might this software:
        • Increase Revenue, Avoid Cost, or Increase Service
    • Question each goal:
      • If we were making progress toward this goal, how would we know?
      • What would change in the business as a result of reaching this goal?
    • Use answers to these questions to identify metrics for goals
      • Metrics help quantify ROI
      • Metrics helps justify ongoing development expense
      • Requirements to track metrics often generate important product features
  • Capture Goals In a Model Using a Collaborative Modeling Session
    • Use Collaborative Modeling Sessions to:
      • Build up tacit shared knowledge within the team
      • Build communication and collaboration skills within the team
      • Help the team to gel as an affective workgroup


View more >