How to Collaborate with UX and CX
Should UX and CX really be *on* the agile team?
For quite a while, I and other coaches I know have been saying “The ideal agile team has ALL of the skills ON the team.” Because that’s how we achieve some level of autonomy and can deliver value consistently without constraints or dependencies. Now, I know most organizations have complex systems and infrastructure, component, and shared services teams that provide support with things like UX, CX, DevOps, Security, and Production Deployment. So there’s always some sort of caveat I suppose. Something I should probably consider more often myself. But it begs the question, “What’s the best way to collaborate with these shared services teams?”
I’d like to focus on the User Experience (UX) and Customer Experience (CX) teams because I feel the work, demands and constraints are perhaps more obvious when it comes to security, DevOps, and production deployments. Teams should involve co-dependent teams in advance and communicate frequently as needed or in a specific cadence to collaborate well with those teams.
My experience with UX team members is that there is a need for an intimate relationship with the agile delivery team, however it is different than the average team member. In general, the UX team members tend to do two different types of work (whether off-team and centralized or on-team doesn’t matter). The first is the in-advance designs, research, and visuals required for future sprints and expected upcoming work. The second is in support of the active work of the agile delivery team, should they be incorporating previously designed work that is now being integrated and delivered into the product.
So, while the Agile Delivery Team is focused almost entirely on the current sprint (with only some of their time focused on planning for future sprints), the UX team does almost the opposite; focusing most of their active work on future sprints and only as needed to support the current sprint. If you think of your team members (or co-dependent teams) in this way, you might be smarter about just how integrated and “on-team” you expect them to be. Does a UX team member need to be at every agile event or ceremony? What cadence makes sense? Are they only available on demand and yet agree to be responsive for any questions? Consider incorporating UX specific items into your working agreement and adjust them as you collectively decide you need to.
There’s a parallel here for the role of the on-team Product Owner as well, since much of their time is likely focused on the next sprint, prioritizing future work, or starting conversations with stakeholders that will impact future work. And yet, a PO needs to be available to help the team anytime they have questions. The PO is perhaps more critical and should continue to be at all of the team’s agile events, because they can likely provide relevant input into any of the current work items.
Customer Experience teams, in my view, should have a very similar relationship to the agile delivery team(s) as the UX folks do. But first, if you don’t have CX teams, a quick description of what I mean. CX is the overarching, strategic, customer journey work. Larger companies with multiple customer touch points and multiple products and experiences need to consider the end-to-end impact of all of the customer experiences they provide to their customers. CX answers questions like “Do we provide consistent level of quality and resolution to similar problems with our in-person or in-store solutions as we do over the web or in our call center?” The Customer Experience and Journey related work tends to span multiple departments or divisions of a company and can be very complex work, often dealing with longterm strategic shifts in the way a company wants to conduct business in the future, for example. That said, these longterm strategic elements still need to embrace an iterative mindset and should be experimental in nature, to be sure we are solving problems in a way that is impactful to customers.
So, the CX teams and their journey work should have a similar relationship to the agile delivery teams as the UX teams do. Only, the CX timelines are longer, require more research, analysis, experimentation, and design thinking to be effective, so instead of looking ahead one sprint or two like UX work, the CX teams should instead align to Product Increments or a quarterly cycle. What else comes to mind when you think about strategy, alignment, and quarterly cycles? OKRs! I don’t know if this idea is already well-known yet, but as my teams and I have started discussing this concept lately it was like a huge lightbulb lit up and connected a lot of dots for us. Some teams of teams struggle to “make room” for longterm journey work because they’re so busy working on big technology shifts or just in the daily struggle of feature factory chaos, keeping up with a lot of requests from customers and stakeholders.
But if your company wants to make a deliberate plan to create a meaningful strategy, it should include a portfolio of priorities that balance the priorities of innovation and new features vs. maintenance vs. planning for the future. And, instead of looking to the senior executives to define that strategy for you, create a framework that allows the right people to help influence the strategy to suit the fluctuations that ebb and flow in your company. My thoughts on how to create this framework are simple. Use the Objectives and Key Results system in a way to forces you and your team to consider what portion of a given quarter’s goals will be innovation, maintenance, or future focused. Keep a small number of Objectives, usually three to five. How many of those are going to advance each of those three strategies? And if, for a quarter, you need to not do one or do a lot more of another, you can. But the point is it forces the conversation to happen.
If used well, the OKR strategy is the marriage of the company vision and the opinions of your key executives to the teams of teams where the work gets done. And, like a good marriage, it allows the space for one to change without forcing the other. Strategy, business focus, and OKRs can change, but the teams of teams still operate the same way. After the strategic OKRs are set for a team of teams, for example, the team(s) who have the skills to solve the problems presented by an OKR figure out how to absorb that work, craft their own OKR statements to define their portion of the work, the epics and stories to deliver it.
I like to think of OKRs as the big buttons, dials, and levers that an executive or senior leadership team has to set the direction and strategy. In this way, the senior leaders can remain at a level where they are most effective, weighing the impact of one strategy vs another, and frankly also steer clear of getting into the weeds of implementation details where they often break psychological safety and cause harm to the teams. That said, it also goes both ways. If a technology delivery team is aware of some critical need to change direction (i.e. build architectural runway, fix security holes, upcoming regulatory violations, huge technical debt slowing development, etc.) they should surface these needs to the leadership in charge of determining the right balance of the OKRs to set the right direction and focus for the teams.
Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the practices and frameworks of the agile universe into easy to understand and simple common sense. I offer fractional agile coaching services to help teams improve affordably. See more at FractionalAgileCoach.com
How well is your team “being agile”? Our self-assessment tool focuses on 24 topics of modern ways of working including the Agile Manifesto and Modern Agile basics, XP, Design Thinking, Lean, DevOps, and Systems Thinking. It comes with deep links into the Practical Agilist Guidebook to aid continuous improvement in teams of any kind. Learn more at MakeTeamsAwesome.com
The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an agile coach showing you why the topic is important, what you can start doing about it, scrum master tips, AI prompts to dig deeper, and tons of third party references describing similar perspectives. Learn more at PracticalAgilistGuidebook.com
Follow me here on Medium, subscribe, or find me on LinkedIn, or Twitter.
