Agile: 20 years on and still no “Designers”?
In February 2001, 17 visionary developers met in Snowbird, Utah to ̶g̶o̶ ̶s̶k̶i̶i̶n̶g̶ ̶o̶n̶ ̶c̶o̶m̶p̶a̶n̶y̶ ̶m̶o̶n̶e̶y̶ create the Agile Manifesto for Software Development. Today as the whole software development and engineering community unites to commemorate this remarkable event, it feels less of a celebration for the design industry because let’s be French about it: there’s still no sign of designers in any Agile frameworks or Agile tools.
Design in Tech is a must not a should
Few digital teams would question the value of good design today — every time a user flicks open Monzo on their iPhones they’re enjoying the beautiful synergy of thousands of hours of hardware and software optimised for a pleasant and effective banking experience.
“If you think that good design is expensive, you should look at the cost of bad design.”
- Dr. Ralf Speth CEO Jaguar Land Rover
However, way too often we shrug when asked how these skills should be embedded within our Agile teams. Even in the full glory of the many roles itemised in the SAFe framework, there’s no formal role declared for designers, even whilst many of the artefacts and techniques mentioned clearly require their involvement (Design Thinking as a topic has even been formally integrated in recent versions). So whether you’re an organisation of thousands attempting to scale Agile, or just a single team operating with agility — where do designers fit in and how can we embrace good design alongside agility?
Design is a team sport
Good Design is as much about what is being produced as how things get done. With an unfair ratio of on average 1 designer for 12 engineers in large digital transformation programmes, it seems inevitable that designers are seen as the bottleneck hindering the velocity of engineering teams. Realistically though, there’s not going to be any silver bullet and if you want to improve the quality of your products you’re going to need to 1) increase the number of designers to reduce the ratio gap, 2) upskill the other members of the team so that building with empathy towards end users and caring about the quality of the experience becomes everyone’s mission.
However, emerging practices like DesignOps help offer an anchoring approach to enable this — encouraging both investment to identify ways to scale the design impact and the designer’s value across the product development cycles:
- Adopting the correct mindset (like any team sport)
- Creating shared values
- The whole team must be bought into a single goal, and share in its success (or failure!)
Avoiding peak overload — building slack into your system
The emergence of Team Topologies and related thinking has useful shined a light on the need to focus on the whole team as the most important unit — and this must include our designers. Cognitive load is a critical concept for all creative problem solvers, including developers, and particularly crucial in order to build in the space to think which is integral to the design process.
When assigning responsibilities or software parts to a given team, we hardly ever discuss cognitive load. Perhaps because it’s hard to quantify both the available capacity and what the cognitive load will be. Or perhaps because the team is expected to adapt to what it’s being asked to do, no questions asked.
Matthew Skelton and Manuel Pais https://itrevolution.com/cognitive-load/
In a healthy team running Scrum for example, the cadence of ceremonies and ‘protection’ of the team designed to preserve this space and focus to allow the team to work effectively and avoid burnout. When we factor design into equation, this is even more important. The challenge of whether design can be effectively contained within an active sprint leads us to an important choice (for both routes can work) about whether designers can work most effectively in your team as primarily an extension of the pre-delivery Product aspect, or as part of the cross-functional delivery team…
Embedded in Product: The designer as (mainly) pre-sprint
Viewing the Designer as sitting mainly in the Product Ownership domain can work well for some teams, particularly in larger and more complex organisations where having a firm focus on design before the delivery process (“pre-Sprint” if using Scrum) can help in:
- Aligning requirements and approach across multiple areas (e.g. an identity platform which acts across multiple apps and services offered by and organisation)
- Building a common body of practices and approaches across areas (e.g. ensuring a shared approach to accessibility across different domains)
- Investing time in discovery, user, and market research where design skills are useful in defining the problem statement and potential approach to solutions
Jeff Patton describes some common approaches for this complimentary approach, and avoiding unintentional conflicts in his writing on Dual Track development:
If design capacity is limited, it may be possible (though it’s probably not a great long term fix) to use this approach to spread a positive design influence across more teams. Taking the designer out of the delivery capacity also moves (though not removes) the challenge of trying to work out how design capacity and creativity impacts planning.
Drawbacks of this approach worth considering mainly stem from needing to avoid siloing and accidental waterfalling:
- Overall lead time needs to be tightly monitored to ensure discovery doesn’t end up extending too long — e.g. 3 month “design sprints”
- (as with the PO) need to actively invest in how to ensure collaboration and connection with the team
Embedded in delivery: the designer as part of the cross-functional team
For some teams, it makes more sense to embed designers as part of the cross-functional team — you’ll find them annoyingly under the term “developers” in Scrum Guide terms. This approach encourages both designers and other members of the team to broaden their skill-set and “T-shape” — e.g. designers beginning to actively contribute to some areas of development and/or testing.
The cost of this approach is essentially the flip of our discovery-centred designers above — when your head is focussed in nuance of individual user stories, it can be easy to miss the bigger picture and knit together individual features and functions into a compelling end to end experience. In this anti-pattern, we can end up accidentally designing for tickets rather than for whole services that our users can really grow to love.
Design needs to learn from the data-led world of engineering
Whilst OKRs and KPIs are fantastic approaches to defining and measuring the outcomes of our product teams overall, measuring the effectiveness of the designers itself can be a challenge with too many variables to wrap formal numbers around. At least until a fancy AI bot offers a solution, it’s difficult to conceive a way that the “Design debt” of wasted hours spent on solutions that might never see the light of day might be measured and optimised. In the meantime, a practical solution is to focus on how to creative a culture where the Minimum Viable Design is encouraged in order to validate hypothesise and encourage iteration. As well as measuring the outcomes of a given hypothesis, related output measurements can be used to help encourage teams to balance how much design goes in up front before work begins:
- Reaction time (and hence Lead time) — measure how long work items during all pre-delivery stages, including design. Lead time and cumulative flow charts can create simple automated ways to measure these critical timings.
Don’t try and target unreasonably fast times — designers aren’t machines, and as we’ve said — they need time to think.
Do monitor averages and have a discussion around outliers and overall trends — is there a pattern in which items take a long time to design which points to some improvements? - “Returned for input” — how often does work come back for more input because up front design and discovery wasn’t sufficient?
- Reusable insights — designers during a sprint might unearth valuable findings that could be useful for another sprint. How do we store, share and measure that type of value across multiple sprints?
For further thinking around how metrics can work for design, InVision and others have produced detailed guidance here, and there’s a host of other writing to explore…
So what?
Has this article hit a nerve or triggered some thoughts? Here’s the key messages we’d like you to take away and try…
- Embrace the chaos of exploration and experiment — build psychological safety around expecting creative and design to need space
- Culture needs a catchup –Ensure you are actively investing the same attention and respect to those with design skills
- Creativity be manic, but your team doesn’t need to be — build slack into the system, and respect the load you place on teams to leave room for humans
- Every do’er is a designer and design is a team sport, the responsibility of everyone is to create experiences that delight and serve our users/deliver real value
This article was collaboratively iterated with Kit Friend, but the funny and insightful bits are mainly Marion — Kit
