Transcript Document

Agile UX
Primer
or: how I stopped
worrying and
learned to love
the bomb
Jeff Patton
© 1964, Columbia Pictures
[email protected]
AgileProductDesign.com
Our goals for today…
Part 1:
Understand where agile came from
Understand simple agile process from a UX
practitioners point of view
Part 2:
Review emergent agile-UX practices
(My recommendations for UX-centric agile
practice will be threaded in)
2
je ne sais quoi
Agile development is a fairly recent
identification and naming of “quality” of
successful software development – a quality
that’s been understood since the origins of
software development.
Winston Royce is generally credited with first
describing what’s known as the waterfall model in his
1970 paper “Managing the Development of Large
Software Systems.”
4
That diagram was followed by this diagram showing feedback
loops at each stage… then this statement:
“I believe in this concept, but the
implementation described above is risky and
invites failure.”
5
More telling is the next diagram showing that after we’ve built
and tested something we need to go back to requirements… do
not pass go, do not collect $200.
This begins to look like what is today’s agile development cycle.
6
In the 1986 Harvard Business Review paper “The New New Product
Development Game” Takeuchi and Nonaka described an emergent
ideal process that overlapped traditional phased approaches to design
and construction.
(This paper was the basis for the Scrum Process)
http://hbr.harvardbusiness.org/1986/01/the-new-new-product-development-game/ar/1
7
Since there’s been software development,
there’s been an undercurrent of people
believing it could be done better
8
What we call “Agile Development” today has
evolved over many years
1970: Managing the Development of Large Software Systems, Royce
(first description of the waterfall model and why it’s a bad idea)
1971: The Psychology of Computer Programming, Weinberg
1986: The Mythical Man Month, Brooks
1986: Scrum, Schwaber, Sutherland, Beedle
1987: PeopleWare, DeMarco & Lister
1994: Borland’s Software Craftsmanship Approach
1994: Dynamic Systems Development Methodology
1997: Crystal Methodologies, Cockburn
1998: Feature Driven Development, DeLuca
2000: Adaptive Software Development, Highsmith
2000: Extreme Programming, Beck
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
9
Coining the Agile Software Development label
(instead of lightweight development)
In 2001 XP’s success acts as a catalyst
Workshop of 17 practitioners at a Utah ski resort in February
2001
All the participants disagree on specifics
All agree they have something in common
The four statements found in the Agile Manifesto
emerge
The Agile Alliance non profit was formed the following year
The 17 practitioners that disagreed
on specifics have been joined by
thousands more… who continue to
disagree on specifics
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
10
Culture
Agile is characterized by a set of values that
motivate particular practices and a loose, but
disciplined process.
Agile looks more like a culture than a process.
The Agile Manifesto describes a value system
The Agile Manifesto (2001)
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.
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
12
Agile’s 12 Principles suggest values and
corresponding practices of agile development
1.
Our highest priority is to satisfy the customer
through early and continuous delivery of
valuable software.
2.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
3.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
4.
5.
6.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they
need, and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a
development team is face-to-face
conversation.
7.
Working software is the primary measure
of progress.
8.
Agile processes promote sustainable
development. The sponsors, developers, and
users should be able to maintain a constant pace
indefinitely.
9.
Continuous attention to technical excellence
and good design enhances agility.
10. Simplicity--the art of maximizing the amount
of work not done--is essential.
11. The best architectures, requirements, and
designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how
to become more effective, then tunes and
adjusts its behavior accordingly.
For more information:
http://www.agilemanifesto.com
http://www.agileproductdesign.com/downloads/AgileDevelopmentQuickReference.pdf
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
13
Agile values motivate agile process
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
Agile values are clearly visible in the
Agile Manifesto and 12 Principles
14
“Agile Development” describes a class of
approaches, not a single approach
Some Agile approaches get named:





Scrum (origins in1986)
DSDM: Dynamic Systems Development Method (1995)
Crystal (1997)
FDD: Feature Driven Development (1998)
XP: Extreme Programming (1999)
Most organizations assemble their Agile approach from a
collection of Agile practices
Today’s common Agile practice combines elements of all
of the above named processes
Scrum is to Agile as
Cooper’s Goal-Directed Design is to User-Centered Design
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
15
While agile isn’t a specific process, a
common process lifecycle and roles have
emerged
16
People in agile development often act
as one of three “super roles”
People often move freely between
these roles
17
The team is responsible for creating a high quality
product
The Team is generally composed of





