How to integrate UX design into the Scaled Agile Framework (SAFe)

You might have heard about SAFe. Maybe others have told you it’s a scary and confusing diagram showing how corporations try to "do Agile". Or maybe you’ve experienced scrums where no one knows what’s really going on, what the product you’re all working on is really supposed be, or why you’re even doing it in the first place. You may even be worried to talk about it at all.

Don’t worry, Jennifer Fabrizi, UX Director of Strategy and River Brandon, XD Director and Design System Product Owner, from business insurance provider Travelers are here to tell you it really isn’t that scary or confusing.

What is SAFe?

This is the diagram of SAFe as featured on the Scaled Agile Framework homepage.

It can be a little intimidating when you first start dealing with SAFe. But in order to address that, let’s get back to basics and talk about what SAFe is and where it’s coming from.

SAFe has Lean, Agile and Lean UX approaches at its foundation .

Some of the core concepts here are of dedicated, accountable, cross-functional teams. A team should have all the skills and capacity it needs to accomplish the work, to achieve the mission that it’s been assigned.

We also work in cycles, we collaborate across functions, we’re iterative, and we respond to change. Hopefully these are all pretty familiar ideas if you know the Agile manifesto.

When we get into user experience design specifically, we’re user-centric, hypothesis-driven and focused on what’s measurable. We really need to look at outcomes.

And then finally, the work is continuous, it’s on-demand, and it’s value-oriented. On-demand means we want to always be ready to release things we’re making or create something that can serve the purpose of whatever we’re trying to learn at the given time.

These are the underpinnings of anything that’s Lean and Agile. We think it’s really important for all of us to have a good grasp on these things if we’re going to operate within SAFe, or any of the other approaches that are out there.

SAFe can be helpful because it provides a scaffolding and guidance around how to deal with particular concerns. This is useful when we’re managing across portfolios in organizations. If you don’t have the scale, you don’t need SAFe – you can just do good Agile and Lean approaches and be fine. But if you’re creating and sustaining large-scale platforms, if you’re building something that really has a diverse kind of ecosystem of users, producers, and consumers, then SAFe can be useful.

What we’ve learned about integrating XD and SAFe

We’re here to share some of our experiences, and our thinking. But it’s really to get the conversation going. We’re not trying to define the right way to do anything.

The focus is going to be on how you can use SAFe, and integrate user experience more effectively into your product teams, and the work that you do.

We want you to own the framework, we don’t want it to own you. Frameworks are not for controlling people, they’re for helping people. So we’re here to make sure that you get some tips on how to use SAFe to our advantages as UX practitioners.

There’s a myth around SAFe being good for design. It's more accurate to say that we make it good for design. So that’s the core message here. And in order to make it work for design, we need to have some understanding about what we’re dealing with.

Kill handoffs

When we’re doing Agile, we want to be able to deliver on-demand. But that’s a little different than design on-demand, where you’re expected to feel like a busy chef, taking an order and cranking something out very quickly, as if you have all of your ingredients ready to go, and you can slap it together real fast, and hand it over and then move on to the next order.

This chef’s skills are amazing, but they have everything chopped up and perfectly ready to go. And that’s rarely the case with the kind of design work we’re doing and the problems we’re solving. This is a holdover from our Waterfall days, and the problem comes when we’re transitioning to Agile approaches. What often happens is Waterfall is taken and squished down. It’s hard enough when we’re doing regular Waterfall to work in that manner, but then you squeeze those timelines down and expect everybody to do it faster over and over again, we don’t really get Agile, we get faster Waterfall.

And if you’re already constrained for capacity in terms of your design practice, this is only going to make the pain worse.

So how do we get out of this? Kill handoffs! Waterfall is defined by handoffs, and a lot of our concepts about how we work with different functions is all around making things and handing them off, as if we are in some kind of production line, where things go from one stage to the next. That’s not our reality. So we need to hang our hat on something within SAFe.

