Just a few weeks ago, Scaled Agile Framework launched SAFe 4.0 with some great improvements across the board implementing a whole new level of value streams and a tighter connection to the enterprise. You can read more about these changes in our posts on Why I love SAFe® 4.0 and Why I Love SAFe® 4.0 Part II.
So what’s in it for design?
SAFe integrates pieces of both Lean and Agile UX methodologies eliminating Big-Up-Front-Design (BUFD) and transitioning the design teams towards iterative design and research processes. There are plenty of advantages moving towards an iterative design process, but most importantly, it eliminates the massive bottleneck created by throwing red-lined design documents over the ‘fence’. We’ll touch on a few key areas to help design teams dive right into SAFe 4.0.
To start, I’ll make a clear distinction between Lean/Agile UX here and talk about how SAFe 4.0 supports both.
Agile UX, as the predecessor to Lean UX, was an effort to blend design processes with development teams moving towards agile methodologies. Agile UX utilizes similar tools, practices and ceremonies found in agile development with some slight differences. We’ll highlight a few key areas in SAFe that can strengthen your current processes or jumpstart your transition towards Agile UX.
Lean UX is a cycle of building, measuring and learning that encompasses Agile UX. Though some would make a clear distinction between Lean UX and Design Thinking, I'd say Lean UX and Design Thinking are one and the same - they are dependent on each other. While Agile UX is focused on building, Lean is focused on research, user insights, and testing. We'll talk about how SAFe 4.0 brings flexibility to design processes that businesses tend to undervalue.
Introduced in SAFe 3.0 with an added focus for design teams in 4.0, the architectural runway supports the business and development practices by making sure there’s sufficient infrastructure in place to keep the development team from running out of track. This doesn’t just refer to performance enhancements, technology upgrades, protocols, etc.. but to UI components, defined UX patterns, and reducing redesigns.
How can designers help maintain a healthy architectural runway? Invest in aggregating repeated components, creating a centralized component library and define key UX patterns to ensure consistency throughout various products. Most importantly, maintain these libraries as new features require new components.
The design team should be very aware of how UI components are handled and help define CSS best practices around variables, helper classes, animations, etc... Not only does this promote faster dront-end development, but it ensures consistency and reduces 'clean-up'. There will be less one-off components and pixel pushing.
- development work will only need designs for components unique to any given feature
- Reduced development hours spent rebuilding components
- Reduce high fidelity mocks from design teams.
- Reduced risk of redesign, but any re-skinning easily ripples throughout the application.
- Centralized component testing. QA can test component functionality across the application instead of testing every one-off.
Enabler Story Spikes
Enablers are meant to support the development team and business initiatives with exploration and research needed to validate functionality. For design, the vast majority of the design backlog is composed of enabler story spikes. Since the vast majority of components and UX patterns are pre-defined, these stories cover research, prototyping and iterating on cross-cutting functionality, information architecture, new features, etc… From a Lean UX perspective, these stories are the backbone to the build-measure-learn design loop.
- Supports developing a cadence for design research and usability testing
- Removes ambiguous design tasks from stories
- Helps manage the balance between just-in-time design and reducing unknowns
- Manage large centralized design teams more efficiently with better visibility
- Ensure a voice for the user throughout the product development process
Common Cadence Design Sprints
SAFe best practice is to support multiple programs through one centralized design team to avoid a segmented experience across products. Pulling from the design backlog, the design team works on the same cadence as the development teams delivering ‘just-in-time’ design.
Most design stories are inherently dependencies and it helps to think and manage them as such. ‘Just-in-time’ design sounds intimidating and too high-risk, but remember we have a much larger supporting base through spike stories (we’ll talk about these later) and the architectural runway. By the time we need to provide designs for a story we have already explored, researched, and tested the parent feature. We also have globally defined components and UX patterns that will be reused and repurposed in the new feature. Mid-sprint, design should only be supporting on edge-cases and ironing out the minimal uncertainty left.
Solely working with Agile UX methodologies, we may design an entire feature three sprints ahead of time, make assumptions and produce high fidelity mocks as we go into the next sprint, but as we implement Lean UX methodologies where we’re in a constant feedback loop of building, measuring and learning, we start to mitigate risk. It’s one thing to stay ahead of development, but dropping in high-risk designs may cause costly re-designs later. Testing and iteration is incredibly important when working towards just-in-time design sprints.
How do we accurately frame the problem and reduce high-risk designs up front? Build out a factory to process incoming features. From Google to IDEO and software to hardware design teams use similar processes to Define the problem, Ideate solutions and Validate through testing. Like Google Venture's design sprints, it's often helpful to timebox these processes into a week or even a day.
- Centralized design team ensures consistency across products
- Reduce mid-sprint bottlenecks
- Managing design stories as dependencies creates better visibility across the design and development teams
- Less time developing mocks mid-sprint, more time working closely with developers to ensure design quality
- Just-in-time design reduces BUFD
The design backlog is not identical, but somewhat complimentary to the product backlog. The design team’s job is to translate the product roadmap into phases of research, prototyping and design iteration to validate new features and integrate them into the existing experience. Similar to the product backlog, these phases may break down into epics, features, and eventually enabler stories.
In Lean UX, this helps us prioritize research and usability testing outside of in-sprint design support and visualize the big picture. Since we often conduct research at different levels (from wholistic to very granular) and for different purposes (value, usability, conversion), there’s value in having the ability to group research initiatives and keep them focused.
From a managerial perspective it helps reign in scope creep and reduces design waste. Too often designers spin tires on BUFD that either never sees the light of production or is thrown away due to changes in requirements. Throwing away designs due to an overall change in the product roadmap or market needs is not iteration, it’s waste. Sometimes this waste is unavoidable, but managing a healthy design backlog and moving closer towards just-in-time design helps trim the fat as scope is more accurately defined.
- Dedicated, tangible means to manage and prioritize research initiatives
- Reduce scope creep and design waste
- Develop a design process cadence
- Seeing is believing: Design backlogs are a good way to get buy-in from stakeholders that the measure/learn piece is just as important as building
- Be ‘Agile’ but keep your process! A misconception with Agile methodologies is that it forces Designers to drop process for the sake of moving fast. With a healthy architectural runway and a research cadence managed through your backlog of spike stories, design thinking processes will live on in your team (and hopefully your organization).
At the end of the day, this is the goal, not the reality on a daily basis. We deliver based on business needs - and that depends on the business. At a startup, I often find myself bypassing process for the sake of shipping, but these processes enable me to revisit, learn, measure and iterate. As evident in SAFe 4.0, Agile is not an enemy to good design. If anything, user-centered design becomes more focused, more iterative and more effective. No pressure, no diamonds.