Should UX be part of the Scrum Team?
“We are still recruiting a UX for your domain.” That was a scary sentence when joining a new team. It implied that there was a need, hence a gap in skills either needed now or tomorrow and that the solution centered around a person.
At the same time, it is not a unique situation. Many teams ask themselves does Architecture need to be part of the team? does a DBA need to be on the team? what about a Business Analyst? or a Data Scientist? At a time and age where specialisms become more and more important, how do we marry the concept of skill excellence to the full-stack team?
Ringelmann’s Rope Pulling Experiment
You may have heard of the Ringelmann effect. The idea behind this research is that once you add enough people to a team, the effectiveness goes down. Some numbers suggest that if you need 8 people for a task, you get about 50% efficiency, compared to a team of 1 (hmm, is that a team?)
The main reasons for that are: (1) loss of motivation “surely someone will do this….” and (2) loss of coordination “I was waiting for…”
So huge teams of specialists are not what we want, yet we also need individual expertise that may not exist in all team members. This is why many organizations struggle to hire enough specialists, but there is a hidden problem with that.
Yes we do Scrum and…
Gunther Verheyen pioneered the concept of Scrum, yes and.. and it feels a very natural fit to the problem that one of the founders of Scrum explained in his letter “Scrum is hard and disruptive.” Because it is hard, it means that it will be a struggle to get there, it requires inspection and adaption and the route might be more important than the end state.
Embedding UX into Scrum means you can do expect more benefits, the tighter UX is integrated into your development process. But what does that look like?
If you are not doing UX, but building products it will be very hard to deliver value to end-users and we will refer to this as the “dark ages” of product development. I’m not even including it on the chart, because of that.
More commonly we see UX being done outside the Scrum team. Sometimes by design agencies, sometimes by a UX squad or something similar. UX is seen as something a particular person does. It is a specialist role, and often they are very good at it. Of course, it is an upfront design, so when the rubber meets the road it feeds the family feud between UX specialists and Developers that have “an opinion” about each other.
In other organizations we see a UX specialist juggling multiple teams. This tends to improve the relationship between the people though it can be quite a strain on the UX specialist, who now finds him/herself in multiple Daily Scrums, Sprint Plannings, Retrospectives, etc. On top of that, they have to juggle their time and work between different teams, often needing to context switch. Not infrequently they end up having their own “UX backlog” with items that refer to items in the “real” Product Backlog. Scrum feels like a restraining harness and at the same time, the Developers wonder why they are delayed by UX.
A bold move is to move the UX specialist on the team. He or she is still seen as “the expert” and hence needs to do all the UX work. Often the UX pain is similar to the QA pain. Where the QA gets a ton of PBI to test and approve by the end of the Sprint, UX is chased at the beginning of it “so we have all specifications.” Even in the team, the UX specialist finds him/herself often working “a Sprint ahead” leading to confusion and waste when new insights emerge.
Move from UX as a person to UX as a skill
(Thanks to @garrypedretti for this insight) The magic happens when we move from seeing UX as a person to UX as a skill. It doesn’t the skills of each Developer now equal the skills of a UX specialist or vice versa, but there starts to develop some overlap.
Typically this is done by the UX specialist actively mentoring the other Developers on UX principles. You can start small. On one of my teams, a Developer was blocked because she didn’t have a favicon of our logo. The initial response was: “I’m blocked, let me code something else” but with some help, she managed to unblock herself and deliver value. Start small and grow.
UX work becomes a skill that can be collaborated on during the sprint by the Developers, now including the UX specialist. Think of some typical UX activities:
- User research
- Persona development
- Information architecture
- Wireframing
- Prototyping
- User testing
- Business Problem Statements
- Writing hypothesis
- Designing experiments
- Usabilty testing
Now think of your team, where could they help? Perhaps the UX specialist is more skilled in say, conducting user interviews, but how can we infuse the team with UX? how can skills and work be shared accross the different members of the team?
Ultimately..
UX is part of each PBI, just like testing is, and architecture, etc etc. It is not something that is done upfront by a seperate team. What if it becomes impossible to destinguish betwween design and delivery? What if the blurry boundary beween discovering what the customer needs and delivering solutions to their problems are so intertwined that we no longer focus on what seperates us, but on what unifies us.
A streched goal, sure. Scrum was meant to be simple, not easy ;-) we are all just trying to figure out what works for us.
