Integrating Agile development
with User Experience design
Jennifer Ferreira
jen.ferreira@ucalgary.ca
Helen Sharp, Hugh Robinson
• Integrating Agile development with UX
design
• Integrating Agile development with UX
design
•
Problem?
• Integrating Agile development with UX
design
•
Problem?
• Workplace studies
• Integrating Agile development with UX
design
•
Problem?
• Workplace studies
• Achieving integration
• Integrating Agile development with UX
design
•
Problem?
• Workplace studies
• Achieving integration
• Implications
Agile development + UX design
XP
Scrum
FDD
ASD
•
•
•
•
•
•
•
•
interaction design [Patton 2002a]
usage centered design [Patton 2002b]
discount usability engineering [Kane 2003]
rapid contextual design [Beyer et al. 2004]
user experience design [Hodgetts 2005]
user centered design [Miller 2005]
scenario-based design [Lee and McCrickard
2007]
goal-directed design [Cho 2009]
ISO CD 9241-210
“all aspects of the user’s experience
when interacting with the product,
service, environment or facility.”
indicative of the collection of methods,
tools, techniques, etc. for involving and
maintaining focus on the end user in
software development
- understand users
- design
- evaluate
WORK
indicative of the collection of methods,
tools, techniques, etc. for involving and
maintaining focus on the end user in
software development
- understand users
- design
- evaluate
Agile development + UX design
•
•
The place of UX design in Agile development
When what happens
•
•
The place of UX design in Agile development
When what happens
- Up front
- In the Agile iterations
•
•
The place of UX design in Agile development
When what happens
- Up front  BDUF
- In the Agile iterations
•
•
The place of UX design in Agile development
When what happens
- Up front  BDUF
- In the Agile iterations
•
•
The place of UX design in Agile development
When what happens
- Up front  BDUF
- In the Agile iterations  too short
•
•
The place of UX design in Agile development
When what happens
- Up front  BDUF
- In the Agile iterations  too short
comparisons of values and
principles  process
e.g. both Agile and UX are
iterative
and both focus on the
customer/end user
“The two-track organization is
what we aimed for, although in
reality it was a little more
complex. Some designs needed
longer than a single cycle to
complete. For example, one
particularly troublesome feature
took us over 5 cycles before the
design passed all of its goals.”
Lynn Miller, "Case Study of Customer Input For a Successful Product," Agile
Development Conference, pp. 225-234, Agile Development Conference
(ADC'05), 2005.
PhD thesis
• How is integration accomplished on a
day-to-day basis?
•
Singer et al. “… little is known about how
software engineers perform their work. In order
to improve software engineering tools and
practice, it is therefore essential to conduct field
studies, i.e., to study real practitioners as they
solve real problems.”
Janice Singer, Susan E. Sim, and Timothy C. Lethbridge (2008) Software
Engineering Data Collection for Field Studies. Guide to Advanced Empirical
Software Engineering. Forrest Shull, Janice Singer, Dag I.K. Sjøberg Editors.
Pages 9—34, ISBN-13: 978-1-84800-043-8.
• How is integration accomplished on a
day-to-day basis?
•
Only 4 of 23 empirical studies included
observations of practice in work settings
• How is integration accomplished on a
day-to-day basis?
•
Only 4 of 23 empirical studies included
observations of practice in work settings
 Study practitioners in the workplace
project
size
Team1
Team2
Team3
Team4
web
web
mobile
mobile
16
4
7
6
Scrum
Scrum
Scrum
yes
yes
yes
no
>1000
50
Agile method Scrum
UX role
organisation
<50
all three organisations
• successful at delivering software
• highly valued UX design
• used Scrum
different experiences of practice
all three organisations
• successful at delivering software
• highly valued UX design
• used Scrum
different experiences of practice
the best way to create software
• Integration
•
•
On-going – negotiated, day-to-day,
individuals
Achieved – variety of conditions:
1. Developers and designers were kept apart
2. Developers and designers were working
closely together
3. Developer designers were trialling working
closely together
• Expectations about acceptable
behaviour
• Mutual awareness
• Negotiating progress
• Engaging with each other
• Expectations about acceptable
behaviour
• Mutual awareness
• Negotiating progress
• Engaging with each other
• expectations about how the other
group behaves
•
what developers expect
-- due to Scrum commitments
• what UX designers expect
-- due to UX design commitments
“Could we have a
meeting to give you
some feedback?”
“What kind of feedback
do you want to give?”
developers: expected
to provide feedback as
issues arose
designers: expected
to hand over designs
and move onto the
next project
developers:
expected
designers to provide
timely redesigns
designers: not
expecting on-going
conversations
Apart
“Which would be
easier to
implement?”
“Either would
be fine.”
designers: expected
developer to
answer their
questions
designers:
expected that the
developer could
answer their
questions
developer:
expected
that the designers
would have
questions
Together
designers:
expected
developer to have
useful input
• Expectations about acceptable
behaviour
• Mutual awareness
• Negotiating progress
• Engaging with each other
• UX designers being aware of what
constitutes work for Agile developers
• Agile developers being aware of what
constitutes work for UX designers
• levels vary between the teams
Mutual awareness
“Are the designs
ready?”
“We're moving desks
today.”
Agile developers and
UX designers seated
on different floors
rigid role
boundaries
Agile developers and
UX designers on separate
teams
tense
Apart
Mutual awareness
fluid role
boundaries
bonded
team
on-going
conversations
relaxed
Together
• Expectations about acceptable
behaviour
• Mutual awareness
• Negotiating progress
• Engaging with each other
• Maintaining workflow under
uncertainty
• client expectations? (market,
dependencies on other projects)
• requirements
• decision-makers are not always
available
• teams make progress in spite of this –
they HAVE to
“Could we have a
meeting to give you
some feedback?”
“What kind of feedback
do you want to give?”
reluctant
phased
formal
a set of activities
constrained
Apart
“What do you
remember from
the client meeting?”
“I think they wanted
more pop.”
on-the-fly
informal
agreed
together
Together
• Expectations about acceptable
behaviour
• Mutual awareness
• Negotiating progress
• Engaging with each other
• developers and designers do 2 types of
work:
•
•
own
together
switch
• input
•
•
decision-making
expertise
“Could we have a
meeting to give you
some feedback?”
“What kind of feedback
do you want to give?”
explicit
require design
expertise to
proceed
designers leading,
developers releasing
software
developers
approaching
designers
Apart
“What do you
remember from
the client meeting?”
“I think they wanted
more pop.”
implicit
status updates
solution is negotiated
clarifications
Together
Achieving integration
Systematic, separatist approach
• walking around, finding
• meetings, logistics
• communicating via documents, up to date
“Are the designs
ready?”
Apart
“We're moving desks
today.”
Achieving integration
Subtle, on-going effort
• shared awareness of design values and
technical constraints
• shared decision-making
Together
• Not just about process
• Teams are not isolated
• Not just about seating the developers
with designers (i.e. colocation)
• Integration is shaped by organisational
and team-level factors
 views on how best to create software
 views on how best to create software
• Implications
• for processes and tools
• team arrangements
• Supporting and maintaining
• expectations about acceptable
behaviour
• mutual awareness
• negotiating progress
• engaging with each other
• Not about co-location
 working closely together
 achieved in different ways
1. Valuing input from different roles
2. Enabling roles to work together
3. Understanding and sharing
responsibilities