How UX Fits Within a SAFe Environment
Universal Mind decided to make the investment in getting its entire UX staff trained and certified as Scaled Agilists. The intent was to not only bring the team up to speed on the framework but also better understand how user experience fits in.
“SAFe is purely development-focused.”
“We’ll still run our normal process, then feed SAFe.”
“I really don’t know how this is beneficial for UX.”
All of these statements were made by me after going through SAFe training with a room full of user experience (UX) architects and designers (aka UXers). Universal Mind decided to make the investment in getting its entire UX staff trained and certified as Scaled Agilists. The intent was to not only bring the team up to speed on the framework but also better understand how user experience fits in.
User experience is a big part of Universal Mind so if we’re going to utilize SAFe, we need to make sure UX is done right.
SAFe® (Scaled Agile Framework), for those who don’t know, 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.
The multiple teams include a Portfolio team managing the funnel of potential work, a Program team evaluating approved projects and multiple Feature teams actually producing the product. Each team includes some representation from UX, development, IT, and the business leads.
Within SAFe documentation, the role of UX is included but never clearly defined. This became obvious once the whole user experience team began to dissect SAFe through a UX lens. SAFe proposes significant changes in how we all work, and we discussed at length how this would play out in the real world.
Our discussions got us to a point where we were willing to give it a try, but in reality, the best way to learn is to dive right in. So we did, and we learned both why SAFe is better than traditional project approaches and what needs to happen in order to be successful.
I currently serve as the UX Architect for one of Universal Minds’ larger clients. Our team staffs eight UXers including myself, two UX information architects on the Program team, and five UX designers on individual Feature teams. Some Feature teams work exclusively on native iOS and Android while others work on Responsive web.
The team, including myself, was apprehensive about how user experience would be handled within the framework itself — as this represented a large shift from our current approach. Once put into action, however, our collective opinion shifted for the better. This isn’t to say everything went perfect from the start.
Before rolling out five Feature teams with this client, we validated the concept with a single Pilot team and captured learnings along the way. The Pilot team roll out went so well, we scaled to the current five teams — and are planning on rolling out more in the future.
Because of these learnings, Universal Mind can now confidently include UX as a crucial part of any SAFe implementation — something no one else does, much less even understands.
The basic structure of UX within the SAFe framework includes a UX Architect on the Portfolio team, Information Architects on the Program team, and one UX Designer on each Feature team. Each individual works with the entire UX team, but also across disciplines on their own respective team.
The apprehension comes in when SAFe framework describes design as a functioning cog within a team, delivering designs to developers in what’s essentially a “just-in-time” model. If you’re a designer and this is the first you’ve heard of SAFe, I understand that you probably felt cold sweats coming on just now. On paper, this is bad — pixel-pusher bad.
Take a deep breath and keep an open mind…
The reality is that SAFe takes all the same players and steps that we’re used to within a Waterfall design process and fixes everything that’s wrong with it.
Let’s compare a current Waterfall project with a SAFe implementation.
First, Waterfall…
Waterfall begins with an approved project. Most of the time, UX will take the provided project plan and dive in with research. They work simultaneously on benchmarking, building personas, and creating journey maps. That gets translated into wireframes, which are hopefully tested, iterated upon, and tested again. The designer finishes the project by compiling a deck of designs with annotations. At various checkpoints within that process development is consulted, but that is often the exception rather than the norm.
Done. Deliverables sent, paycheck cashed, who’s next?
Now, consider SAFe…
SAFe distributes the team, working with the client at multiple stages. Instead of starting with an approved project, the UX Architect (along with the Program team) is working to validate ideas that will turn into an actual project. Once approved, a project shifts to research, wireframe, and testing — further fleshing out the concept. This is where it gets really interesting, as the project is then “handed off” to a Feature team to actually build the thing. Working with developers, QA, the Product Owner and Scrum Master, the Designer completes the project visually and validates intent once produced.
After living this, there are three main reasons I’m sold on SAFe…
1. The visibility you get at the front end. No Designer likes to start a project with a document. I’ve personally been on projects that we get wrong because we don’t fully understand intent, goals, and success criteria. That cannot happen with SAFe. Gone are the days of loose definitions, poor communication, and lack of direction. If a project can’t be defined clearly, it won’t get green-lit.
2. The consistency you get across projects. We’ve all been on projects where we’ve done work with the client in the past or we’re working in tandem with another independent team for the same client. Waterfall runs teams of UXers as unique instances. SAFe runs teams of UXers as a single “Release Train.” No one is ever alone, and communication is baked in (so much that your Slack message count sets company records).
3. The validation at the end. When we’d finish a project in waterfall it was kind of like buying a pre-owned car off the internet. You hope everything goes well, but you won’t really know until it arrives. Annotations, design files, and as many examples as possible are all shipped to the developer. Within SAFe, every finished product is demoed to the team at designated checkpoints, before release.
SAFe gets UX involved sooner, keeps UX involved later, and ensures the entire team is delivering towards one main goal. Boom. On paper, SAFe improves much of how Designers currently work. It is important to know, however, that you’re in control of your own SAFe destiny.
Success within SAFe is all about collaboration, breaking down silos, and communication. That doesn’t just include IT, business and UX — that includes the UX team overall. Your team roster may show you as the only UXer, but you are never alone. All of UX, including the Portfolio, Program and each Feature team all work together to develop the product. In fact, Portfolio and Program team members should allocate 25–50% of their time towards working directly with the Feature team Designers. And, in the same way, the Feature team is responsible for peer review of other teams’ work, as well as understanding the projects seeking to be green-lit.
SAFe documentation calls the different teams “levels.” I suggest thinking of them as “stages.” It isn’t about who is in charge of who, rather who is responsible for what. The entire team is responsible for the end result, but each team is responsible for moving the needle further towards completion.
In order to successfully engage UX 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.
SAFe introduces a significant shift from waterfall but is being widely adopted because it works. It works for developers, for businesses, and can even work for UX.
During a two-day planning event I participated in, a developer stood up and said he had spent more time with the business and UX in the past two days than he had during his entire multi-year career at that company. Exactly zero people would ever say a two-day meeting was valuable unless it represented a giant change for the better in how they would be working from that moment on.
Months ago, sitting in training, we all wondered what SAFe had to do with UX. Universal Mind pushed all its UX staff in helping to define a solution for that question. After implementing and running since the beginning of 2016, we’ve come out with not only an understanding of SAFe but a respect for the process itself. When done correctly, SAFe can yield serious results, without sacrificing the UX.
