Matt Kortering of Universal Mind, wrote a blog post aboutHow UX Fits Within a SAFe Environment. Lately I’ve been thinking about and writing about the scaling models, so a part of this fits well with current themes.
But I don’t want you to get stuck on the SAFe bits here. I truly want this to be a generic blog post about handling UX concerns and x-team integration within anyagilemethod or approach.
Here’s what Matt had to say towards the end of his post:
In order to successfully engageUX within SAFe, there are a few other things to remember…
Give the Designer some runway. I’ve never met a designer whose approach is to quickly design something once and walk away satisfied. Designers iterate, period. If you force a designer into a “just-in-time” delivery model, the designer and the work will suffer. In order to do this, the Program team must help the Feature team designer hit the ground running at the beginning of Sprint 1. This often means some designs are done, and clear direction is given. Also, when measuring velocity, don’t include UX in the point calculation. They should be working ahead on deliverables for Sprint 2 during Sprint 1. Trust me, this is huge.
Don’t build a team silo. No one should be acting within SAFe alone. Communication is built into SAFe for a reason. Communication must happen in all directions — across Feature team designers, upstream between Feature, Program, and Portfolio teams, and within each team itself. It is easy for UX to silo itself since that’s been the typical approach, but a huge benefit of SAFe is the ability for all disciplines to work together in real time. Also, look for ways to improve. SAFe is built around responding to issues, don’t be afraid to bring them up in order to keep your train moving.
Listen to the other members of the team. In waterfall, UX would hand off work and hope it gets delivered as designed. Developers hated this because they were regulated to accept work, sometimes incomplete, and do their best to interpret. Trust your team, seek their advice, listen to what they have to say. This is a big shift for developers as well, representing a giant leap to get their ideas included in designs. Listen to them.
From my perspective, this is sound advice whether you’re focusing UX efforts in SAFe or simply other agile approaches.
I want to share my own hard-earned lessons as it relates to integrating UX teams.
But First
I want to touch on what I mean by aUX team, which applies to the team in my example below. The team often includes the following roles:
Now let’s move on to my experience across several approaches.
Three Approaches
A few years ago I joined an organization that had made a serious investment in Scrum and another investment in creating a UX group. I joined as a senior development leader and the UX team reported to me.
Since you know I’m a “Scrum guy,” one of my first actions was to try to figure out how UX fit within the Scrum team structure.
Embedded within the Teams
My initial knee-jerk reaction was to assign UX team members across all of the Scrum teams. Essentially they became part of the team. Even folks who were more forward-looking and doing customer surveys and research.
Over time, we found this didn’t work out well. Sure, these folks were solid team members and they contributed to sprint goals and work. However, they lost their functional ground, their focus on UX look-ahead, if you will, in lieu of delivering team work. In a word, they simply didn’t have the time to do enough forward-looking work, which is the ESSENCE of UX.
So I knee-jerked again.
Divorced from the Teams
I then pulled all of the UX folks entirely out of theScrum teamsand formed them into an independent team. This solved the above problem, in they had plenty of time to work on their own initiatives, designs, research, etc.
They even operated as a Scrum team, so the dynamics matched those of the development-centric Scrum teams.
But over time we found that the UX team was too abstracted from the work the teams were doing. For example, a UX design would often enter a team too late. They had not seen it as part of the Backlog Refinement process and they were surprised. More importantly, the designs often weren’t feasible from a development effort perspective so we had to rework things.
A more thoughtful reset…
A Hybrid: Balanced across the Teams
Finally, we created a more balanced approach that included both of the above approaches. We continued to have anindependent UX team. However, we asked team members to work within the Scrum teams as they explored their design ideas.
More importantly, if a design needed to be instantiated in the product, the designer would join the Scrum team(s) as a part-time team member to help with the implementation. It was this oscillation by UX designers between their functional home (for design look ahead) and team engagement (for design implementation) that simply drove the best results.
I lean toward this balanced approach when I’m personally leading an organization and I recommend it in my coaching.
Sometimes folks ask me if there is a prescriptive model to how to balance? I tell them no. It’s up to the UX team members and the Scrum teams to sort out the most effective balancing dynamics per team and per product.
Wrapping Up
Circling back to the article, my learnings align with theirs – independent of SAFe.
Give the designer some runway– I achieve this by fostering a sense of community, guild, and functional grouping within the UX team. This includes forming a Scrum team and the associated dynamics.
Don’t build a team silo– while I certainly want to honor the notion of UX as a discipline, we need to collaborate across teams. That means the rubber meets the road by UX folks joining Scrum team(s) to get things done.
Listen to the other members of the team– a great part of the agile dynamic is transparent collaboration. One of the things that UX teams can do is listen to, then mentor and coach the teams in UX best practices. This includes listening to the stakeholders & customers via the Scrum team ceremonies.
