Can a Development Team member work on more than one team at a time?
In my last post I used the metaphor of a rowing team to describe the potential implications of having more than one Product Owner per product. In this post, I’d like to use a similar metaphor to show what might happen if a Development Team member works on more than one team at a time. It’s one of the most asked questions in every Scrum training.
Here's the metaphor
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 Development Team, and the person facilitating rhythm is your Scrum Master.
Imagine the Development Team members 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 members of a Development Team on more than one 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 Development Team member 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 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 Servant Leader stance to take. Your options range from observing if and how the Development Team self-organizes to solve this, to taking action and removing what has become an impediment to the progress and success of the 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 a Development Team, 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.