Developers
Architects
Testers
Business Analysts
UI Designers & Interaction Designers
If you’re part of constructing the software,
you’re “the team” from a common agile
terminology perspective.
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
18
The Scrum Master or Coach oversees, facilitates,
and helps the team peform
The Scrum Master or Coach helps keep the
process running smoothly
 makes sure everyone understands their roles and
responsibilities
 helps team members get support and training
 deals with problems or impediments that slow the team
down
 facilitates planning, product evaluation, and retrospective
meetings
Often this person used to be a project
manager or lead developer in a traditional
software development approach
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
19
The Agile Product Owner steers the product
construction
Product Owner role name comes from Scrum, the
Customer role name comes from Extreme
Programming
The Product Owner describes what to build and is
responsible for the outcome of the product after
delivery.
While this is a role that can be held by a single person,
it is generally supported by a team:






Business Analysts
UI Designers & Interaction Designers
Architects
Testers
Domain Experts
Users
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
20
The snowman and the onion
are two of the simple process
models that describe agile
development
21
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
The Scrum process framework is the simplest of
incremental development models
Product Owner
supported by
others creates the
product backlog
The team
synchronizes daily
in a short morning
standup meeting
or daily scrum
Daily
Planning
Meeting
(the Daily
Scrum)
Iteration
or Sprint
Product Owner
identified a
potential product
idea
Product
Goals
Product
Backlog
1-4 week cycle
Product Owner &
team plan the
next sprint or
iteration
Sprint
Backlog
The team works
towards the
iteration/sprint
goals in a 1-4
week time box
The product owner and
team gather to review
the results of the last
sprint and reflect on
how the product and
process could improve
Working
Evaluated
Software
22
If the snowman seems too simple,
it’s because it is
Let’s peel back another layer
23
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
The product owner plans the product in layers of
feedback cycles
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
24
The product owner plans the product in layers of
feedback cycles
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
25
The product owner plans the product in layers of
feedback cycles
Release
Product
or Project
What business
objectives will the
product fulfill?
Product Goals
Product Charter
Elevator Pitch
How can we release value
incrementally?
What subset of business
objectives will each release
achieve?
What user constituencies
will the release serve?
What general capabilities
(big stories) will the release
offer?
Release Roadmap
Iteration or
Sprint
What specifically will
we build? (user
stories)
How will this iteration
move us toward
release objectives?
Iteration Goal
Development or
Construction Tasks
Release Plan
Story (Backlog
Item)
What user or stakeholder need will
the story serve?
How will it specifically look and
behave?
How will I determine if it’s
completed?
Story Details
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com Acceptance Tests
26
The product owner plans the product in layers of
feedback cycles
Release
Product
or Project
What business
objectives will the
product fulfill?
Product Goals
How can we release value
incrementally?
Product or Project
Release
Product Charter
Elevator Pitch
Iteration/Sprint
What subset of business
objectives will each release
achieve?
What user constituencies
will the release serve?
What general capabilities
(big stories) will the release
offer?
Release Roadmap
Iteration or
Sprint
What specifically will
we build? (user
stories)
How will this iteration
move us toward
release objectives?
Iteration Goal
Development or
Construction Tasks
Story
Release Plan
Story (Backlog
Item)
What user or stakeholder need will
the story serve?
How will it specifically look and
behave?
How will I determine if it’s
completed?
Story Details
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com Acceptance Tests
27
The Planning Onion can grow to include product
portfolios and business strategy
Product or Project
Release
Iteration/Sprint
Story
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
28
28
The Planning Onion can grow to include product
portfolios and business strategy
Business Strategy
Product Portfolio
Product or Project
Release
Iteration/Sprint
Story
©
Patton,
All rights
reserved,
www.agileproductdesign.com
©2006-2009
2008 Jeff Jeff
Patton
& Josh
Evnin,
All rights
reserved,
29
29
All agile cycles, large and small, follow a predictable
flow
What will we
construct?
Keep quality high and
minimize the cost of
change
What outcome or
benefit are we
striving for?
Keep progress
visible to all
plan
perform
Pace : how fast are
we moving?
An Agile iteration or “sprint”
is typically 1-4 weeks, or 1
calendar month
evaluate
the goal: plan, create, and
validate potentially
deliverable functionality
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
Product: is the
software we’re
building able to
achieve its intended
benefit?
Process: is the
process we’re using
working effectively?
30
An iteration or sprint has its plan-perform-evaluate
cycle
perform
Iteration
plan
evaluate
©
Jeff Patton,
rights All
reserved,
www.agileproductdesign.com
©2008
2006-2009
Jeff All
Patton,
rights reserved,
www.agileproductdesign.com
31
Performing an iteration means discussing, writing
code for, and validating user stories
code
Story
design
perform
validate
Iteration
plan
evaluate
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
32
32
Releasing software incrementally means building
software in some number or cycles
code
design
Story
validate
Iteration
plan
evaluate
Release
plan
evaluate
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
33
33
Products release incrementally to deliver benefit
over time to its creators
Notice the layers of
planning and
evaluation
code
precise, fine
grained, detailed
design
Story
validate
Iteration
plan
evaluate
Release
plan
abstract,
course grained,
and high level
plan
evaluate
Product/Project
evaluate
© 2006-2009
2008 Jeff Patton
Jeff Patton,
& Josh All
Evnin,
rights
Allreserved,
rights reserved,
www.agileproductdesign.com
All this planning and
evaluation lends lots of
opportunity for course
correction
Notice how planning and
evaluation moves from
course grain to fine
grain, and from abstract
to detailed
Notice how all this
planning and
evaluation at different
levels of abstraction is
going to take a lot of
time?
34
We can flatten these nested cycles to see that at any given
time we’re actually involved in multiple cycles
product
release
release
iteration
daily story
development
cycles
time
©
Patton,
All rights
reserved,
www.agileproductdesign.com
©2006-2009
2008 Jeff Jeff
Patton
& Josh
Evnin,
All rights
reserved,
35
35
Add internal releases to break up long periods
between public releases
release
As a designer you
internal
decide
what the
release
product does at a
larger level. You
validate design and
finished software at a
larger level.
internal
release
iteration
daily story
development
cycles
At any
given time,
product
you’re not just in one
cycle, you’re
operating in many
simultaneously.
time
©
Jeff
Patton,
All All
rights
reserved,
www.agileproductdesign.com
©2006-2009
2006-2007
Jeff
Patton,
rights
reserved,
www.agileproductdesign.com
36
36
The key points:
1. Agile Development isn’t new. It uses strategies as
old as software development
2. Agile developments value system, language, and
rituals makes it resemble a culture more than a
process
3. Common agile practice has emerged as a
combination of practices from many named agile
approaches
4. Cycles of planning, execution, and validation
characterize agile development
5. We’re working in many nested cycles
simultaneously
What’s next: Emergent agile UX practices – how UX
practitioners can thrive in agile environments
Download an agile quick reference guide here:
http://www.agileproductdesign.com/downloads/AgileDevelopmentQuickR37
eference.pdf
Named Agile processes give little or no
guidance for integrating UX practice
(I suspect you’ve noticed this)
38
Salesforce.com’s Craig Villamor describes their five phases of
Agile UX adoption
1. denial
2. anger
3. bargaining
4. depression
5. Acceptance
Craig Villamor
http:/www.craigvillamor.com
Digging in and understanding Agile
values and practice often results in
some pretty innovative UX practice
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
39
Agile process is invented, not followed
Scrum’s creator, Ken Schwaber, describes it as a process
framework, NOT a process.
Your organization must tailor its agile process to fit its context.
That context varies from team to team, and product to product.
Get busy inventing your agile process that accepts both agile and
design culture
http://www.ohgizmo.com/2007/04/16/full-scale-mousetrap-kinetic-sculpture/
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
40
Emergent
Agile UX Practices
41
1. Drive: UX practitioners are part of the product
owner or customer team
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
42
Product ownership must blend a diverse set of skills and
concerns – more than can fit in one head
Business Advocate

Understand the needs of the
organization paying for the
software’s construction and select
a mix of features that serve their
goals
Customer Advocate

Understand the needs of the
business buying the product and
select a mix of features valuable
to the customer
End User Advocate

Describe the product with an
understanding of users and use,
and a product that best serves
both
Subject Matter Expert
Answer technical questions on the domain
for those creating the product
Designer
•Synthesize business, customer, and user
needs into a product design that satisfied
them all.
•Maintain product coherence while
constructing the product iteratively and
incrementally
Communicator
•Capable of communicating vision and
intent – deferring detailed feature and
design decisions to be made just in time
Decision Maker
The Product Owner role is generally filled by a
person supported by a collaborative team
•Given a variety of conflicting goals and
opinions, be the final decision maker for
hard product decisions
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
43
Identify your product ownership practice
Sit down with your product management
team
Discuss how product ownership is being
accomplished
How are each of the concerns of a
product owner being accommodated?
How will you as a UX person help fill the
product ownership role?
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
44
2. Research, model, and design up front - but only
just enough
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
45
Building the product backlog is a phase, not a quick
step – leverage it.
The place in agile development where the
backlog is created is the space for
preliminary research and modeling
Product
Backlog
This first backlog building phase is often
called “sprint 0” or “Iteration 0”
 Identify the business’s goals for the product
 Identify and customers and users then sketch