First, let’s talk about the triumvirate of product management, business technology and design. Scaled Agile doesn’t quite address the design part clearly enough, so we have to wedge ourselves in that triumvirate. These functions working together and using these different lenses on the problem space creates a very healthy tension. You’re essentially managing tradeoffs between the set of objectives you have, and what’s feasible, what’s desirable, and what’s valuable. Which leads to awesome results – we get a great solution for the customer, and the business drives value and we’re able to leverage the technology to its best effect without spending a billion dollars every time someone writes a line of code. That’s our zone of happiness!

The problem is in a lot of organizations where they have a lack of balance. So in the following example, where we have product management more closely aligned with IT as opposed to the user-centered design lens, we get an unhealthy tension. We can’t get great experiences if we’re operating in that mode. So if you find yourself in this state, the goal is bring the three lenses into closer alignment.

In order to do that, you need to get close to your product managers and product owners. Become besties with them, learn how to work arm in arm, help educate and bring user experience design knowledge to them so that they can begin to take a level of ownership. If they come from a project management background, then they’ll need some help understanding how the design practices go into creating the right solution.

In order to do that, we need to get more collaborative and more facilitative, and that means inviting everyone into the design process. So that means our design work must become the shared work of the team, which puts us in a facilitation and leadership position.

It’s a learning ecosystem not a feature factory

Often it can feel like we’re toiling in the feature factory. That is something we want to get away from. So going forward, let’s understand that work is social, and design can give the work of a product team meaning.

We need to shift the product team’s mental model from work being a feature factory to being more of a learning ecosystem that we share with one another.

SAFe has something called a continuous delivery pipeline. And what we love about the continuous delivery pipeline is that it’s continuous exploration, continuous integration, and continuous deployment.

What does that mean in terms of the learning experience? We have a hypothesis, we build something, we measure it, and we learn. So that’s our new mental model for how product teams should be collaborating.

What does it take for a designer to ensure comprehension on the team about what the user really needs, through empathy and how that’s reflected in your designs, and why you need certain design approaches? We can make work more human by injecting creativity.

SAFe addresses this in the Portfolio Kanban. The funnel is a place for ideas, and ideas can come from anywhere. So we start taking any ideas that anyone in the team has and include them in the funnel, so that they can be evaluated by the Portfolio leadership.

Design work is still work

In design we tend to cultivate this idea that we’re very special. But we want to demystify design and take out the magic, and help people understand that it’s work, just like the all other work that’s happening around us.

Our function as designers is to think about how we render the right things with the right intent, to create the opportunity for our users to have a good experience. But we need to elevate above this and think about the experience of design. So zoom out and think about how your stakeholders are experiencing design.

But how do you invite people into the process? How do you make it inclusive, so that they understand that what you’re doing is actually based on a set of practices, and it’s hard work to get to a good result?

SAFe DevOps has these core principles and it’s about creating a culture–not just a set of workflows. The culture of shared responsibility means we think the user’s actual experience is a result of this thing we made together. I’ve never made anything with a larger team where I was the only one responsible for the user experience. The developers made key choices, the business folks made key choices, everybody contributed to the end result.

So design work is work, and if we’re going to be Lean, that means we don’t do unnecessary work, we don’t create things that are wasted energy or unneeded inventory.

We’re talking about taking design seriously. It’s work, it’s a job, it’s a practice that fits in with all the other kinds of work that we need to do. A lot of large organizations are relatively immature in this area, so we have to be the advocates for what it means to do design work.

We have to understand how the business drives value and what we can offer to improve the ability of the business to get value. And ultimately, we should know that happy users mean better, more successful businesses.

It’s really about not thinking that we’re doing something separate, but we’re doing something together to render the ultimate end result of the product and services we want to create.

In summary

Embrace faith, but don’t drink the Kool-Aid. Use your critical thinking to understand what some of the flaws are with SAFe, and where those show up and how you can talk to your product team about integrating UX for a better outcome.

Own the framework, because if you don’t learn it and understand how to take advantage of it, the framework will own you.