The Top 5 Blockers to Building a Robust UX Culture: Part 3
Keeping UX Separate From Agile Transformation
Keeping UX Separate From Agile Transformation
This post is part 3 of a 6-part series on Blockers to Building a Robust UX Culture.
You can find part 1 here.
You can find part 2 here.
The Top 5 Blockers to Building a Robust UX Culture
- Placing UX culture in traditional organizational hierarchies.
- Keeping UX separate from Agile transformation.
- Allowing silos between UX and Engineering to form and become embedded.
- Hiring the Wrong People.
- Not integrating UX with a strong Product IT Culture.
The collision of UX culture with Agile transformation is a well-documented phenomenon, and the reasons are legion.
It gets even more complicated.
Approaches like “Agile UX” and “Lean UX” are similar enough to make people believe they understand each when they do not. Consequently, when they start working together, these differences in approach emerge as seemingly unresolvable interpersonal conflicts. (Conflicts on product teams are almost always not about individual people but process and policy. Sadly, it usually gets framed as personality issues, a waste of talent and experience.)
Agile, UX, and “Design Thinking” emerged and developed along parallel tracks and share a lot of similarities, which can trick people into thinking they understand each other when they actually don’t. Further, Design Thinking and UX were both at genesis driven and developed by engineers and PhDs. Bob Sutton’s piece, written in 2010, still does a great job of detailing the all-but-forgotten origins of UX and D-Thinking in Engineering. When added to the impact of McKinsey’s The Business Value of Design in 2018, being “design” driven can sometimes mean that design and UX are centralized and operated discretely from engineering. In competitive environments, they can even become opponents to each other.
Human nature exaggerates these divisions. Building a culture that grows cross-functionality and interdisciplinarity is difficult. Silos are much easier on the ego. In a silo (or, in some cases, a fiefdom), it feels easier to think that you are with “your people” who understand “what you do” and where your authority remains unchallenged. And you don’t have to adjust your ways of working because you all work in kind of a similar way.
Building silos or fiefdoms within organizations is typical clannish behavior. (Think Harry Potter’s Platonic universe with “Eng,” or “Dev,” and UX instead of Hufflepuff and Gryffindor.) Our natural clannish instincts make some designers long for a consolidated “design-driven” culture that feels lost when an org embeds UX-ers within Agile teams where the designer-to-engineer ratio makes them a minority voice.
The other problem is that many people managing UX aren’t actually UX trained. They are trained in marketing and graphic design, or sometimes in wholly unrelated fields, which makes them a little uneasy in tech-driven spaces. Consequently, there is frequently a lack of understanding between Engineering cultures and UX cultures. Since Agile was developed for and by Engineers, sometimes UXers who have now evolved from multiple other non-technical fields can feel marginalized.
On the other hand, UX can seem time-consuming for engineers who are used to having work measured, tracked, and evaluated. Its outcomes can seem infeasible and lack understanding of the technology that animates the proposed solutions. UX Designers prioritize according to perceived or observed “user needs,” and Engineers prioritize according to capabilities, capacity, and velocity.
The end result is that it seems more comfortable and easier for everyone to keep UX and Agile scrums separate. However, this keeps everyone miserable. Silos force a Waterfall mentality into the Agile process. UX completes processes and hands them off to Scrum teams to be sliced and diced, slowing velocity. Outcomes frequently look like this:
There are about as many ways to solve this problem as there are product teams worldwide. The point is silos aren’t a solution; they are a default human nature state.
Nor is this about being capabilities aligned vs. product aligned. You can have a product-aligned organization with silos and a capabilities-aligned team with a cross-functional approach. What matters is that there is an intentional strategy and policy for bringing greater cross-functionality.
Mindset shift:
UX can be Agile, and Agile can be user-centric. How that looks in your organization will depend upon your human partners. Make your Agile processes and communications plan suit your people’s work and maximize your team’s strengths.
Change your beliefs about the relationship between Agile and UX from something fixed: “Agile and UX don’t work well together.” To a growth Mindset. “UX and Agile have similar goals and work well together with communication and collaboration.”