Experience Report

User Experience design: a true part of SAFe or a patch?

About this Publication

This experience was derived during our transformation to Scaled Agile Framework (SAFe) in Demant, started in January 2021 and ongoing. In this report we share our experiences and sum up what we did wrong and learned about building high-performing Design Teams under the SAFe umbrella.

1.      INTRODUCTION

Demant is a world-leading hearing healthcare group that offers solutions and services to help people with hearing loss connect and communicate with the world around them. In January 2021, we got the approval to transform Demant, R&D Software Solutions department into SAFe – a project that involved 250 professionals (from Developers and Testers to User Experience Designers, Project Managers and Product Owners) working from three countries: Denmark, Poland and Switzerland.

While implementing SAFe we decided to use a “by the book” approach. But after a year we must admit it was a struggle, and we feel that “the book” lacks guidance on how to include the User-Centered Design process in the SAFe.

2.      Background

Before going SAFe we operated in two product areas – Fitting Software Area (software for professionals) and Mobile Apps Area (applications dedicated to hearing aid users). These areas had an Area Product Owner (APO) and a Marketing Product Manager (PM). We also had scrum teams with a Product Owner and a Scrum Master, 4-5 developers, 2-3 testers and a Business Analyst. Because of the limited number of persons we shared design competences among teams, for example, one UX Designer supported two teams. This setup had its drawbacks, of course, but overall, we were quite happy with our achievements as a team and the maturity level of our User Experience (UX).

In early 2021, we hired an external SAFe Program Consultant (SPC) to drive the changes. As part of a gradual transformation, it was also decided to implement SAFe on the team and program levels first and after few increments to continue with the portfolio level. As it turned out, this decision strongly influenced the challenges faced by the Design team.

The value stream analysis we did at the beginning of the transformation resulted in four Agile Release Trains (ARTs) called:

  1. Fitting Software Digital (software for hearing care professionals)
  2. Fitting Software Device (related to hearing instruments features)
  3. Apps on Earth (mobile apps for hearing-impaired people)
  4. ART in the Cloud (cloud services)

Before writing this paper, we had already started three out of four Agile Release Trains and tried out two different ways of including the design competences – which we call Design Teams.

3.      Top-down, by the book approach to SAFe implementation

We – Teresa and Helle – Line managers for UX Designers, UX Researchers, UI Designers, UX Writers and Business Analysts, wish to motivate our team members. We want them to feel listened to, included, and part of the teams. We must also ensure that they are able to do what they do best – design great user experience.

At the same time, we as a Company decided to use a top-down, by the book approach to SAFe implementation. We, UX Team Leaders, quickly learned there is no “by the book” system for including design competences. Hence, in addition to transforming the teams from a semi-agile setup to scaled agile, we also needed to define how our competences would be included. During the first months we spent a lot of energy trying to understand how best to prepare UX people for success. But we did not manage to do so in the first iteration, and this statement shows it:

I’m feeling like I’m a pain in the ass, my work seems not necessary”. [Design Team member during the retrospective]

4.      Top-down, by the book approach to SAFe implementation

During one of the first training sessions with our SPC we learned that SAFe does not advise sharing people between ARTs and Teams – each should independently deliver values and features. Knowing this, together with the fact that we do not have enough people to supply all competences to all feature teams, we began exploring other solutions.

We were aware that the change would o be huge and perhaps painful (SAFe has a bad reputation in the UX world). But we were eager to do whatever we could to implement it smoothly. We read many articles, met with other companies who had already transformed into SAFe, reached out to SAFe Consultant Rune Kølle Christensen and attended some NN Group Agile UX courses.

“What I remember from that period is mainly the fact that I had 32 meetings every week, not much else.” [Teresa – Design Team Leader]

The conclusion was to extract all User Experience related competences from Agile teams (Business Analysts, UX Researchers, UX Designers, UI Designers and UX Writers) and establish one Design team per ART (we had two ARTs at that moment).

SAFe is very well described as a framework, sometimes down to a level of detail that defines lunchtimes during increment planning. Unfortunately, it is silent about the role of a Business Analyst and reduces the User Experience activities to collaborative design. So we wanted to fill this gap and be precise on how UX should work. We questioned whether we need a Scrum Master, do we need a Product Owner, and which ceremonies, tools, and roles are needed. Perhaps we went overboard when defining this new setup. We detailed how to work, we established new roles, we felt success upon adding our input to Definition of Ready (DoR) and Definition of Done (DoD), and we wrote many pages documenting our decisions. We agreed that the Design team would have a Scrum Master but not a Product Owner. With this setup we aimed to give Design people time and space for closer collaboration during the discovery phase and a chance to follow features over time (from discovery to in-market). This had one obvious drawback: design competences were no longer close to or even part of the Agile team. We saw only the top of the iceberg!

5.      A True Story – The Octopus team and the Heartbeat team

Among the first tasks for each Design team was to choose a name, and the invented names say it all – they were the glue that made it all work. The Octopus team and Heartbeat team consist of:

1 Scrum Master

1 User Experience Architect

1 Business Analyst Lead

2-3 User Experience Designers

2 User Interface Designers

2 Business Analysts

1 User Experience Writer

1 User Experience Researcher

Figure 1. ART setup – first iteration

Each Design team served the full ART – being usually four Agile Teams. They were also key partners for Business Owners, Product Managers and some stakeholders from outside the ARTs.

5.1      First challenges

Most of the challenges that surfaced in our transformation to SAFe were not new but are experienced by designers in many Agile frameworks. Agile and Scrum were not created to support the design process, however many companies have shown that they can work together.

We knew that problems would arise, and we tried to prevent them. But our problems were not apparent to the rest of our organization, and we clashed over the lack of a common strategy and voice.

5.2      Different time zones (Design team vs Agile teams)

Working in different time zones was a challenge. In Demant, UX Researchers, Business Analysts and UX Designers have always prepared content for our features by means of explorative research, prototyping and usability testing. In Demant we deliver specialized solutions for people with hearing loss and for hearing care professionals. To deliver value in such a specialized and delicate domain requires extensive study.

We wanted to continue this process in SAFe, knowing it brings quality to our products. We wanted to involve researchers and designers in formulating epic hypotheses and creating strategies. But because at the beginning of the transformation we implemented SAFe without a portfolio layer (no portfolio roadmap, no epics) we had backlog of features only at the beginning. So suddenly we had to find a way to merge our UX competences with non-existent processes or phases. SPC encouraged us to refine our well-established process to fit into new procedures. Meaning making prototypes and usability tests parallelly to development of the very same feature. Every UX person knows that exploring while the developers are developing is usually not a good idea.

5.3      The lack of PO during the discovery phase

We decided not to assign a Product Owner to the Design team, but only Scrum Master and lead roles called UX Architect and BA Lead. The goal was to encourage the PO from the Agile team to work together with the Design team and Product Management Team (PMT). But Product Owners were focused on features they needed to deliver during the increment. We were not able to empower the PO and other agile team members to play their roles in the discovery phase. As a result, designers were discussing feature ideas directly with PMT. They felt very alone, and Product Owners felt likewise.

“I told my Team Leader I write user stories and he was surprised, cause it’s PO’s responsibility.” [Design Team member]

5.4      Detachment of designers from technical knowledge

Working in different time zones and having our Product Owners and Agile teams detached from exploration resulted in a lack of cooperation and lost technical knowledge. These had consequences for the quality of our deliveries and findings. We frequently had to redo solutions that were too complicated to implement. We began repeating mistakes made during early days of User-Centered Design in the Company. We inadvertently made the waterfall bigger than it was before going SAFe.

5.5      No clear priority on user centricity

We were also challenged by the fact that our SPC was not used to working with companies so committed to design as ours. We felt our UX goals and values were not appreciated and respected, sometimes even seen as contrary to Agile philosophy. This led to a lack of clear priorities for the Design team in the ART and strong focus on the delivery phase. Even when going through SAFe training materials, all subjects related to user centricity were skipped by consultants. It was very frustrating for our UX people but only resulted in our SPCs saying things like: “UX people take 80% of our capacity but bring only 20% value” or “You are not the center of the Universe”. People were hard to motivate after statements like this. We UX managers have failed to establish common goals with the rest of the Company. Now it is clear that before changing the way we work we need to clarify guiding principles such as: optimize velocity vs quality, SAFe maturity vs UX maturity. As a result, we received comments like:

“Management has zero know-how to apply design processes in a modern way”. [Design Team member]

5.6      Our key learnings so far

