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 organisation 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.
I believe that all design teams follow the same journey as they adapt their practice to an agile workflow.
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 organisation is on the same journey. They all recognise where they are on the journey, and the steps they have been through. There is also great interest in knowing where other teams are on the journey, as well as identifying the right steps to move forward.
I have 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 three distinct stages, starting at ‘Throwing grenades’ through ‘Feeding the beast’ and eventually getting to ‘Design facilitation.’ No two teams are exactly alike, so the scale allows for room between the three 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 organisation 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.
The effectiveness of a team depends on how it is measured
It is also possible for a team to move backwards on the scale for various reasons. Those reasons could include things like: organisation 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 is not a bad thing. Teams have to find what’s going to be the most effective way for them to work.
The scale is not intended to measure how effective a team is—it is intended to highlight a common journey experienced across the industry. The effectiveness of a team depends on how it 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 is 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 will 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.
UX and UI designers collaborating at Envato
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.
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 very 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 buzz words like ‘sprint’ are used
All this makes ‘Throwing grenades’ sound like a bad way to work. However, designers feel safe in this environment. They are 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 three to mention. This is the stage that most agile design teams appear to be in or near. This is 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 designer will sit with their teams and focus on delivering the designs needed for their team to build.
The designers have broken from their team unit. They are distributed amongst the agile delivery teams. Typically there will be one designer for as many as eight 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.
Distributing designers using the tribes and guilds method
The designer on the team will work one or two 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 are 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 are 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. However, when it does not, 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.
To advance beyond ‘Feeding the beast,’ a team must change the way they are measured
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 are 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 organisation. 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, 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.’
Job titles are left outside the door
The designers are still embedded in small cross-functional teams, but the roles in these teams is 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 are given direction by the business in the form of target for a Key Performance Indicators (KPIs). They will discover the right feature to build, then iterate over and over again to reach the target.
The designer in 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.
Design war room
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 which the whole cross-functional team gets involved in and care about
- Most of the old design deliverables have been replaced by conversations and sketches
- 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-organising, often creating their own ‘best of’ process
- Designer will also regularly design directly in code
- The team will develop a design system which enables them to iterate on the product at a much faster rate, while still being consistent and high quality
Envato’s design system
Examples of ‘Design facilitation’ are few and far between. Startups appear to be the most likely organisations to have a team that operates like this. It is much harder for larger organisations 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 quite easy, but deciding where you want to be and getting there can be quite difficult. Each team has to find the best place for them. 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 is 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 organisation.
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 article was first published on UX Magazine: The Agile Design Team Maturity Scale