

Why Agile teams shouldn't be speaking to users every week - UXM
source link: https://www.uxforthemasses.com/continous-discovery/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.


Why Agile teams shouldn’t be speaking to users every week
2 minutes read
What are some of things you do on a weekly basis at work? Attend a weekly planning meeting? 1-2-1 with the boss? Lunch with the team? How about speak to your users? If you’re part of an Agile team this might be something that you’re doing on a weekly basis, or perhaps striving to do.
In an attempt to squeeze user research into an Agile process, there’s been a push in many organisations to focus on small, frequent research, rather than research activities at the beginning of a project. Championed by thought leaders such as Teresa Torres, this approach has become known as continuous discovery:
Continuous discovery is an approach to user research used in agile teams where research is conducted as small, frequent activities throughout the product development lifecycle. This infuses customer feedback into all product decisions instead of focusing on one-time research activity at the beginning of a project.
Interaction design foundation
Rather than upfront research which can potentially slow things down, teams undertake ongoing user research to inform product decisions, usually in the form of weekly research sessions with users. Surely a team continually speaking to your users is a good thing, is it not? Well in theory yes, in practice, I don’t think so.
When teams undertake continuous discovery, they tend to set-up weekly research sessions with users, such as 1 or 2 sessions on say a Wednesday afternoon. However, because planning, recruiting and analysing sessions every week takes significant time and effort, these sessions either consume a lot of a team’s weekly resources, or effort is kept to a minimum, so they invariably turn into unstructured chats with whoever a team can get easily get hold of. Teams tell themselves that they are carrying out important user research, when in reality they’re having fireside chats with random users. This counterproductive behaviour can be amplified when teams are measured by the number of users they speak to. Teams will go through the motions with users simply because they need to hit their target of speaking to X users a week.
Continuously undertaking poorly planned user research not only means that there is less time for a team to do other important work, it can lead to them making poor decisions based on the input from just 1 or 2 users; users who might not even be representative of the wider user base. For most qualitative user research, it’s a good idea to speak to at least 8-10 users (more if there is a very diverse user base) since you’re looking for trends. If a team is speaking to only 2 users a week, then it will take a month to speak to 8 users. If a team is only speaking to 1 user a week it will take 2 months. That doesn’t sound very Agile to me.
Don’t get me wrong, I’m not against the concept of continuous discovery, it’s the X user sessions a week approach that many teams take that I’m against. Rather than ‘Continuous discovery’ I think that teams should be aiming for regular bursts of discovery. In my experience teams are better off carrying out 1-2 days of focused user research a month, rather than 1 or 2 user research sessions a week. This provides more time to plan sessions and to recruit users. It makes it easier to schedule user research activities with teams and reduces the risk of making product decisions based on the feedback from just 1 or 2 users. Of course, user research can be carried out outside of these 1-2 day bursts, but only when it makes sense to do so. Rather than being a slave to continuous discovery teams should find a user research approach and cadence that works for them.
See also
Images
User interview photo by KOBU Agency on Unsplash
Recommend
-
6
Moving from Agile Teams towards an Agile Organization Dec 14, 2020 16...
-
4
Why I’m Not Speaking at PASS Summit and You Shouldn’t Either – The SQL HeraldSkip to content ...
-
5
The Focus of Every Agile Coach: Support How the Business Creates Value How should agile coaches work? I've heard several questions and problems around what agile coaches should and should not do. Should agile coaches f...
-
8
THIS WEEK'S SPONSOR: Concepts Sketch, Note, Draw
-
10
Five books every Agile leader should read before they start Agile transformation To continue my with my book recommendations (check Five bo...
-
4
SUNDAY REWIND: The world is colorful, so why shouldn’t our users be? BY
-
11
Essential Engineering Skills For Every Software Architect
-
9
How many ‘office days’ a week are enough? You shouldn’t need to ask Organizations are not made up of one type of person and one type of...
-
5
way0utwest 🎙️ (He/Him/His) on Twitter: "@jasonhorner Tell him every day without putting weights away is a day you shouldn't get a beer. That might induce compliance. Or indicate a weak will"Don’t miss what’s happeningPeople on Tw...
-
7
Speaking at Eleventy Meetup Next WeekRaymond CamdenDevRel at Adobe, Star Wars nerd, Web/Serverless hacker, lover of good beer and good books. Oh, and cats.
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK