Blog
Can Developers work on more than one Scrum Team at a time?
"Can Developers work on more than one Scrum Team at a time?", is one of the most asked questions about Scrum, and we’d like to use a metaphor to answer it:
Imagine your Scrum Team is the crew of a rowing boat. There’s the person holding the rudder, the people at the oars and the person helping everyone create and maintain rhythm. The boat is your Scrum Team. The person at the rudder is your Product Owner. The people doing the hard work of rowing are your Developers, and the person facilitating rhythm is your Scrum Master.
Imagine the Developers really putting their backs into it and doing their best. You can feel their focus to meet the Sprint Goal.
Working on more than one team?
Now, imagine one of the rowers has to switch boats and join another crew. Take a minute and think about what that might mean for the crew and their boat. Picture it before you read on!
Does your mental picture look like this?
The Scrum Framework doesn’t say you can’t have people working on multiple teams. So, it might be tempting to “optimize” staffing by having some Developers on more than one (Scrum) team.
What’s the problem here? It just takes a bit of careful planning, you might think. For example, have the person row on boat #1 on Monday, Wednesday and Friday and on boat #2 on Tuesday and Thursday.
I’ve seen varying degrees of this ranging from people working on two teams to eight teams at a time. It never worked well for any of the teams and contributed to a whole host of undesirable consequences: Teams didn’t reach their goals, customers didn’t get the value they expected, stakeholders lost trust in the teams, people hurt their careers and companies had to cut products and jobs. The effects on motivation, morale and well-being were devastating.
It’s important to understand that this doesn’t just affect Scrum Teams. These effects happen on any team regardless of their approach. Scrum just makes them more visible. Don’t confuse symptom and cause.
Here’s why it usually doesn’t work out
Your Scrum Team isn’t just an ordinary rowing team on an ordinary rowing boat. They’re more like sailors who explore uncharted territories and travel unknown seas.
Just like those sailors, your Scrum Team has to deal with lots of unknowns that affect their plans. Both teams can plan their Sprint Backlogs in a way that a Developer will be needed only on certain days. However, when things are complex, teams will have to inspect and adapt their plans often in order to reach their Sprint Goal. What was expected to be little work turns out to take longer and isn’t ready to be picked up by the Developer yet. What was expected to be a lot of effort is now waiting to be completed. Things change. If only the Developer was available now. How efficient is the “optimized” staffing now?
So, what does this mean?
Scrum encourages teams to work as a unit and focus on one Sprint Goal and Product Goal at a time. That’s when the principles of self-organization, cross-functionality and empiricism can deal with complexity best. This is also where the Scrum values, especially focus, come into play.
As a Scrum Master in this situation, you need to decide which leadership stance to take. Your options range from observing if and how the Developers self-organize to solve this, to taking action and removing what has become an impediment to the progress and success of the Scrum Team. This metaphor might help you create a shared understanding of the potential intricacies of having a developer work on more than one team at a time.
As Developers, you would ideally solve this situation yourself, and there are many conceivable solutions to this challenge. However, if you can’t solve it and it gets in the way of your work, ask your Scrum Master for help.
So you want to learn more about Scrum?
We hope that this story has given you valuable insights about Scrum. If you want to learn more about Scrum, our professional Scrum training might be a great start:
learn more!
