UX vs and Agile: Getting the best out of both worlds is a document that discusses combining UX and Agile approaches. It describes a design sprint case study where a team conducted user interviews, generated and iterated on ideas, created prototypes, and validated prototypes with users. The document also outlines different approaches for integrating UX and Agile processes, such as having UX occur before development, within sprints, or using hybrid models. It emphasizes the importance of collaboration, gaining user feedback, and balancing short and long-term goals.

1. UX vs and Agile:
Getting the best out of both worlds
27 July 2017

2. © why innovation! 2
Short and sharp
Hong Kong Lead for why
innovation!
Boutique consultancy
dedicated to unlocking the
collaborative and creative
power hidden within
individuals and
organisations
Likes to think he is an
Agile expert, not an UX
expert, complains a lot
about why a lot of cafes all
look the same.
Http://www.linkedin.com/darylchan
Http://bit.ly/why-innovation.com

3. © why innovation! 3
This tweet.

4. © why innovation! 4
99 problems

5. © why innovation! 5
UX is…

6. © why innovation! 6
999 problems

7. © why innovation! 7
Agile is…

8. © why innovation! 8
Are the goals different?

9. © why innovation! 9
UX and Agile…

10. © why innovation! 10
Case study – it can work.
Let’s look at just one of the popular methods going
around – Design Sprint
This is only one of many ways to combine UX and
Agile

11. © why innovation! 11
Design Sprint
Created by Google Ventures, popular but not the only way to
combine Agile + UX
Addresses design challenges in a short amount of time

12. © why innovation! 12
Day 1 - Understand
The entire team sat down together to understand what need to
be done for five days within the design sprint
We went out to interview people about their experience with
the existing process
Developer DesignerCustomer

13. © why innovation! 13
Day 1 – Interview questions
Questions asked
What do you like about the current process?
How does the current process make you feel?
What do you dislike?
How do these things you dislike make you feel?
What would you like to see improved?
What overall feeling do you want to have from this
experience?
Empathy maps
Common threads explored as a group
(delayed to day 2 – we ran out of time!)

14. © why innovation! 14
Day 2 - Diverge
Formulate strategy together (challenge map, target, user
journey, design principles)

15. © why innovation! 15
Day 2 - Sketch

16. © why innovation! 16
A small exercise
Key concept in Agile
How to generate ideas collaboratively?
How to establish shared understanding?
One example: iterations using Crazy Eights

17. © why innovation! 17
Crazy Eights?
Do it.
You have three minutes.

18. © why innovation! 18
Now get some feedback

19. © why innovation! 19
Crazy Eights, again.
Do it.
You have three minutes.

20. © why innovation! 20
The heart of Agile
The iterations can continue almost indefinitely,
changing every time to get different feedback (come
up with one idea as a group, storyboard, ritual
dissent, Six Thinking Hats…)

21. © why innovation! 21
What we ended up with…
We sketched our own ideas for the app individually, before
sharing as a group and iterating on original ideas

22. © why innovation! 22
Day 3 - Decide
Create the storyboard of the best ideas
Voted on what gets built as the prototype
Good facilitation is key; clear decision making process can help

23. © why innovation! 23
Day 4 - Prototype
Build it.
If it’s on screen:
PowerPoint, Keynote, Microsoft Word, Squarespace etc
If it’s an app
Marvel, InVision, Ionic, or even go Native!
If it’s a physical object
3D print it
If it’s a physical space
Modify an existing space
If it’s a service
Write a script
Use your sprint team as actors!

24. © why innovation! 24
Day 4 - Links to the prototypes
Simple “working” product using
Invision
Multiple prototypes were built to get
different types of feedback
One team member even decided to
code all the front-end natively!

25. © why innovation! 25
Day 5 - Validate
The team went back downstairs to validate prototypes with
users and get feedback

26. © why innovation! 26
Conclusion
What went well?
First time that the team was able to directly speak to the end-
user and modify their acceptance criteria for product backlog
(and feed ideas back to the product owner)
Team were able to build trust with each other very quickly.
Greater understanding of ‘shorter feedback loops’ and
‘frequent release’ compared to previous projects
Team were able to mobilise extremely quickly
What didn’t go so well?
Final prototype quality slightly compromised due to time
constraints (more research or higher fidelity prototypes could
have been created)

27. © why innovation! 27
Conclusion - continued
What lessons can other teams learn from this exercise?
Run design sprints even earlier in the project (before too much
other analysis has taken place)
For suitable projects, use design sprint to validate business
case/project assessment
Ensure that this prototype only contains the true MVP from the
Product Backlog. Any other activity should be saved for the
actual Agile ‘execution’
Product Owner still needs to make the final decision

28. © why innovation! 28
From that point onwards…
With all that feedback, the team had a product roadmap and
design blueprint, and started working in Scrum… a story for
another day!

29. © why innovation! 29
Other approaches for Agile and UX
Here we will use Scrum as an example to explain
other approaches (this is the most popular, but not
the only framework for guiding Agile teams)

30. © why innovation! 30
1. UX before development
‘Pre-production’
activities occur before
the sprint
UX production and
development occur
during the sprint
+
Time and space for UX
pre-production to take
place
-
Encourages too many
hand-offs and
communication gaps
between teams - you
don’t find out about
problems until it’s too
late

31. © why innovation! 31
2. UX within the sprint
All UX and development
occurs during the sprint
+
Highly collaborative
Only the necessary
features for that sprint
are worked on
‘Why build a wireframe
if it takes me the same
amount of time to code
the frontend?’
-
Can be high pressure if
features are complex
Can lead to tendency to
neglect longer-term
thinking

32. © why innovation! 32
3. “Design Sprint” sprints
Pre-production done
collaboratively before
any ‘real’
development starts
+
Shared understanding
All team is able to
engage with user
-
Can encourage silos if
development is
component rather
than feature driven
Teams can struggle
with ‘sizing’ work to
fit within the sprint

33. © why innovation! 33
4. Hybrid models
All UX done within
the sprint but in
parallel with longer
term planning
activities
+
Balance of short-
term and long-term
thinking
-
Can require lots of
context switching

34. © why innovation! 34
What approach would you choose?
1. UX before development
2. UX within the sprint
3. “Design Sprint” sprints
4. Hybrid model
What would you choose if you were
Enhancing a simple, existing feature?
Delivering a complex product to market first
time?
Had a fully ‘full-stack’ team and access to users?

35. © why innovation! 35
What factors to look for?
Problem statement definition
The clearer the problem and understanding
around it, the more you can be oriented to detail
The more uncertainty
The more experimentation/research you may
need to do
Prioritisation – need for feature/user to be delivered
right now
You can delay unnecessary work until a later
stage
You can be Agile even in the experimentation/pre-
production phase

36. © why innovation! 36
One thing…
What’s one thing you will do differently next time for
your UX and Agile initiative?

37. © why innovation! 37
Thanks!
Thanks to Adrian from why innovation! for leading
the Design Sprint,
Jelena from why innovation! for shaping this idea
HUGE thanks to Ada Yuen for shaping the content
and providing the UX angle
Sorina, Elaine and the rest of the IxDA crew for
organising!

38. © why innovation! 38
Don’t forget…

39. © why innovation! 39
Thanks!
http://www.why-innovation.com