The agile design team maturity scale

Design is historically a waterfall process. The change to an agile workflow is usually driven by the engineering team, or by the demands of the organization to deliver faster in the face of market disruption. Whatever the reason for the switch, in my experience the journey to adapt to an agile practice appears to follow the same pattern.

This journey is similar whether the design team is an in-house product team, a digital agency, or a consultancy—there are just differences in how difficult it is for the team to move along the journey or where they start. I also believe that the recent trend of designers moving from agencies to in-house positions is connected to the opportunity to move along this journey, and the impact they can have on the products they create.

Related: How to adapt design for agile workflows

From conversations with other designers and design leaders, or those who have heard me talk on the subject or read one of my previous articles, it has become clear that every team or organization is on the same journey. They all recognize where they are on the journey, and the steps they’ve been through. There’s also great interest in knowing where other teams are on the journey, as well as identifying the right steps to move forward.

I’ve created the agile design team maturity scale to chart your team’s progress and to benchmark it against others. It also serves as a target to aim for in developing your practice.

The agile design team maturity scale

The scale is a simple 10-step journey that moves through 3 distinct stages, starting at throwing grenades, moving to feeding the beast, and eventually getting to design facilitation. No 2 teams are exactly alike, so the scale allows for room between the 3 main stages to acknowledge those in-between steps.

When a team begins to adapt to an agile workflow, they can be at any point on the scale. This depends on how they worked and how they were structured before the change. For example, a large organization that operates a design department will most likely find themselves right at the throwing grenades stage. On the other hand, a startup building a brand-new design team may find it possible to jump right in at design facilitation on the scale.

Different teams move at different speeds along the scale. As you’ll find out below, most teams really slow down when they hit the feeding the beast stage.

It’s also possible for a team to move backwards on the scale for various reasons. Those reasons could include things like: organization changes, changes in the way the engineering team operates, or simply if a movement on the scale doesn’t work for the team. Moving backwards isn’t a bad thing. Teams have to figure out the most effective way to work.

The scale isn’t intended to measure how effective a team is—it’s intended to highlight a common journey experienced across the industry. The effectiveness of a team depends on how the team is measured. As you’ll see below, the method used to measure a team is the main indicator of movement on the scale. The scale is best used to describe where your team is at and where you want to get to.

Throwing grenades

This stage is where most design teams start from when adapting to an agile practice. It comes from the core design process of briefing, creating, collecting feedback, and then delivering a finished design. This is typically how an agency might operate. It’s named after the way a finished design is handed over to an engineering team in the pre-agile siloed world, affectionately known as throwing a grenade over the wall.

In this stage, the design team operates as a single unit. They’ll sit together, often in a different room or even building from the engineers. They will most likely refer to their office as a studio.

The team takes orders from the business or client in the form of a brief or a set of requirements. They will transform this brief into a beautiful design, gathering feedback from the business along the way. The business will sign it off, then the design team will prepare a specification document to hand over to the engineering team. They will then move onto the next project.

An extreme example I’ve experienced has each specialty of design working as an individual silo, each handing over to the next silo as part of the delivery process. Solution architects hand over to interaction designers, who hand over to visual design, before finally handing over to engineering. Each person is throwing the grenade over the wall, hoping someone catches it.

The important thing to point out is that the team is measured by their ability to provide a solution for the business, then to deliver it to engineering or the next team in line.

Related: The questions you need to ask developers before you start designing

Also:

• Projects are planned in a waterfall of activities, each handing over a deliverable to the next
• The engineering team is not consulted during the design phase, and the design team is not present during the build phase to assist with any compromises
• Change is difficult to accommodate
• There is a big disconnect between the designer and the product that ends up in the customer’s hands
• While the engineering team may operate in an agile way, the design team may not—no matter how many buzzwords like “sprint” are used

All this makes throwing grenades sound like a bad way to work. However, designers feel safe in this environment. They’re protected from the constraints of delivery and given the creative freedom to properly explore solutions. The results can often be amazing with really creative ideas and beautiful designs. The team will usually seek recognition through industry awards.

Feeding the beast

This stage is perhaps the most important of the 3. This is the stage that most agile design teams appear to be in or near, and it’s also where most teams start to struggle. Progress from here is often really slow and requires significant change. Feeding the beast is named after how this stage feels for the designers, working super quick to ensure the engineering team has everything they need to keep going.

