This is a common question in my Professional Scrum classes. It often comes up early when we are still learning the basics of the Scrum Framework. And it comes up because people are already splitting their time between multiple Scrum Teams or are being told by their organizations that they will be.
The short answer is: Scrum does not have a rule against people being on multiple Scrum Teams. This is left up to you to decide what is best in your context. The longer discussion involves answering the question: Can you effectively be part of multiple Scrum Teams and should you?
This situation can arise from being a project-focused organization rather than a product-focused organization. Or perhaps there is not a strong enough desire to break down skill silos. Often I see both. Essentially, people get split across multiple Scrum Teams because they have specialized skills, people are still working in a waterfall way within Scrum Teams, and the organization is not making the tough decisions about product value and alignment to organizational strategy and goals.
To answer our bigger question (can you and should you), let’s explore the 4 most common challenges I see when an individual is part of multiple Scrum Teams.
Challenge #1 – Increased complexity for communication and collaboration.
By not being focused and committed to one Scrum Team, the individual must make choices every day about which team to spend their time with – how much time and when to be available. This increases the complexity of communication and collaboration for all Scrum Teams impacted.
Challenge #2 – Loss of productivity and quality issues.
Furthermore, the individual must switch context when they stop doing one activity and pick up an activity for another Scrum Team. Humans don’t multi-task; they task-switch. And this will always lead to a loss of energy and time while stepping into the new context to remember where they left off and what they need to do now.
I often see that this situation leads individuals to feel pressured to work beyond a sustainable pace. And this can lead to quality issues. People make mistakes when task-switching, and this is exacerbated when pushing beyond our physical capacity.
Challenge #3 – Delays in value delivery.
Increased complexity, loss of productivity, and quality issues all contribute to delays in value delivery. Stuff gets started, but it doesn’t get finished – at least not as early as it could be finished. Little’s Law tells us that the more things that you work on at any given time (on average) the longer it is going to take for each of those things to finish (on average).
It can be challenging for a Scrum Team with fully dedicated team members to minimize their work in progress (WIP) and focus on improving the flow of value through their process. The challenge gets even bigger when people are working on multiple teams. It just seems easier to pick up something new when you are waiting on someone to be available.
Challenge #4 – Low morale.
All of these challenges are likely to lead to low morale. The individual who is pulled in multiple directions may feel that they are letting down their team(s). Perhaps they feel they are not doing their best work. And this situation may be impacting other parts of their life. There may be a point where they feel disrespected by the organization.
Even the other team members can experience low morale because they have empathy for the individual splitting their time across multiple teams, and they don’t want to feel like they are adding to the pressure. They can also feel frustrated with the situation because they know they aren’t achieving what they are fully capable of as a team.
So should you and can you? First, have an open discussion about these challenges. And then ask yourself why you want someone to be part of multiple Scrum Teams. You may find the 4 questions approach described in this post helpful.
Is it to avoid the challenges of breaking down skills silos, learning to work in a new way, or making the tough prioritization decisions across an organization? This is pointing you towards the underlying problems to address. If you have uncovered other reasons that feel valid and important, then perhaps this makes sense in your context and is worth trying. Be sure to frequently discuss how well this is working.
Is there sufficient focus? Do people feel respected? What are we committed to as organization? Do the best you can to set individuals, Scrum Teams, and organizations up for success.