Why UX isn’t well integrated into SAFe
A few days ago I attended a talk on “Better integration of SAFe & UX”. In it, “proponent[s] and opponent[s] of SAFe”, Jeff Gothelf and Luke Hohmann were discussing aspects about SAFe, or more aptly: discussing aspects of “agile”.
We weren’t really touching on user experience in SAFe as I would have hoped, so I’d like to share my view as a basis for further discussion. It bases on almost four years of working in SAFe mode in Swisscom, where human-centered design had been an idea (and a division) for more than ten years.
Today, I have three problems with SAFe in UX:
Where’s UX in the chart?
I’ve made it a point previously to mention that SAFe cannot be spelled without customer or user experience. While that’s true in theory, in Swisscom’s approach UX wasn’t really visible or planned in the SAFe transformation. We hardly talked about the product, the solution, or the customer in the “leading SAFe” training I attended in 2017. Instead, we were focused on how to build & deliver software, and how to run the rituals that come with SAFe.
At that time — I think it was with SAFe 4.0 — even “Lean UX” hadn’t made its way into the SAFe diagram. To my knowledge, it was introduced with version 4.1, but at that time it seemed very much like a necessary and also half-butted addition. It filled an obvious gap, but it didn’t connect to the rest of SAFe at all. Yes, teams need to do Lean UX, but how they combine to provide a user-centered SAFe solution wasn’t part of the plan.
Natalie Warnert’s article on Lean UX and the life cycle shed some light on true integration. But the article lived disconnected from all other documentation and none of our trainers and transformation consultants knew about it after I had discovered it by accident. At least, it confirmed the way that we had chosen to make experience an important part of our work.
What roles advocate for UX?
Lean UX proposes that UX work is done by everybody and led by UX experts, with which I wholeheartedly agree. Our situation however was that UX work solely was (and is) being done by UX people in UX roles. And SAFe simply doesn’t have them.
Maybe the expectation here is that product management considers user experience an important part of the product. At Swisscom, we were discussing how to build software, and product management was busy managing stakes — so the experience aspect was often reduced to being the UX person’s work.
We’ve introduced UX architects early on to mitigate that. They were meant to discuss experience with product management and IT architects — but since their role is not on the official SAFe chart, their influence is lost. Again, Natalie’s approach to having a Lean UX Center of Excellence is a good one — but how does it connect to all the other SAFe rituals? What management will build a small team to do this, when it’s not foreseen on the chart?
Why an IT-only architectural runway?
SAFe’s architectural runway is a great idea. It ensures that things that might need testing, and maybe some planning have a way of being evaluated.
At Swisscom however, it is limited to IT architecture. If IT architects consider a topic too complex they’ll easily get an enabler feature and analyze it. If the same is requested for user discovery or testing … everyone just asks why UX cannot do that during the sprint.
Again, SAFe’s description of the runway doesn’t help the topic — no mention of UX being part of the runway. Same for tech debt vs. UX debt: the first is an accepted problem, the second doesn’t exist.
I’m aware that this article is quibbling without providing solutions. Still, I believe a good problem statement can be the root of a lively discussion … so please critique away!
If you’re also interested in the solutions we’ve devised for these problems (and where so far we failed), let me know in the comments.