The designers have broken from their team unit. They’re distributed amongst the agile delivery teams. Typically there will be 1 designer for as many as 8 developers. They will also work closely with the product owner for that team. The designer will sit with their teams and focus on delivering the designs needed for their team to build.

The designer on the team will work 1-2 sprints ahead of the rest of their team. They will take epics from the backlog. They will do the research and prepare the designs. In some cases, they will even write the user stories for the engineers, in collaboration with the product owner and the engineers. Then they will hand it over just in time for the engineers to build. They may even get involved with signing stories off once they’re ready to be shipped.

In this phase, the designer (not design team) is measured by their ability to deliver everything that the engineers need. They’re also measured alongside the engineers by things like velocity or cycle time. This adds extra pressure on the designer to keep the engineers busy.

Also:

• The designer will find it difficult to collaborate with the engineers who are focused on the current sprint’s delivery goal
• Things get built before they are ready simply because the designer simply runs out of time
• The process is incremental—not iterative—as the designer (and engineers) will move from one story to the next
• Change is accepted as part of the process, but it means the designer has to throw away a lot of work
• The team will debate—at some point—whether to include design in estimates
• It takes a strong leader to bring the distributed designers together as a team

When feeding the beast works well, it works really well and everything just flows. But when it doesn’t, the designer can often feel overwhelmed by the pressure—and the quality of design can be affected greatly. The worst example I’ve seen is when overwhelmed designers got too far behind the engineers. Features were completely built by the engineering team without input from designers. The designers were then asked to “make it pretty” just before the feature was shipped to the customer.

From my experience, most teams are in this stage. Most of them also appear stuck. I think this is because to advance beyond feeding the beast, a team must change the way they’re measured. For most teams, it’s really hard to see past design as a deliverables role. For the others, the barrier comes from the business and the way strategic decisions are made.

Moving beyond feeding the beast requires a culture shift in the organization. Allowing an experimental approach to creating products and emergent strategy to guide decisions on what to build. The design team must also accept a change in role and welcome design facilitation.

Design facilitation

This stage—for most agile design teams—is the dream. They read about it in books such as Lean UX by Jeff Gothelf and Sprint by the Google Ventures team. However, the reality of getting there is hard. I’ve named this stage after how I see the role of the designer evolve when teams reach design facilitation.

The designers are still embedded in small cross-functional teams, but the roles in these teams are less clear. Job titles are left outside the door. Teams are empowered to experiment using techniques like the Design Sprint and Hypothesis-Driven Development. They’re given direction by the business in the form of target for a Key Performance Indicators (KPIs). They’ll discover the right feature to build, then iterate over and over again to reach the target.

The designer on the team works right alongside the engineers, not ahead, as they did in feeding the beast. Rather than being created by the designer, the design evolves through the input of the whole team and the data collected from the customer. Therefore, the role of the designer has shifted. They are now the facilitator of the design. They lead the conversations and steer the team towards the results needed to achieve the team’s goal.

In this dream stage, the designer is measured and held accountable with their cross-functional team for the outcome observed rather than the deliverables or the act of shipping.

Also:

• Research is a core activity that the whole cross-functional team gets involved in and cares about
• Conversations and sketches replace most of the old design deliverables
• Designers will seek feedback from the rest of the design team but have the autonomy to make their own decisions, there are no gatekeepers
• Cross-functional teams are self-organizing, often creating their own “best-of” process
• Designer will also regularly design directly in code
• The team will develop a design system that enables them to iterate on the product at a much faster rate, while still being consistent and high quality

Examples of design facilitation are few and far between. Startups appear to be the most likely organizations to have a team that operates like this. It’s much harder for larger organizations to reach this stage, as it requires a significant and difficult culture change first. While some agencies are moving towards this stage, for most it is difficult to reach as it requires a shift in their business model. A rethink in the way they invoice for the work they do.

Throwing grenades, feeding the beast, or design facilitation. Which one?

Deciding where your team lives on this scale is easy—deciding where you want to be and getting there is tough. Each team has to find the best place—the stage that offers the most efficiency and the best morale for the team that in turn leads to the best end product.

The scale is just as much about the individual designers on the team as it is the team itself. The team can pick their point on the scale. But that’s related to the average of where the individuals in the team are on the scale themselves. There can be quite a difference between between designers on the same team. Also, the engineering teams and product owners have an impact, along with the culture of the organization.

Where does your team live on the scale? Let me know if you find it useful and if it helps move your team to a more productive and rewarding state.

This was originally published in UX Magazine.