As presented at Big (D)esign 2011. This provides designers, developers, and product owners with tools to build a shared language for UX in Agile development, based on the tenets and terminology of the Agile community.

1. Conversations for User Experience
in Agile Development
Jim Carlsen-Landy

2. Is
about working across
functional lines
 applicable to designers,
developers, product
owners, and managers
 how to communicate about
design and development
during the process

Is
intro to Agile or how to get
Agile into your org
 critique of Agile or how to
keep Agile out of your org
 how to do better design
 how to communicate
specific design elements
 a definition of a specific
way of practicing Agile UX
 how to cram 3 months
worth of design into a 2week iteration

2

3. Who am I?
Why might you care what I
think?
3

4. Who am I?
Why might you care what I
think?
4

5. Who am I?
Why might you care what I
think?
5

6. Who am I?
Why might you care what I
think?
Without music to decorate it,
time is just a bunch of boring
production deadlines or dates
by which bills must be paid.
- Frank Zappa
6

7. And you are…








Designer?
Developer?
Product owner?
Project manager?
Scrum Master / Agile coach?
Manager?
Lone wolf?
Are you “doing” Agile?
or does your organization just say you’re doing
Agile?
7

8. For the attention span impaired
Talk about value
Refactor and reprioritize
Speak your team’s language
8

9. You’ve heard this part before
Design is different from development.
Years of waterfall thinking have created a divide.
By-the-book Agile is very development-centric.
Even the best professionals will
 crawl into their comfort zone under pressure
 use the secret language of their profession to
reinforce their authority
Is anyone surprised that we don’t communicate
well?
9

10. It’s in there, somewhere
10

11. It’s in there, somewhere
Individuals and interactions over processes and tools
11

12. It’s in there, somewhere
Responding to change over following a plan
12

13. Common Goals
What is your goal at work?
Is everyone around you aligned on that goal?
Does everyone agree on the exact details of
everything that gets done each day toward
achieving that goal?
13

14. It’s all about value
http://www.visualthesaurus.com
14

15. It’s all about value
Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.
[We value] Working software over
comprehensive documentation
http://www.agilemanifesto.org
Deliver valuable working software at the end of
every iteration.
http://www.visualthesaurus.com
15

16. What has greater value?
http://www.mathworks.com
16

17. What has greater value?
http://f2.washington.edu
17

18. What has greater value?
http://dribbble.com/FransTwisk
18

19. What has greater value?
http://www.jnd.org
19

20. Who decides value?
User value
 usability, appeal, efficiency, fitness to purpose
Business value
 cost vs return (ROI)
Developer value
 velocity and (usually) code quality
Your Product Owner defines value on your team
20

21. Why is user experience valuable?
Failure at the glass inhibits the value of
otherwise completed working
software
Usability is the last few inches of value
delivery
Is your user experience hiding value
from the users, or optimizing it?
21

22. Value questions
What you’ve requested is expensive / risky /
time-consuming / whatever.
Would you be willing to get this valuable
alternative instead, at lower cost / risk / time?
What would you ask for if you knew the project
would be shut down after this iteration?
22

23. Value exercises
Give everyone $100 to spend how they want
Every feature has a price proportional to effort
Adam Polansky “Spread It, Split It, Stack It”
bigdesignevents.com/2011/04/video-spread-it-split-it-stack-it-threemethods-for-qualifying-content/
Luke Hohmann’s “Innovation Games”
www.innovationgames.com
23

24. Common Language
24

25. Common Language













Acceptance criteria
Agile coach
Backlog (iteration, product,
release)
Create no unnecessary
documentation
Definition of done
Emergent or Evolutionary
architecture
Iteration or Sprint
Iteration demo
Iteration planning
Iteration zero
Last responsible moment
Pair programming
Pigs and Chickens
















Planning poker
Product owner
Refactoring
Retrospective
Rework
Scrum or Standup
Scrum Master
Simple design
Spike
Story points
Sustainable pace
Task
Technical debt
Time-box
User story
Velocity
25

26. Common Language
Planning
Coping with change
On the team
26

27. Planning
User story and task
Backlog
Iteration planning
Velocity
Sustainable pace
27

28. Planning
Release A
Design Itr 1
Release A
Design Itr 2
Release A
Design Itr 3
Develop Itr 0
Release A
Develop Itr 1
Release A
Develop Itr 2
Release A
Develop Itr 3
Release A
Release B
Design Itr 1
Release B
Design Itr 2
Release B
Develop Itr 1
Release B
Release Plan
Release B
Design Itr 3
Release B
Develop Itr 2
Release B
Develop Itr 3
Release B
Release C
Design Itr 1
Release C
Design Itr 2
Release C
Release Plan
1
2
3
4
5
Weeks
6
7
8
9
10
11
12
13
Release C
Develop Itr 1
14
15
16
17
28

29. Planning – User Story and Task
The fundamental units of work in Agile
Rae Scott
Reservation Agent
Work Experience
Rae Scott has been working as a Reservation Agent for the past 5 years. She is a high school
graduate. When she started her job, Rae spent weeks in company-sponsored training programs in
order to learn the reservation system and other travel-related
information and to understand airline rules and procedures.
After completing her classroom instruction, she worked under
the direct guidance of a supervisor and a lead for three months.
Goals and Tasks
User stories are not always about “users”
Reservation Agent

Experience: 5 years

Makes flight reservations and
accepts payment

As <persona> I want to <do something>
so that I can <achieve a goal>.

Gathers information from the
caller to identify customer needs
and determine appropriate action

Searches for availability, frequent
flyer miles, seats, car rentals,
hotels and history

Documents the conversation for
each call. Reports all actions at
the end of the shift

Needs to be efficient and quick
“I like the flexibility of
schedule that comes
Rae’s main responsibilities are to provide travel information
with this position!”
over the telephone to customers of the airline, make flight
reservations and accept payment over the phone for ticket
purchases. Rae assists callers with trip planning, car rentals,
seat availability, fare information, schedules, tours, meals and
other information relevant to the customer's flight plans. Rae
asks the caller for their travel dates and destination cities. Rae has to have access to the caller’s
frequent flyer miles information as well as to the caller’s family’s frequent flyer miles information as
using family members miles is very common. In addition, she needs to search for class and seats
available for frequent flyer miles travelers.
In the case of any change request, Rae looks up the itinerary based on the confirmation number of
the ticket. Travelers often call with a destination change or to change the schedule to a multi-city trip.
Rae has to have access to rules, fees and penalties associated with the requested changes. When
travelers request seats together with their companions, she needs to look up the seats available for
companion class and the details of the extra charges for that. Rae also has to lookup, change or
confirm car rentals and hotel reservations. At end of each call, Rae documents the conversation and
the decisions made. For some calls she needs to write a special note for Ticketing or Pricing Agents.
At end of each day, Rae needs to create a report with the number of tickets issued each day.
Work Environment
Rae works at the reservation call center which has individual desks four to five feet wide with a
divider between them. She operates a telephone headset and uses the reservation system on a
computer network. Rae uses a 17 inch monitor like the rest of the agents. Since her seniority level is
not that high, she does not always get the shift of her choice. Her shifts vary greatly as reservation
offices are open twenty-four hours a day. The call center environment is often hectic, noisy and
stressful. Rae has to work very efficiently and accurately, often handling multiple calls
simultaneously.
Design and development stories in one repository
 Talk about them together
Task
 Break it down. Everything can’t happen at once.
29

30. Planning – Backlog
Product backlog
Fill
 vision
Release backlog
Groom
Prioritize
 product versions
Iteration backlog
Deliver
Develop
 deliverable unit
30

31. Planning – Iteration planning
How the work for the iteration (Sprint) gets defined
Everyone has to be in the game
 or I guarantee you will be less successful
 attend all iteration planning and estimating meetings