As you can see, it was difficult at the beginning and our first attempt to implement design competencies in SAFe was not a success.

Important insights gained during our first iteration:

  • Discovery phase: must be planned, transparent and prioritized in the same way as features in SAFe. If user-centricity is important for your company, then find a place for those activities within the Agile framework.
  • Discovery tasks are not tasks for designers alone. Everyone should contribute to this phase and Product Owners are needed to drive the process. To achieve that we implemented work items called exploratory enablers. We also decided to decentralize design competences to empower Agile teams.
  • UX Managers: must be assertive partners to Agile Coaches during the implementation of any framework. User-Centered Design cannot be implemented in Scaled Agile if it is not an integral part of Agile strategy, supported by the entire organization.

Figure 2.: Dual-Track Agile and exploration enablers

If the above does not happen, then what Jared Spool described as Reactive UX in Agile happens: “Reactive UX in Agile focuses on shrinking the UX process down to fit inside of a sprint. We must reframe to be proactive instead of reactive”. J. Spool.

6.      A True Story – Agile teams

These new findings led to changes in the setup: our design skills were included in Agile teams (which resulted in dissolution of the Octopus and Heartbeat teams), and exploratory enablers were added to the Program backlog.

However the changes created frustration in the Design teams, who were working hard to make them function, having defined pleasant, proactive ways of cooperation. After experiencing so many changes in only six months most of them were exhausted and argued that better discovery planning would be enough to solve their problems. They did not need another revolution.

“SAFe was intended to be an experiment- “it’s okay to fail” – but apparently we feel responsible, even though we did a great job”. [Design team member]

6.1      The UX competences embedded in teams

These new findings led to changes in the setup: our design skills were included in Agile teams (which resulted in dissolution of the Octopus and Heartbeat teams), and exploratory enablers were added to the Program backlog.

Having design competences being part of Agile Teams, we needed to share some of our resources, as we’ve done before. But this was not the old setup. We changed expectations towards our Product Owners and Scrum Masters. We changed the system considerably, with ceremonies, PI planning events, work items, etc. So reinforcing our SAFe transformation was imperative to ensure our design competences and their needs were included in Agile teams. Furthermore, thanks to exploratory enablers other Agile team members were included in the discovery phase to a higher level. We were striving to implement what is called Dual-Track Agile into Scaled Agile.

Figure 3. ART setup – second iteration

6.2      Challenges again

The world would have been perfect if we hadn’t discovered some new problems with the new setup.

How to calculate team capacity and estimate features: some features require mainly designers and others mainly developers. If one person is a member of two or more teams (for example UX Designer), who ensures that this UX Designer is truly part of a team? How to support the flow of knowledge between the discovery and development phases, if during PI planning every team can pull every feature?

So after the second iteration of our SAFe journey we had some new problems and questions we couldn’t answer.

6.3      Capacity planning and prioritization

With canceling Design Teams we miss overview of design competencies capacities, and it’s much more difficult to shuffle capacities between different features and enablers. A developer usually has a simple situation: one team – one Scrum Master. But if a UX Designer supports two teams, questions arise: “If I belong to more teams, do I have all my capacity in one team and what happens if my SM “lends” me to other teams?”, “Or maybe I upfront divide my capacity between the teams I support, but is it 50/50?”, “Which events do I participate in, am I needed in all ceremonies in both teams? If so, when can I find time for the designing?”.

We are still seeking the answers and still hope for the ideal setup. But in the matter of capacity and priorities among the teams we think Scrum Masters will manage to facilitate the discussion case by case and increment by increment. After all, this is the essence of their role. We try to let them lead the work of team members also other than developers.

6.4      Team belonging

Two teams are still half the trouble, but what if someone supports four teams? In our setup we have two such roles, namely UX Researcher (1 per ART) and UX Writer (1 per one or even two ARTs). It is part of their job to focus on the whole ART, see the integral product and avoid the feeling that one team has more right to use their skills than the other. But as a result they are homeless and again questions arise: “How do I establish good work relations?”, “Why has no one invited me to an important meeting!”, “Sense of belonging is important to my job-life satisfaction, but I do not want to attend four daily stand-ups each morning!”.

