Aligning human-centered design and Scaled Agile Framework (SAFe)

TL;DR

On the surface Human-Centered Design (HCD) and SAFe might seem like they would work well together out of the box. In our experience, this can be a much bigger challenge than you might expect. The ebb and flow of HCD depends on the stage of the design process, which doesn’t always align with the rigid schedule that SAFe requires in the PI structure.

We have found success by focusing on the strengths and the common ground between HCD and SAFe, such as the double-diamond design process, iterative design/development, and release on demand. This has enabled compromises between the two methodologies and contributed to a shared vision for the product these teams are building.

Background

One weekend in 2001 in the mountains of Utah, 17 software engineers met and created the Agile Manifesto. These 12 principles for developing software can be summarized as follows:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

They envisioned a way to increase responsiveness to user needs and changing requirements without sacrificing velocity.

As these agile principles were forming in the late nineties, so was human-centered design (HCD). There were new ideas around design thinking. These new ideas focused on:

• User needs over technical requirements
• Proactive user research over reactive user feedback
• Processes that fit the users over training users to fit the system

New standards of user research were being implemented to affect design decisions in real-time based on user needs and changing requirements.

Because of the similarities between agile and HCD principles, you might think that the merging of HCD and Agile methods might be relatively easy. In practice, it isn’t. Profound challenges remain when aligning HCD best practices within an agile environment. They are two processes just different enough to cause friction and pain if not properly managed.

Federal agencies have made strides in adopting agile methods. Some federal agencies have adopted an agile framework that gives digital service teams the flexibility of Agile while the government provides oversight and planning aligned with waterfall software development methods. This way of working, called Scaled Agile Framework (SAFe), is designed to coordinate agile teams around shared goals in a way that increases their speed without the heavy documentation of waterfall development.

Increasingly, federal agencies are also bringing human-centered design into their toolkit as a way of guiding the work of digital service teams based on the researched needs of actual users. HCD is a key component of bringing user needs into an agile process, but at times both Bellese and AdHoc have found challenges bringing the spirit of HCD into SAFe environments. The chief challenge is that SAFe works in Program Increments (PIs), which manage work in 6-12 week cycles. The goals and work priorities of PIs are carefully planned at the beginning of the cycle, and teams must follow the priorities set in PI planning with bi-weekly demos showing progress.

In effect, this means that SAFe teams only have four to eight development cycles a year. PIs dictate when new insights can be implemented. They can also drive a waterfall mentality as teams become focused more on outputs from the PI plan vs outcomes for users of the product. In this way, the priority that SAFe puts on planning and velocity can hinder the flexibility valued by HCD and agile development methods.

While this mismatch in priorities can be a challenge, Bellese and Ad Hoc have found a number of product management strategies to bring the values of HCD into a SAFe environment.

Find shared foundations to bridge the gap between human-centered design and SAFe

While agile and human-centered design could be considered first cousins, SAFe and HCD are more like second cousins once removed.

SAFe and HCD have distinctly different context, goals and rhythms. SAFe was originally created as a way to articulate how existing, proven Agile practices could be scaled and combined to work as a system for large-scale software development. SAFe’s original 3-4 versions were built from Agile techniques focused on the delivery of a defined backlog of work. Only recently has SAFe included HCD practices that have a decidedly different focus and context. HCD focuses on the discovery of problems where the rhythm traditionally is more variable and similar to R&D than it is to the manufacturing analogy of software development (see Kanban). With the introduction of proven HCD practices into SAFe 5.0, these differences in rhythms and focus still exist but they also share several foundational factors that can bridge the gap to help them work better together, such as:

1. The Double Diamond

Illustration of the double-diamond concept

SAFe originally did not have a single reference to HCD-specific concepts; however, in the latest version, SAFe has started to explicitly include more HCD practices. As of SAFe 5.0, both HCD and SAFe share the Double Diamond concept of divergence and convergence. This method encourages a broad process to explore problems (divergence) and then a move to focused action to solve the most pressing problem (convergence). Both of these competencies place understanding the problem as the first step, then designing the solution next.

2. Cyclical Iteration

Key to both Agile and SAFe is a cyclical, iterative design process. This explore, integrate, and deploy cycle is at the heart of HCD as well. While the cadences of this iteration do not align out of the box, this shared commitment can be the basis for building more commensurate rhythms for development.

3. Release on Demand

