Break Down Silos! How to Enhance User-Centricity on Scrum Teams

Gary Pedretti, Professional Scrum Trainer,

I often see User Experience (UX) Designers struggle to align focus, work, and approach with Scrum Teams building increments of product in iterations of 30 days or fewer. Common concerns and questions I hear include:

• “Developers aren’t really interested in the user, they just want to build.”
• “I’m trying to work side-by-side with the team, but I’m always a bit ahead of them, so what should we talk about in our Daily Scrum?”
• “I don’t work in sort cycles, or tactically. My work is strategic.”
• “Why don’t developers use my design artifacts and decisions? Why do they never go back and refactor for good design? Why do I feel like I never have any influence?!?!”

These challenges often result in tenuous relationships between UX Designers (UXDs) and Scrum Teams — or even worse, distrust, separation, and “staggered Sprints” (where completely separate teams pass work to each other that they execute in completely separate blocks of time, which they still call “Sprints” — even though those blocks of time function exactly the same as waterfall phases).

UX and Scrum: Better Together

But UX Designers don’t have to work in silos, away from Scrum Teams. They can be stewards of design processes, user-centricity, and hypothesis-driven development across teams. In fact, we can borrow from our experience in integrating other specialities into the Scrum Team — testers, data analysts, and application architects — to provide some initial ideas to try when doing the same with UXDs. I focus on the example of application architects for this post, but realize the attitudes and patterns are very similar in regards to team integration for other skill sets and specialties I mentioned. Early on, I heard things like this from architects:

• “Developers often aren’t interested in good architecture. They just want to crank out features.”
• “I need to work ahead of them, prior to feature integration, so I don’t belong on the team.”
• “My work is strategic.”
• “Developers just need to do what I tell them to do. And yet, they usually don’t…”

Sound familiar? 🙂 Notice the extensive use of “they/their/them” and “I/my” — just as the list above talking about UX challenges.

What happened over time is architects realized all of these challenges are interrelated, and need to be addressed holistically, from within the team. Architects turned from order givers to collaborators, building consensus and instilling a sense of “why” behind their decisions across the entire team. That is, developers are less likely to be interested in good architecture when you’re working ahead of them, denigrating their work as “tactical,” and not working with them outside of showing up to deliver orders. Or, more importantly, you will get a well-architected application when developers understand the “why” behind good architectural decisions, when architects embed themselves on teams (if only as part-time members), and when architects change their stance from commanders to stewards and mentors of good architecture. It is ultimately a mindset shift towards collaboration and common goals.

Simple but effective things architects did (that UX Designers could also do) to precipitate and demonstrate this mindset shift included:

• Sitting down with coders to harvest existing, established code and conventions into reusable components and principles
• Bringing awareness back to higher level concerns — architecture, product vision, user needs — when people get innocently lost in the details
• “Lunch and Learns” that focused on “whys” and gathering feedback, as opposed to “I’m going to lecture about something…”
• Sharing work and artifacts early and often, as opposed to holding work before delivering it in a “big bang” fashion

In the new by Scrum.org, we talk about this mindset shift and actionable tactics to achieve it over two immersive, experiential days of learning. The PSU training course teaches students how to successfully use UX techniques and Scrum together, giving students the opportunity to practice these techniques with cross-functional teams throughout the class.

UX and Scrum: More to Come!

As a person interested in “individuals and interactions over process and tools,” I wanted to start this UX and Scrum conversation with the human aspects of bringing design and development closer together. Future posts in this series will discuss more human-centric ideas, such as user-centricity, but also process and artifact suggestions to achieve the same goal discussed here: bringing design and development closer together to acknowledge common goals.

For example — regarding process, how could UX designers actually structure work — i.e., how could it fit into Sprint cadences of one month or less? Regarding artifacts, how could common design system artifacts, such as style guides, not only be built out incrementally, but inform the actual work as soon as possible?

We will look at those questions in future blog posts about UX and Scrum together — stay tuned!

Resources

Originally published at .