A Guide to Feature Team UX Runway within SAFe
To start, thank you to everyone who reached out via Twitter (@mkortering) or email (firstname.lastname@example.org) regarding my recent article on UX within SAFe. Overwhelmingly, the topic that people were most curious about was the UX (User Experience) Runway, specifically at the feature team level. Often, comments that were shared circled around wanting to avoid “Just in time designs”, which sacrificed consistent design across teams, and left no time for iteration - frustrating designers. The goal here is to help define the key to UX working within SAFe at the feature level - the UX Runway.
For a refresher: SAFe® (Scaled Agile Framework), is an adaptable framework of proven success patterns for implementing Lean-Agile software and systems development at scale. Created in 2011 by Scaled Agile Inc., it has quickly become the framework of choice to replace the traditional waterfall approach. It is designed to break silos, empower individuals, and release software at a repeatable rapid pace; this scales to multiple teams running concurrently.
At Universal Mind, we recognize our own reality: we are an agency and many of our clients are using or moving towards a SAFe framework. If we want to continue to support our existing clients and build relationships with new ones, we need to adapt. However, we also recognize that we have been successful because of who we are and how we operate. There’s a balance between new ways of thinking and maintaining our culture.
That said, within Universal Mind, the UX practice has one goal: regardless of how, where, when, and with whom we work, we never sacrifice good UX…ever.
UX is really a combination of art and science that requires research and constant iteration. Building lovable experiences means we need to understand what people want, not just what can be shipped. This process takes time to deliver the best solution and is contradictory, on paper, to SAFe. But, taking a deeper dive within SAFe highlights that this approach not only fits within the framework, it is necessary for long term success of the program.
At the end of the day, SAFe exists to deliver value. Forced, bad UX isn’t valuable. Thus, the goal of SAFe is to not deliver a bad experience, as there’s no value in bad UX. The trick is baking UX practices into the framework at the right time and with the right people. A key to that, for Universal Mind, has been the creation and existence of a UX runway — a “head start” for the designer.
We set up our feature team UX Runway as a full 2-week sprint. This means the designer on the feature team is working on designs “due” at least two weeks out (the next sprint). The goal is to eliminate the idea of a “just in time” designer. Inherently, this provides the designer time to iterate, get feedback (from the people building the feature on the same team), and develop final comps without feeling too much time pressure and instead focusing on delivering good UX. In order to set this up effectively, there are three things that need to happen:
- Team Buy-In Giving some people on a team two weeks to work on something when others don’t have that time can be a tough sell. Developers, Business Analysts, Product Owners and anyone else on a feature team all have to understand and respect the UX process. This isn’t to say that other members of the team can’t or shouldn’t have the same affordances — that’s up to each individual team. My point is for the UX designer, working without a runway shouldn’t be an option, and the rest of the team needs to appreciate and understand why. Often, the best way to get buy-in is put it in action. The UX runway is beneficial for everyone as Product Owners can shop ideas around, Developers can provide feedback, and Business Analysts can ensure requirements are met. Value from the runway becomes obvious very quickly - something we experienced days after initially setting this up.
- Program Team Efficiency In order for a feature team designer PI to start with a full sprint head lead, the program team, including the Business, Technical Architects, and UX, needs to make sure the feature teams have everything they need. This is a full team effort — the A/C needs to be fully documented and low-fidelity wireframes are needed to articulate the decided direction. One difficult thing here is the balance between feature team independence and wireframe direction. It can be tough to build wireframes that provide direction and goals, while ensuring they’re not so polished that design work turns into a “paint by number” process. (We’ll be uncovering that balance in another forthcoming article.) Additionally, it is important for the Program Team to push towards defining MVP (Minimum Viable Product) to also include a UX component. The acceptance criteria for any MVP must account for how the user will interact with the product, not just the minimum feature list. This includes identifying components for post-MVP work - answering, “what else needs to be accounted for in the long-term?”
- Good people This is as cliche as it gets, but the reality is, you have to have great people to pull this off. You have to have feature teams and program teams that work together to set this up — especially because the program team may often be tapped to help with things during the first sprint. But the real key is good people at the feature team level that respect their craft, the client and the user. This isn’t production design, but it is easy to think that way. The reason we created the UX Runway was to avoid that. The integrity and the use of the runway is up to the individual contributor. It requires discipline to work on things that aren’t “needed” right now. The designer also must be available for any help the team may need on what is being built in the current sprint, so there’s a time management factor that is crucial to success. Without good people, the runway could be viewed as a waste or a distraction, of which it is neither.
Once you have a UX Runway set up, the next question is really how you use it. This is the part that I get really excited about. If you’re going to say that you want to give your feature team independence, then you have to walk the walk. Let them use it how they want to. I’ve seen it used by our team in a few different ways:
- Traditional Design Work The most common usage is to simply get ahead in design work for the next sprint. This may mean doing some iterations, getting feedback from the Product Owner or Developers on the team, and updating based on responses. Designers often have time to work on error states, layout changes, break points, or anything else that would otherwise be left for the developer to guess at.
- Building Prototypes One thing that our designers started doing was building prototypes. Why? Because prototypes are tangible — and our designers wanted to spend some time thinking through interactions. Prototypes are wonderful ways of displaying interactions to the rest of the team. Prototypes help communicate motion, flow, and convey the goals of the designer. They also help explain intent when the designer isn’t around — like when a design is being shopped around within the business. Our team has been using Flinto and Principle primarily, but we’ve also had good results with Proto.io and InVision.
- Design Spike This is something we coined to represent doing additional design work at the feature team level. It is comparable to other Spikes, but more design focused. The basic idea is that at sprint planning, a designer is looking ahead to the following sprint and realizes a feature in the backlog could benefit from some additional design thinking in order to better explore all the options. This may be because the wires aren’t relevant based on new acceptance criteria, or the designer may have a different idea worth looking into. The best part of this Spike is that we introduce User Testing into the feature team. Many SAFe implementations set up user testing exclusively at the program team, but that seperates the actual designer from the user - something that reduces empathy and builds a disconnect within user-centered design practices.
The Feature Team Designer’s Design Spike sprint then looks like this:
Week 1: Iterate with the Program team (along with other team members or teams - see tip below) to identify the “options” that could be implemented for a single feature (ideally 2–3). Build one or more prototypes to adequately test the feature/design.
Week 2: User test the feature in whichever way best suits accurate feedback. User testing is lead by entire program team and includes the feature team designer(s). The Feature team designer(s) then compiles the research and presents the findings and direction at the sprint demo.
An important tip is to make sure communication lines are open between teams, so if one designer wants to user test a feature, any designer who may be impacted by the outcome is both aware and involved, if necessary. User testing, like anything within SAFe, should not be done in a silo. Any testing should include an open invite to anyone on that feature team, or other teams if applicable, to ensure all team members are user-focused.
The first time we did a Design Spike, we literally did user testing in a cafeteria at lunch because the time to set up testing was prohibiting us from actually getting it done. Starting this month, we will have access to recurring testing sessions, during the second weeks of sprints, that will allow us to plan accordingly. If there are no Design Spikes identified for that sprint by any feature team, the program team can use the session for something they are working on.
A good program team will never turn down scheduled user testing.
I was at a conference recently and the majority of people I talked to about SAFe said they don’t include UX at the feature team level due to a lack of knowing how to execute timely UX activities within an existing framework. To that I’d respond that if UX is crucial to the success of your product—which is a rhetorical question since UX is always crucial—you can find a way.
UX within SAFe at the feature team really shouldn’t be optional. For it to work, however, the UX Runway must not only exist, but must be understood, protected, and used appropriately. At the core, you need to have a team of people who are passionate about the users they’re building for. That’s how you’ll deliver value.
Digging into the general consensus about UX within SAFe yields a lot of confusion. This confusion, I’ve learned, leads to pulling UX from the feature teams - forcing the Program team to be responsible for all designs - beginning to end - with no feedback provided by the teams actually building the feature. If you get anything from this article, know that UX isn’t something that needs to be shoehorned into SAFe, but something that actually seems tailor fit for it.
Need help? Let us know, let me know. We’d love to work with you.