Sharing Team Members in Scrum

We all know that there are three roles in Scrum teams : product owner, scrum master, and the development team. Modern software development can sometimes require a high level of specializations that could be beyond the capabilities of the Scrum team members. UX and Web design, database administration, performance testing are some examples of activities that require specific expertise only for a limited amount of time.

How do you deal with it? Can you share team members across multiple scrum teams? In his book “Scrum Shortcuts without Cutting Corners”, Ilan Goldstein discusses the question if a software development specialist can be a member of multiple Scrum teams.

In the previous section, I mentioned a 50 percent allocation for deep specialists. This “fractional assignment” is not overly popular across the Scrum community, and for good reason. James Shore and Shane Warden, authors of The Art of Agile Development (2007), put this down to the fact that “fractional workers don’t bond with their teams, they often aren’t around to hear conversations and answer questions, and they must task switch, which incurs a significant hidden penalty.”

I totally agree that ideally you want all team members dedicated 100 percent to the team. That being said, I have often found it unnecessary (from a requirement perspective) and unrealistic (from a budgeting perspective) to have deep specialists, such as database administrators, dedicated full time to a development team. That doesn’t mean I disagree with Shore and Warden, nor does it mean there aren’t occasions when you certainly need full-time deep specialists; however, it does mean that we often have to make the most of the skills available, and in many situations, we don’t have the luxury of full-time deep specialists.

As a sort of consolation prize to the purists reading this book, I point out that although I am not against splitting developers across two projects, I am adamant that no one should ever be split across three or more projects – that level of context switching becomes very counterproductive.

Another option that you might like to consider, especially if a deep-specialist is required to work on more than two projects at the same time, is to treat them as consultants and trainers for the rest of the team. So, instead of including them as part of the actual Scrum team, they are shared across multiple teams and assist on specific tasks while at the same time educating the other developers.

Reference: Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools & Tips, Ilan Goldstein, Addison-Wesley

Here is a list of articles dealing with the fact of sharing members across multiple Scrum team:

Can People Be on Multiple Scrum Teams?

Extract: “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.”

Can Developers be on More than One Scrum Team?

Extract: “Scrum does not explicitly prohibit individuals from being part of more than one Scrum team, but it’s essential to consider the potential impact on productivity and adherence to Scrum values. Task switching can lead to reduced efficiency, and spreading focus across multiple teams can challenge the value of commitment and focus. Ultimately, the goal should be to create an environment that supports the principles of the Agile manifesto and values of Scrum. For the best thing to do in your specific context… ask the team”

Ask an Agile Coach: What Team Members can be shared across multiple Scrum teams?

Extract: “The undesirable result of this variation is an unstable velocity and increased carryover of user stories in sprints. This in turn erodes the reliability of planning and estimation activities. The team shows itself to be unreliable and unable to deliver on commitments, eroding confidence and trust with stakeholders and management. The primary risk with sharing team members is that Scrum Masters and management often do a poor job of accounting for how those peoples’ time is allocated and managed, which inflames the symptoms described above.”