assumption-based personas
 Create a plan to continuously and incrementally
perform research
 Be involved with user story writing to write user
stories that leverage your user model and describe
use as you see it.
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
46
3. Chunk your design work
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
47
User stories are both description of functionality and planning
item – they’re a “chunk”
It’s a desert
topping!
User stories name a
prospective part of the
system – ideally as a user’s
need
It’s a floor
wax!
Once named we can:


Easy you two… new
shimmer is both a floor
wax, and a dessert
topping!
Shimmer, Saturday Night Live, Season 1
© NBC Studios
move forward to research, design,
and specify that part
but, before that, we can schedule
.that work to perform at an
appropriate time
Stories aren’t the best way to
describe software
functionality, or the best way
to create project plans
But, they’re the only artifact
that attempts to perform both
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
48
Break up design work to perform
incrementally throughout development
Use high level stories to identify major
parts of the system
Design at this higher level for
 Structure for each release
 UI Details for each iteration or sprint
Break down stories to iteration-level
stories just-in-time
 Each iteration level story references higher
level UI design
 Leverage your high level design to describe
acceptance criteria for individual stories
For more on chunking see
Desiree Sy’s Adapting Usability Investigations for Agile User-Centered Design
http://www.agileproductdesign.com/useful_papers/sy_agile_ucd.pdf
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
49
Organize your backlog – don’t just prioritize
My recommendation: Organize stories into a map that helps
communicate the structure of your system.
See “The new backlog is a map”: http://www.agileproductdesign.com/blog/the_new_backlog.html
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
50
Organize your backlog – don’t just prioritize
My recommendation: Organize stories into a map that helps
communicate the structure of your system.
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
51
4. Use parallel track development to work ahead,
and follow behind
+
Lynn Mller’s Parallel track development
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
Dr. Who’s TARDIS
52
Iteration1
• planning
• data gathering
• high level design
• design for
iteration 1
features
• support iteration
1 development
• design iteration 2
features
• gather user input
for iteration 3
features
• development
environment
setup
• architectural
“spikes”
implement
iteration 1 features
Iteration 2
• support iteration 2
development
• design iteration 3
features
• gather user input
for iteration 4
features
• validate iteration 1
features
Iteration 3
• support iteration 3
development
• design iteration 4
features
• gather user input
for iteration 5
features
• validate iteration
1-2 features
support dev
Development Team
iteration 0
support dev
Product Owner Team
Design and coded features pass back and forth
between tracks
implement
iteration 2 features
fix iteration 1 bugs
if any
implement
iteration 3 features
fix iteration 2 bugs
if any
time
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, All rights reserved, www.agileproductdesign.com
53
5. Buy design time with complex engineering
stories
User stories schedule the construction of a
complete piece of software including:
 Time to design and specify
 Time to develop
 Time to test
