As a person who used to work in UI/UX (before being a tech PM and also before Agile was a thing), it’s always interesting to me to tackle this question.
First problem, does a company need the discipline of UX design enough to invest in specialized experts in this field? Many companies don’t do this (they probably should), and this is a non-agile bigger problem. You’ve already crossed this line, but I wanted to call it out as many readers of this thread won’t be that fortunate.
So, you work in a company that believes in this (yay!), but can only hire one person across several scrum teams… now you have a non-dedicated resource pulled in many directions and they HATE agile as they can’t round-robin fast enough. In this scenario, I’ve seen one of two things work:
- Have that individual work in “review” mode and basically work as an expert that floats and trains the teams to become better at the discipline themselves. The team owns the work, the expert is a coach, not a do-er.
- Prioritize the biggest issues/problems and have that person work a “UX backlog” in front of the sprints and do the best they can knowing they are solving the biggest problems first. Also, give them budget/customer-access to do user testing to validate that the priorities they are focusing on, are actually the best to prioritize.
At some point, the company makes money and grows… or has an “oh shit” moment about how important this role is… at that point maybe you can get more bodies into the discipline. As much as I’d like to see a dedicated UX person on each team, this isn’t any more likely than seeing this with scrum masters. So, in these scaled environments, I’ve seen a mostly successful balance where SM’s and UX folks are both “matrixed” across two teams (no more than 2!!!). The UX folks will work ahead of the sprints, and I treat them as a BA (business analyst/product analyst) role that extends the role of the technical PO. Basically the PO writes the basic story and then the UX person takes ownership of that and flushes out the wireframes and acceptance criteria (while validating with dev’s along the way). This becomes an integral part of the backlog grooming/estimation process. Some might say this isn’t “agile”, but I simply argue that it’s not pure Scrum. If a little waterfall in front of 2 sprints makes those sprints go better, then we are doing the right thing.
The other important effort I’ve found is making sure that a “community of practice” forms across the UX team across agile teams. You don’t want each team to solve similar problems with different patterns, because then your customers get lost. My current company has a common pattern library and style guide that is mentored by the UX team across the global company (even though product interfaces vary considerably) and the front end dev’s are well-engaged in understanding and responding to it (part of our Done criteria includes a “visual QA” review with Dev:UX on all stories before closure).
On a side note… “community of practices” are just as important for all “practices” and we set and work similarly for DevOps, Performance Testing, Penetration Testing, etc, etc, etc. (Big company, wicked problems!)
I hope this helps and I’m very curious for other approaches/patterns (successful or failed) people have seen in other companies as it’s a problem still being explored!