Every scrum team seems to have dedicated software engineers — people who write code only for that team. Most of these scrum teams have dedicated product owners or product managers as well. However, when it comes to designers the common practice, despite years of advice to the contrary, is to get them to cover as many scrum teams as they can. Designers I’ve met over the last decade are covering, at a minimum, two teams’ worth of design work and in the worst cases, aren’t dedicated to any team at all but instead work as an internal agency, doing whatever low hanging design task any team needs that day.
Here’s why this is a problem:
Context switching costs
It’s easy to believe that a designer (or anyone really) can easily switch between one team’s initiative and another without hesitation. This is blatantly wrong. Each time a designer has to switch from one team to another there is a minimum of 23 minutes of time to ramp up to the new initiative and a proven lack of overall productivity of nearly 40%.
Team dependency delays
It’s easy to assume that while the designer is off supporting another team, the other team(s) they support can move on with their work. The reality is that there are inevitable dependencies on the design work that person was going to do. Teams are left sitting around waiting for their designer to come back keeping user stories in limbo or in progress until the designer can focus back on their team. The worst case result here is that the team moves forward without the design work or farms it out to someone less skilled than the actual designer hired to do that work.
Designers caught between a rock and a hard place
This one is the worst casualty of not having dedicated designers on your scrum team. Let’s assume that a designer is covering three scrum teams. Every day that designer has to come to work and decide which two of the three teams she supports she’s going to piss off that day. Each of those teams has number one priorities but the designer can only work on one thing at a time. By distributing the designer’s focus across three teams they are now in the unfortunate position of disappointing their colleagues on a daily basis. How long do you think they’ll stick around if that’s the nature of their day-to-day interaction with their teams?
Design work — user experience, interaction, visual, copy writing, content strategy, information architecture, research, discovery all of it — is part of The Work of producing high quality digital products and services. We have a huge number of highly qualified folks ready to do this work. If it’s a priority at your company, hire enough designers to support each and every scrum team. Not only will your designers thank you, but your developers, product managers and customers will too.
I’d say scrum teams need dedicated developers, not derivated software engineers, designers or testers. What happened to T-shapedness? The reasons mentioned in the article are certainly valid, but to be a real team, team members should be able to step out of their traditional (engineer, tester, designer) role to help each other. That’s why these roles don’t exist in scrum, they’re all called Developers.
I mostly agree with your conclusion but for different reasons. Good design comes from deep understanding. Context-switching, the agency model, and other things that prevent a designer from developing that deep understanding lead to bad design.
(Here I mean deep understanding of the problems to be solved, the outcomes to be attained, and the people to be served by the designs.)
That said, a good designer – especially as they become more senior – develops ways of creating and retaining that deep understanding. Once they have attained a level of understanding it is possible to split your designers across multiple teams. Senior people also learn how to manage their context switches better. We all pay a cognitive price for context switching but you see senior people taking steps to mitigate those costs by increasing their delivery estimates accordingly, setting aside focus time, etc. Junior people don’t generally know to do these things and deliver worse design as a result.
All IME, of course. Other people may have different experiences.
This article assumes poor planning, poor communication, and delivery management – all easy to fix.
It also assumes big teams and big projects. I struggle to understand how you will justify dedicated designers and architects to small teams and small projects.
Agile ways of work are big on flexibility, adaptation, fast learning, and unlearning. Not all people are designed for Agile ways of work. Context switching costs are higher in a low maturity Agile environment and with coaching, mentorship, and diligent planning it is not hard to mitigate these problems if you have the right people allocated to the right teams and projects.
At the end of the day, resource allocation is an economic decision so I would allocate resources in a manner that gets me the most value out of the investment and the most output from the team.
Agile ways of work promote operational excellence and optimal resource allocation and sequencing is part of that culture. All these competencies are trainable and coachable.
Maybe the article should have included some assumptions that drove the position taken.