Even out workflow by scheduling stories
heavy in design with stories lighter in
design and heavier in development
The goal is even flow
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
54
6. Cultivate a pool of users for continuous user
validation
Identify users ready to act as subjects
for research and testing
Schedule involvement with them
ahead of knowing what you’ll be
working with them on
Keep your feedback fresh by rotating
users through your pool visiting an
individual only user every few months
See Williams’ The UCD Perspective: Before and After Agile:
http://www.agileproductdesign.com/useful_papers/ucd_perspective.pdf
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
55
7. Schedule continuous user research in a separate
track from development
You know you didn’t get enough time for
research before development started
You know you’ve only identified “chunks”
of design work as user stories or backlog
items
Kitchen Stories, © 2003 BOB Film Sweden
http://www.imdb.com/title/tt0323872/
Schedule research within your user pool
and with other potential users, as a
continuous activity
Use scheduled research times to
research upcoming “chunks”
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
56
8. Leverage time with users for multiple activities
Leverage scheduled time with users and
customers to:
 Perform contextual inquiry or other types of
research to identify needs and prospective use
 Get feedback on design work in progress
 Get feedback on the working product
You’ll be working on design 1-2 sprints
ahead, and vetting software built in past
sprints
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
57
9. Use RITE to iterate UI before development
Use time before the sprint or
iteration to refine design
Prototype, iteratively test and refine
UI using RITE: Rapid Iterative
Testing and Evaluation
Adding Usability Testing to an Agile Project
http://www.agileproductdesign.com/useful_papers/meszaros_agile_usability.pdf
Using the RITE method to improve products; a definition and a case study:
http://www.agileproductdesign.com/useful_papers/rite_method.pdf
Getting Software RITE:
http://www.agileproductdesign.com/writing/ieee/patton_getting_software_rite.pdf
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
58
10. Prototype in low fidelity
As collaboration between
developers increases;
And, As time between
design and implementation
decreases;
You’ll find lower and lower
fidelity design will suffice.
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
59
11. Treat prototype as specification
Allow your prototype to be
your product specification.
Communicate details of
your prototype in a
collaborative meeting with
developers and testers.
Let them ask questions
and take notes or annotate
as they need to
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
60
12. Become a design facilitator
Use facilitated
workshops to:
 Collect and analyze
information
 Ideate design ideas
 Socialize design
 Share research
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
61
Practices like Design Studio and Sketchboard help us
collaboratively design and ideate
Design Studio Approach
http://interaction08.ixda.org/Jeff_White%20and%20Jim%20Ungar.php
Sketchboarding
http://www.adaptivepath.com/ideas/essays/archives/000863.php
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
62
An effective designer and agile product owner leverages
facilitation
“Design isn’t something that designers
produce, design is a process that
designers facilitate.”
--Leah Buley
Ideally everyone on your agile team
becomes a design thinker.
Leah Buley
http://www.adaptivepath.com/about
us/leah.php
Use facilitation to allow the team to
participate in an effective design
process.
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
63
Collaboration doesn’t mean you don’t design
“Design by community is not design by
committee”
--Leisa Reichelt
Leisa Reichelt
www.disambiguity.com
Leverage your users, customers, and team to
gather information and socialize decisions
Make strategic decisions as a product
ownership team
Make tactical design decisions as a designer
and product owner
© 2006-2009 Jeff Patton, All rights reserved, www.agileproductdesign.com
64
If we judged our design process not on the
quality of our specification, but on the
quality of our resulting product, what would
that design process look like?
For me, agile development represents
today’s best hope for high quality products.
65
“For our user experience
team, agile user-centered
design resulted in better
designed software than
waterfall user-centered
design.
Agile communication
modes narrowed the gap
between gathering
usability data, and acting
on it.”
-- Desiree Sy, Autodesk
66
Agile UX
Primer
or: how I
stopped worrying
and learned to
love the bomb
Jeff Patton
© 1964, Columbia Pictures
[email protected]
AgileProductDesign.com