Executing Design at Scale

When I joined GE Transportation, there wasn’t a software organization, let alone a design organization. Sure, there were software engineers sprinkled around the organization, but no connecting structure in place. Over the coming months, a series of reorganization efforts ultimately created our Digital organization, bringing all our software builders in alignment. This alignment was in theory, but not quite in practice. Soon teams organized around Agile, and then eventually around Scaled Agile, or SAFe. 

Agile

Agile came to be from a group of developers unhappy with the workflow they knew. It was too rigid. It assumed people knew what they needed, and things rarely changed. And so, the Agile Manifesto came to be.

Scaling Agile

Agile was originally designed for a small team of software engineers to work faster and deliver more meaningful results. When products grow, the product development teams tend to equally scale. Eventually, the ways of working between a few people doesn’t translate to hundreds of people. And so, SAFe, or Scaled Agile Framework for Enterprises, was born. SAFe enables organizations of scale to harness the flexibility of agile and mitigate some of the challenges that teams of teams can start to introduce.

Challenges with Design in Agile

Many might not realize this, but in the Agile manifesto, design is actually mentioned:

Continuous attention to technical excellence and good design enhances agility.

The best architectures, requirements, and designs emerge from self-organizing teams.

So we all agree design is good, but everyone has different opinions on how design is incorporated. When looking at the SAFe process, Lean UX is prescribed as an ongoing effort, focusing on hypotheses and the Minimum Marketable Feature.

One of the conflicts of design in agile is timing. Agile sprints are typically one to two weeks long, but not all design can fit in that timeline. After all, we have to consider overall product strategy, how our users complete work, how work might change in the future, the users’ physical environment and the impacts that might have on the design, etc., not to mention the actual design, feedback, and refinement loop. 

A New Way of Working

Through a couple of years of trail and error, we’ve honed a process to enable all teams to capitalize on long-term strategy, and short-term design-led execution by focusing on four key principles:

• Simplify the complex

• Work in bite-size chucks to make things manageable

• Built-in exit ramps to ensure relevancy and quality

• Work in full transparency 

Buy-in

One of the core pillars is working in full transparency. We’ve found the best way to get started is to prepare a presentation that explains exactly how our design process works. This works if UX is brand new or standard within the org. As design is still maturing across organizations, there will always be someone who has a different expectation or experience with design.

Make sure to cover the core services—process, billing, deliverables, accountability, etc.. This eliminates most of the questions and ensures everyone is on the same page. Don’t limit these conversations to just leadership or decision makers. Try to meet with everyone, regardless of seniority. And continue to meet with teams until they don’t have any more questions.

Strategic Innovation

At a strategic level, we need to understand where we're going—this is the 50,000ft view. That's not someone telling everyone what page we're on, but rather the team collectively defining the vision.

When setting the initial vision, it’s important to not go too small. A lot of the things we're trying to solve are massive. And often times the solution is massive, too. This can be done a number of ways—meetings, workshops, co-creation sessions, etc.. There's no right way to do this, however, you want to include a few key things:

1. Understand the current state

2. Imagine the worst

3. Set the vision

4. Visualize the plan

Tactical Research & Design

With a strategy in hand, the team now needs to shift into a tactical mindset and take action.

Quarterly planning

This meeting is magical, but often overlooked. The entire team should get together to discuss what's on deck for the next 3 months. That means product managers, product owners, engineers, QA, researchers, designers—everyone should be included. Here, we plan out how every team is localizing the strategy. We want to define dependencies, deliverables, blockers, questions—get everything is out in the open. If you’re familiar with Scaled Agile Framework, or SAFe, this is a page out of their playbook. It works. This will take a day or two, depending on the team size and scope. But it's worth it.

High-level research

Now it's tempting to jump right in and get started. Let's tackle that first box in the roadmap, right? Not yet. We typically want kick off research by focusing on the entire scope. We focus on deeper research at the ecosystem level, to make sure our strategy and assumptions are right. Make sure it's possible. This typically takes a few weeks, with the goal of validating our plan is right, and understand the broader context. This discovery work typically covers taxonomy, high-level workflows, technology landscapes, etc.. These insights will pay dividends over the entire project.

Focused discovery

Then we focus on the first piece of the roadmap for in-depth research and product design. Here is where we get into our typical double-diamond process: discover, define, design, deliver.

Iterative design

Iterate the design with real users to increase buy-in & adoption. This essentially builds FOMO, or Fear of Missing Out. Now, during design, don't forget that your engineers and developers are equally important in the iteration and validation process—early and often. Their buy-in is key to successful products. You don't want a beautiful design that your users love... that turns out to be unbuildable.

Agile Execution

Quarterly planning

Remember everyone is brought in for the quarterly planning session. That's where we're planning which stories are being built over the next three months. We review all the research and design done in the previous planning session. We review the prototypes the engineering teams are going to build. Most importantly, this gives developers time to ask all the questions they have, see the related research, and be empowered to own their deliverables. Another key element here is participating in stand-ups. Everyone should. They're not just for developers. Stand-ups exist to keep everyone up to date. Don't skip them, then bug people for updates on your schedule.

consistant support

Hand-offs make sure designers have a clear finish line, and encourages non-designers to go review research and understand why things were designed the way they were. The deliverables can change depending on team needs and project maturity, but a few things have been key:

• Research report, showcasing clear insights that led to the design decisions made

• Personas and journey maps relevant to the delivered prototype

• Interactive prototype, with links to design system components used

• Access to all research assets, for developers to explore

Don’t let the term ‘handoff’ confuse you. Design teams are still supporting engineering teams every step of the way. At least one designer should be responsible for attending standup—this is key to providing consistent support and facilitating communication.

Celebrate success

Typical agile process has a demo at the end of each sprint. This is not just for engineering teams. In fact, it's more important for the rest of the team to join in, rather than just engineering. After all, developers talk... they know what they did that sprint. End-of-sprint demos is a great time to come together and celebrate all the hard planning, research, design, and development that has come together in these two weeks. This is an amazing feat. Don't just view this as an engineering meeting. Celebrate the team's accomplishments with the team. This creates a strong team, and you're seeing the product take shape. This allows you to quickly react to anything not following the plan.

Regular Alignment is Key

The bigger a company is, the more communication needs to happen. With so many moving parts, over-communication is key to avoid rework and standstills. 

Every 6 months

Validate the strategic roadmap every 6 months with internal and external stakeholders. Things change. Business environment changes. This ensures you're delivering meaningful value, in the right order, for your customers and your business.

Every 3 months

Every quarter, come together to plan the next 3 months of work: research deliverables, engineering deliverables, and map out the next 6 sprints.

Every 2 weeks

Celebrate success though team-wide sprint demos. This creates a strong team, and you're seeing the product take shape.