Thrive as a Designer in SAFe

The Growth of Enterprise UX Design

If you’re a product designer building experiences at an enterprise software company, congratulations. You’re likely tackling some of the hardest (and often most impactful) software challenges affecting our governments, corporations, nonprofits, and more. Your work may not always make flashy headlines in the news, but nowadays we can’t work, learn, or travel without relying on critical enterprise software services. At Pivotal Labs, we help leading enterprise companies create not only great software but also the well-balanced teams capable of effectively collaborating across disciplines and departments to create great technology.

Here Comes SAFe

With all the security and human complexities that come with making enterprise-grade software, you might not feel like you need any more hurdles thrown your way—what you have on your plate is more than sufficient. Then one day your product director informs you and your team that you’re about to start working in a new way called “SAFe,” and you realize all your carefully crafted workflows are about to be completely upended.

Building Design Practices From Within

The Scaled Agile Framework (SAFe) intends to help organizations “scale lean and agile practices” through a set of workflows and protocols. There are legions of articles discussing whether this framework is successful or not—that’s not what I’m here to discuss. Instead, I’d like to acknowledge that, for at least the near future, SAFe seems like it’s here to stay. So, in order to help you, my fellow designer in enterprise UX, thrive within SAFe, here are some of the tactics I’ve used to build design practices within my client teams.

 Issue 1: A De-Emphasis of Design in SAFe Leads To Low To No Design Resources or Design-Led Activities, Meaning the Team is Not Well-Balanced.

Background: At Pivotal, we form what we call “a well-balanced team” which is made up of designers, product managers, and engineers. We strive to have each member actively contribute to shaping product direction, as well as quickly communicate risks and blockers. On my recent consulting projects with SAFe teams, there have been few to no designers on any of the teams.

Mitigation: I couldn’t solve the lack of designers, but I could help others on my team to become more involved in practicing and valuing design. Amongst all its workflows, SAFe doesn’t make space for design, so I invented a ritual I call “Design Coffee”, a 10-minute design chat that helps all members of a well-balanced team feel connected to product/design activities. Each week, for 10 minutes (coffee in hand) a team member could share one product design topic for discussion. It could be work that needs some input, and/or a product decision and that decision’s rationale. All members are invited to give input, and if necessary, make time for a longer session at another time. The designer on the team (me) would often support the team member by visually facilitating or note-taking on the whiteboard what that person was thinking through.

Outcome

● Long design workshops were previously seen as blockers to “hands-on keyboards” for the engineers. This format, which we held right after morning standup, did not block engineering time and also led to teams to slowly be bought into more and more effective sessions involving the team around design.

● Design coffee permeated as a practice to other release train teams in SAFe when they saw it happening in our team.

● Design coffee made space for hard or unsurfaced topics in a fun, fast format.

● People on the team felt connected to decisions made in product, when previously they may have questioned those decisions.

● Members regularly cited design coffee as a win in weekly retros.

● Designers were seen as a welcome force to help clarify and test the thinking of members on the team.

 Issue 2: User-Centered Design is Not Used To Determine Priorities Alongside Business Needs By Executives.

Background: It was assumed by my client team that they had to do a time-consuming project component because a VP said it had billions of dollars of value. They were incredibly anxious about this initiative because they felt like it had no value, but they didn’t know how to say no to this VP. Also, SAFe doesn’t necessarily have designers involved with the prioritization of initiatives, so I was, by default, included in discussions around this initiative.

Mitigation: After I had built some trust using the Design Coffee ritual, I used the same ritual to try to understand and clarify what was going on with this proposed initiative. Since the team wasn’t sure if there was actually value in this project, I helped them form hypotheses to validate or invalidate their VP’s assertion. We went to interview 5 of the proposed users to understand their workflow with the data in question to be used and found none of them could use the data the VP wanted those individuals to use.

Outcome:I helped the team invalidate the original assertion by the VP, saving time and money on pursuing something with little to no value. In fact, the team presented our user data to their VP without me because I had a family health issue and couldn’t be present. It turned out, the VP was happy to trust them and their direction as experts in this product space. This showed the team that they could have a point of view, present evidence to a leader, and develop priorities that way. In the end, we were able to deprioritize months of work on an initiative that would have likely not come to any useful fruition.

Issue 3: Program Increment Planning (PI) Does Not By Default Contain Any Discussion of Users, Meaning the Conversations Are Sometimes Not Anchored in End-User Impact.

Background: For one client engagement, I went to two Program Increment (PI) planning, where teams plan their work together each quarter. The first had no mention of user goals or user journeys, just projects, and deadlines.   

 Mitigation: At the next PI planning, I collaborated with the PMs to make space on the agenda to discuss users and user needs. We also made time to get feedback on those user needs with all the teams present and perform a retro on the whole PI process.

To get ready for PI planning, we did the following:

● Facilitation training—I collaborated on helping multiple product managers get training on facilitation from one of our Pivotal product managers.

● Facilitation pairing—I paired with the release train engineer to focus his objectives for PI planning. I also worked with him to think about future ways PI planning sessions could center around user needs.

● Workshop on users—I facilitated a workshop where each team in the PI discussed their users and their user journey.

Outcome:

● PI planning for this client has started including user-oriented discussions around user journeys and user personas.

● Team members feel more enabled to tackle real issues around user needs.

Reflections

Building teams that incorporate strong design practices is a team sport in SAFe or anywhere. I was lucky to have some incredible fellow Pivotal engineers on these projects who helped reinforce the need for a user-centered approach. These tactics I’ve shared do not “solve” SAFe. Rather, I hope they inspire continued discussion in the design community around how designers can build trust across teams. Then, leveraging that trust, continuously build design into the process and, dare I say, transform SAFe from within. 

About the Author

Alexander Tran is a Staff Product Designer at Pivotal.

More Content by Alexander Tran