Iteration zero
 aka “big architecture up front”
 not always there, but listen for it and use it
31

32. Planning – Velocity
The true development capacity of your Team
When you know the how far the team will get
in an iteration you can keep specification,
design, and development flowing
http://www.chandoo.org
32

33. Planning – Sustainable pace
Iteration velocity bounds the sustainable pace
Detailed vision one step ahead of design
Detailed design one step ahead of
development
… but no more than that
33

34. Coping with change
Embracing change
Agile Manifesto:
We value “Responding
to Change over
Following a Plan”
Agile Principle:
“Welcome changing
requirements, even late
in development. Agile
processes harness
change for the
customer's competitive
advantage.”
http://www.agilemanifesto.org
34

35. Embracing change
Refactoring
Create no unnecessary documentation
Simple design
Spike
35

36. Embracing change – Refactoring
(this one is important)
Everybody should be talking about refactoring
Refactor code as it is written
Refactor design as the product grows
Refactor vision as the market moves
36

37. Embracing change – Refactoring
“Why do the product requirements keep changing?”
“Why does the design keep changing?”
“Why are the developers changing code that works?”
“Why can’t <everyone else> just make up their mind??!!”
Beware of these poisonous pseudo-synonyms:
Refactoring ≠ Scope creep
Refactoring ≠ Gold-plating
Refactoring ≠ Rework
37

38. Embracing change – Documentation
Create no unnecessary documentation
 do not detail stories that might not get worked
 do not rush to high fidelity
Documents should be
 lightweight
 fast to produce
 easily consumed
 painless to change
38

39. Embracing change – Simple design
Simplicity – the art of maximizing the amount
of work not done – is essential
http://www.agilemanifesto.org
Build vision
create design
write code
for what you know you need
Defer everything else
39

40. Embracing change – Spike
Focused experiment
 very short, as little as a half-day
 usually vertical
 reduces (or at least bounds) risk
Use design spikes to make fast decisions
 paper prototype
 A/B test
 usability testing on the cheap
Don’t argue about it, spike it out
40

41. On the team
“The Team consists of developers with all the
skills to turn the Product Owner’s
requirements into a potentially releasable
piece of the product by the end of the
Sprint.”
The Scrum Guide, Ken Schwaber & Jeff Sutherland
http://www.scrum.org/scrumguides
41

42. On the team
Definition of done
Pigs and Chickens
Standup, aka Scrum
Pair programming
Iteration demo
42

43. On the team – Definition of done
Done = a potentially shippable increment of the product
How done is “done”?




coded?
unit tested?
documented?
performance
& scale tested?
 integrated?
 usability tested?
 packaged?
 installed?
Each Team defines “done”
 who has authority to say that it’s not done until it’s usable?
43

44. On the team – Definition of done
There is no partial credit, only Done and Undone
Rollover is considered bad in many organizations
Dangerous anti-patterns
 redefining “Done” to prevent rollover
 allowing work to be “Done” without
a GUI
44

45. On the team – Pigs and Chickens
45

46. On the team – Pigs and Chickens
If Team members with critical skills act like
Chickens, the Team is incomplete
46

47. On the team – Standup, aka Scrum
Attend.
47

48. On the team – Pair programming
Design and develop real-time
(really – try it)
Practice pair designing
48

49. On the team – Iteration demo
Get feedback quickly and often
Let the Chickens see progress
Many teams show not-quite-done work
 If yours does, show design for the next iteration
49

50. With your secret decoder ring,
now you can:
Turn disagreements into value discussions
 what can we do to generate the most value?
Embrace change by refactoring
 maximize what is not done – you’ll be smarter later
Speak the Team’s language
 common terminology streamlines conversations and
accelerates value delivery
50

51. Stalker guide
51

52. Stalker guide
www.linkedin.com/in/jimcl
jim.carlsenlandy@gmail.com
@JimCL42
52