A core tenet of SAFe is Release on Demand (ROD). The concept of a Continuous Delivery Pipeline is also at the heart of both Agile, SAFe, and as it turns out, also HCD. Human-centered design is dependent upon user feedback driving iterative design. The faster we can implement these insights, the better the experience will be for the users.

Plan for iterative improvements to features currently in development

For HCD to succeed within SAFe, product teams need to be able to pivot quickly in response to newly-surfaced user needs and customer requirements. SAFe takes the spirit of sprint-by-sprint and team-by-team responsiveness and extends it across multiple teams over 6-12 weeks. As a consequence, once the plan has been set, there is a long lag for reprioritization. This deliberate process leads to a stable release train and predictable capacity — which is valued in the world of government contracting — but it can also hinder iterative development because it requires any pivots to wait until the next planning event.

Our approach to this method is to leverage these cycles to refine our solutions as much as possible and plan enhancements incrementally. We generally have two independent usability studies for each feature. This allows at least two opportunities to further refine the product before we push it to production.

Distribute product management into self-organizing teams

In human-centered software development, proper product management is essential from requirements gathering through development and iterative releases. Any time we learn something from users, the organization needs to make a decision about how to act on that new information. Beyond the cadence of product management, however, there remains a fundamental mismatch between how the SAFe and HCD frameworks handle product management.

When distributed product management is done poorly by uncoordinated teams, you can end up with a hodgepodge of features rather than a functional, integrated product. SAFe, in part, is designed to prevent the tendency of other agile methods to produce just such a hodgepodge. SAFe product development has many opportunities for decision-making, but these are driven primarily by information from within the organizational context: capacity, velocity, and satisfaction of intra-product dependencies are often the most important operational Key Performance Indicators (KPIs) for backlog grooming and planning in SAFe organizations. Proper product management also balances these internal metrics with an external perspective from actual users of the product.

When this is done well, it allows organizations to be outcome-driven and product decision-making to be decentralized but still rational. We accomplish this with small product teams embedded with designers and developers working together from the start.

One of the ways that we’ve been tackling this decentralized, but coordinated product decision-making mismatch is by developing a more robust product footing than is found in off-the-shelf SAFe. We start by establishing a rationalized portfolio of products and sub-products, each supported by specific multifunctional product teams. Each of these teams includes a product owner, a business analyst, a designer, a developer(s), and a researcher. Most decision-making about product direction is then handled at this distributed level and informed heavily by user research. These teams are designed to be self-organizing. Teams size work, plan work, and forecast their own velocity. The goal is to allow rapid, iterative product decision-making to continuously improve the product, and improve the quality of the product by not creating unrealistic workloads. This collaboration at a feature level allows for more transparency into what is resonating with users and where resources should be allocated.

Working in government adds another layer of difficulty to teams with HCD-minded product owners: the insights common in the corporate space are often lacking. Metrics such as customer turnover or share of market are hard to find if they exist at all. Without these guiding data points, it can be difficult to even understand what’s important for a product. Typically, we end up relying on data gathered from usability studies as well as usage analytics to identify usability issues in the system.

When faced with these challenges, our approach has been aided by our metrics strategy. We use the North Star Framework to lead much of our iterative product design. The idea is to find the North Star metric for the product — the one metric that matters. Once you have identified the KPI by-product, you start to understand how to prioritize your features set. Another tool we use to help us prioritize our roadmap is an Innovation Matrix. This allows us to divide our work into innovation segments, moving from Core (think basic modernization) through Adjacent (adding incremental products and assets) to Transformational change (true innovation).

Common ground

Diving into the underlying principles behind Agile, SAFe, and HCD, one quickly sees that they share common ground. All three strive to incorporate user feedback into the product life cycle, and we believe this feedback is critical to the success of any modern digital product or service.

In our work, we leverage these foundational similarities as much as possible. By placing a high emphasis on iterating during the development cycle, we are able to implement user feedback rapidly and still meet release deadlines. Additionally, our self-organizing product team structure allows for faster prioritization of user feedback during product development.

It’s hard to imagine what those original 17 software engineers would think of our extensions to their vision. We tend to believe they would admire our ability to respond to change over following a plan. Because at the end of the day, our highest priority is still to satisfy our customer and our users through early and continuous delivery of valuable software.

This post was co-authored with our partner Ad Hoc.

You can also read this post on their website at https://adhoc.team/2021/05/25/aligning-hcd-agile-safe/