Making Sense of UCD and Agile

Making Sense of UCD and Agile Jeff Patton Agile Product Design [email_address] Lane Halley Cooper [email_address] Chifoo, May 6 th , 2009

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

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

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

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

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

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

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

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.

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

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

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

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

Bringing UCD and agile together iStockPhoto.com/eyeidea

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

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 ”

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

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

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

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

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

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

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

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

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

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

Patterns for success iStockPhoto.com/rmfox

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

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

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
validate iteration 1 features
implement iteration 3 features fix iteration 2 bugs if any
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

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

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

http://www.7ux.nl	178
http://iatealady.posterous.com	29
http://www.slideshare.net	23
http://www.agile-school.com	16
http://clickwatchlearn.blogspot.com	7
http://twitter.com	1
http://www.health.medicbd.com	1

Making Sense of UCD and Agile

by Lane Halley on May 19, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

7 Embeds 255

Statistics

Making Sense of UCD and Agile — Presentation Transcript