Until now we have advised those role players to sit together during PI Planning at a shared competences table and plan their work for the next 12 weeks by negotiating with the teams where and when they will be needed. These are independent roles and do not have Scrum Master. We try to keep these persons close to the Product Managers, to help them remember to include them in all important ceremonies. Maybe in the future we may discover that it is worth asking one of the Scrum Masters to additionally support these roles? We are still inspecting and adapting.

6.5      Continuation of knowledge

We are very pleased with the fact that we have implemented exploratory enablers – the discovery phase is planned and transparent. But problems appear when it ends and development begins. “If I have just spent two months mapping all connectivity problems between hearing aids and different types of mobile phones, do I have a guarantee that my team will attend to the development?”. SAFe does not guarantee this because during the planning a different team can take this task. In such a situation, is it better to change the team or try to pass to someone else my two months of analysis and 100 corner cases that I have mapped?

Again, we don’t know the answers yet, so we try to minimize the risk of handovers by implementing dual-tracks of discovery and development, where all roles are involved in both tracks, with varying degrees of capacity. It is therefore in the best interest of the whole team (not only the designers), to continue working on something they have already started. And if they cannot continue, they should plan an alternative option to achieve the best effect.

6.6      DesignOps activities

User Experience belongs to the product or service and not to the ART or a feature. Efficiency, consistency, quality and our work standards can be addressed during our joint product development. The distribution of design roles between Agile teams has its advantages, but the risk of worsening user experience due to inconsistent design or simply doing the same work twice is growing. Developers have their DevOps teams to optimize the flow and although is an industry standard that in enterprise companies the separate Design System Team and ResearchOps Manager arise – but we are not that big (yet).

We are trying to mitigate those problems in a several ways:

  • Have one Design Team Leader per ART – bringing together all design competences from all Agile Teams
  • Demo our work or do the design critiques on various forums
  • Have Community of Practice and regular meetings for everyone with the same competence (e.g. Business Analysts), to set standards and encourage knowledge sharing
  • Use same tools setup across all teams designing the same product
  • Create and maintain the Design System with the Requirement Manager role at the level of the product

We are unable to say if this work yet. Maybe this is the topic for the next Experience report.

7.      Reflections

Some Scaled Agile Framework principles support a User-Centered Design process. Value thinking, focus on outcome, quality approach, portfolio and program roadmaps are well aligned with user experience good practices. We can build something good on that, but “how to” is not described within the SAFe. If you are about to implement Scaled Agile you must find your own way.

We can suggest three activities worthy of focus:

Implement Scaled Agile with User-Centered Design (UCD) in mind: being part of Definition of Ready and Definition of Done are crucial for delivering quality experience but are not enough. And treating designers just like developers won’t work. If being User-Centered is part of the Company’s strategy, then it means that the Scaled Agile transformation should take this strategy seriously.

Create space for discovery: good user experience cannot be designed within one sprint. In our case exploration enablers served to enable dual-track development and gave us space for user-centered activities.

Build psychological safety: people management is super important during every transformation; therefore you must ensure team building activities, sense of purpose, clear tasks. Include the HR department in your SAFe transformation, they can certainly advise on how to work with your team during the change-over period.

Many UX Designers have chosen this profession because they wish to make the world a better place. After a year of constant changes some of our team members may have forgotten that improving the quality of life is also Demant’s mission. Once the biggest changes are behind us, we will invite them to discuss how we can add improving users’ lives to our SAFe Definition of Done.

8.      Acknowledgements

We would like to start with thanking our shepherd Mia Kolmodin for her constant support and honest feedback. Special thanks go to Debby Moeller for English proofreading. Last but not least we feel lucky to have such amazing and dedicated Design Team members who are with us on this journey.

REFERENCES

[Lean UX and SAFe] https://www.scaledagileframework.com/lean-ux-and-the-safe-program-increment-life-cycle/

[SAFe roadmaps] https://www.scaledagileframework.com/roadmap/

[Agile vs UX] https://www.nngroup.com/articles/agile-not-easy-ux/

[NN Group materials on Agile] https://www.nngroup.com/topic/agile/

[Jared Spool speaks at BostonCHI, Reframe Agile to Deliver Great UX]: https://youtu.be/EkXREqOJYS8

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks
XP 2022

Your Bookmarks

No favorites to display. You must have cookies enabled to add bookmarks.

Have a comment? Join the conversation

Related Agile Experience Reports

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now