Matt Kortering of Universal Mind, wrote a blog post about How 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 any agile method or approach.
Here’s what Matt had to say towards the end of his post:
In order to successfully engage UX within SAFe, there are a few other things to remember…
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.
I want to touch on what I mean by a UX team, which applies to the team in my example below. The team often includes the following roles:
And follows the basics as outlined in this Brainstation article: http://blog.brainstation.io/intro-to-ux-design-the-basics/
Now let’s move on to my experience across several 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.
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.
I then pulled all of the UX folks entirely out of the Scrum teams and 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…
Finally, we created a more balanced approach that included both of the above approaches. We continued to have an independent 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.
Circling back to the article, my learnings align with theirs – independent of SAFe.
Read my next blog, Addendum – An Agile UX Story.
Stay agile my friends,
Bob.
Up Next: