Scrum Agile Project Management

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 some 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 requires specific expertise only for a limited amount of time. How do you deal with it? In his book “Scrum Shortcuts without Cutting Corners”, Ilan Goldstein discusses the question if a software development specialist can be member of multiple Scrum teams.

How To Work Past People Resistance to Becoming T-Shaped

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