Agile software development practices continue to dominate organizations and user experience research and strategy are more necessary than ever, but incorporating research doesn’t always jive with the established practices of Agile. Many of us are still at a loss for making research happen in Agile settings. This session will cover recommendations for setting up the logistics to best facilitate research and specific tips to plan, run, and analyze research effectively within an Agile environment. Introduction with a brief summary of Agile development practices and the specific challenges the practices present for those us trying to incorporate research well Lack of dedicated discovery time Focus on working software as measure of progress Team structure double-edged sword For each section I’ll tell a little story about times these things have bitten me in my own work I’ll then transition into discussions of solutions for those challenges, making specific suggestions around the following areas: Team makeup: I’ll suggest that when at all possible, it’s great to have both a full time designer and researcher on each cross functional team. More realistically, there will be one full time designer and a floating researcher. At a minimum, I suggest having at least one UX person of some kind on each team and having them pair up across projects to help fight bias in their research efforts. Setup and logistics: I’ll talk through some of the boring, practical, but extremely useful logistical elements of making research run smoothly in an Agile environment, including setting a research cadence and setting aside time every sprint, building a database of participants, and allowing self-scheduling of sessions. I’ll also talk about the option to use unmoderated tools with panels, which will lead into a discussion about how to adapt specific methods. Research planning: I’ll talk about narrowing the scope of research to answer specific questions, borrowing from Lean Startup to craft assumption-based hypotheses. I’ll then go into discussion about choosing or altering methods to maintain reasonable rigor in the limited time, and put the focus on conducting iterative rounds of similar research. Data analysis and integration: I’ll then discuss ways to involve the team throughout the process so that everyone learns together, rather than it being the onus of a UXer to do research separately and then spend time teaching and convincing the team. I’ll talk the logistics of having frequent debriefs and discussing UX findings during retrospectives, and focusing on creating solutions together.

1. Hello, Cornwall!
@MandaLaceyS
#AgileOTB

2. Adjusting
UX
Research
for an
Agile
World @MandaLaceyS
#AgileOTB

3. Agile fixes everything!
@MandaLaceyS
#AgileOTB

4. @MandaLaceyS
#AgileOTB

5. @MandaLaceyS
#AgileOTB
You can’t measure
learning in lines of
code.
@MandaLaceyS
#AgileOTB

6. @MandaLaceyS
#AgileOTB
No dedicated
research time
sometimes means no
time at all.
@MandaLaceyS
#AgileOTB

7. @MandaLaceyS
#AgileOTB
UX is meant to be a
team sport.
@MandaLaceyS
#AgileOTB

8. Let me tell
you a
secret.
@MandaLaceyS
#AgileOTB

9. There’s no such
thing as the
“right way”
to do research
in Agile. @MandaLaceyS
#AgileOTB

10. THREEFIVETWO/@MANDALACEYS
10
We’re all
special
snowflakes.
Yep.
@MandaLaceyS
#AgileOTB

11. Team Makeup
@MandaLaceyS
#AgileOTB

12. Cross-functional isn’t
just for devs.
Backend Dev Front end dev UX designer QA testerBack end devUX researcher
@MandaLaceyS
#AgileOTB

13. Backend Dev Front end dev UX designer QA testerBack end devUX researcher
Cross-functional isn’t
just for devs.
@MandaLaceyS
#AgileOTB

14. Cross-functional isn’t
just for devs.
Backend Dev Front end dev UX designer QA testerBack end devUX researcher
@MandaLaceyS
#AgileOTB

15. Second best.
Research
Team
Backend Dev Front end dev UX designer QA testerBack end dev
Backend Dev Front end dev UX designer QA testerBack end dev
@MandaLaceyS
#AgileOTB
Backend Dev Front end dev UX designer QA testerBack end dev

16. UXICORN
Backend Dev Front end dev
QA tester
Back end dev
Backend Dev Front end dev
QA tester
Back end dev UXICORN
@MandaLaceyS
#AgileOTB
It’ll do. But…

17. How much do you love this thing I made?
@MandaLaceyS
#AgileOTB

18. Setup and logistics
@MandaLaceyS
#AgileOTB

19. Make research a part of the schedule.
@MandaLaceyS
#AgileOTB

20. @MandaLaceyS
#AgileOTB
And hold it sacred.

21. But. Don’t lose sight of the big picture.
@MandaLaceyS
#AgileOTB

22. @MandaLaceyS
#AgileOTB
Allow self-scheduling.

23. @MandaLaceyS
#AgileOTB
Make your own panel.

24. Research Planning
@MandaLaceyS
#AgileOTB

25. Write
specific
hypotheses
to narrow
scope.
@MandaLaceyS
#AgileOTB

26. If we [do, build, provide x thing],
then [these people]
will [some desirable outcome].
We’ll know when [actionable metrics].
@MandaLaceyS
#AgileOTB

27. PROTIP
The more specific your
hypothesis, the easier it will be
to plan research
AND come to conclusions.
@MandaLaceyS
#AgileOTB

28. Use
Franken-
methods.
@MandaLaceyS
#AgileOTB

29. Balance
flexibility
and
rigor.
@MandaLaceyS
#AgileOTB

30. When in
doubt,
recycle.
@MandaLaceyS
#AgileOTB

31. Share the load.
@MandaLaceyS
#AgileOTB

32. Pro tip:
Bribery is
OK
@MandaLaceyS
#AgileOTB

33. Data Analysis and
Integration
@MandaLaceyS
#AgileOTB

34. Include
everyone
in
sessions
and
analysis.
@MandaLaceyS
#AgileOTB

35. Remember
If you set a specific, targeted
hypothesis, analyzation is easier.
@MandaLaceyS
#AgileOTB

36. 1) Stay the
course.
@MandaLaceyS
#AgileOTB

37. 2) PIVOT!
PIVOT!
PIVOT!
@MandaLaceyS
#AgileOTB

38. Sometimes the
next path is
really clear.
@MandaLaceyS
#AgileOTB

39. 39
Sometimes…not.
@MandaLaceyS
#AgileOTB

40. Find
solutions
together.
Awesome image from WOCinTech Chat
@MandaLaceyS
#AgileOTB

41. Find
simple
ways to
keep
everyone
in the
loop. @MandaLaceyS
#AgileOTB

42. Actively
add to
the
backlog.
@MandaLaceyS
#AgileOTB

43. @MandaLaceyS
#AgileOTB

44. Thank you!
@MandaLaceyS
stockwellstrategy.com

45. G’night!