Shared roles in Scrum

I am working with two teams from different clients right now that are both struggling with the concept of swarming and cross-discipline work.  Each of these teams have team members that are experts in their own area, but run the spectrum from not comfortable to just plain don’t understand the other technologies or practices that the team needs to accomplish the work.  The result is that both teams are struggling to get stories done because of the lack of ability to focus on just one or two stories at a time; since many team members would ‘have nothing to do’ and others are overworked.  One of the primary focuses that we have for improvement is to learn to swarm on stories and begin the cross-discipline training.

It seems that the general philosophy in agile coaching today is that every member on a scrum team should be able to do anything needed to complete the feature.  I disagree with that hard and fast interpretation, and the Scrum Guide also does not support this concept.  Summarized, the guide states that all disciplines needed to complete the work need to be on the same team, not that all team members need to do the same work.  (Scrum Guide, pg 4 ‘The Scrum Team’).  Self-organizing means the team figures out how best to get the work done, which includes who best to do each portion.  However, the guide does stress that “The team model in Scrum is designed to optimize flexibility, creativity, and  productivity”.

I think the statement that really started the “everybody does everything” mentality was this:

·         Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;

But then those same people skipped over this:

·         Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

I was at a conference a couple months back and heard Jeff Patton give an analogy that I plan on re-using in the future to help with this misconception. Essentially, think of your scrum team as a football team. (North American Football for you euro’s out there). In football, you have specialized skill sets that are pretty ingrained; for example an offensive lineman

is good at his job because of his specific physical and mental attributes, which are very different from a wide receiver's. However, on a given play, each of the 11 players on the field knows not only their role, but the other player’s roles as well, and could perform them if needed. A wide receiver can stay in and block, but they are not as good at blocking as a lineman or tight end.  A lineman can go out for a pass, but they are not as fast or as good at catching a pass as a receiver.

    (I challenge you to remember a time that you saw a 320 pound lineman streaking down the sidelines after making a fingertip catch?)  The point being that each player knows their own role innately, but as needed they can jump into other roles as appropriate to move the team forward.  However, when they jump in to those areas there will be a degradation (usually slight) in efficiency.  That loss of efficiency is more than made up for by the elimination of the queue that would otherwise form at the other team member’s feet. 

Applying this to a Scrum team, the reality is that each member has their specific skill set.  I cannot take a software developer that is really good at their craft, and move them into testing and expect them to be just as good as a well-trained experienced software tester, nor vice versa.  Each of those roles takes years to develop the specific skill sets needed to be an expert in that area.  I can, however, expect them to know each other’s roles well and be able to jump in to any role as the team needs them to so that the work can be completed.  If I need the wide receiver to block, he/she should not only be willing and eager, but understand enough of the technique to be successful.

This does not mean that there are no more experts.  Through pairing and other practices you are going to help share understanding and skills about using the testing and development tools and how to function within them, but it would take years of pairing to share each and every experience that has made each team member valuable in their own expertise.  (Having been a developer for multiple decades I know this first hand).  Many (most) developers or testers have gone into their field of expertise because that is what they want to do; forcing them all to be a homogenous pile of goo that can ‘do anything’ is not practical. 

The reason we as coaches teach and preach about cross functional teams and ‘everybody doing everything’ is to avoid the major downfalls of mini-waterfall (those dreaded queues again) and to increase collaboration and shared ownership.  Queues are what slows down a team because of the inherent wait states built into most (all) queues.  (Google queue theory or read Rienertsens excellent book “Principles of Product Development Flow”).   The delays built into queues are one of several key factors that slow down waterfall development and make it inappropriate for most software projects.

Collaboration is key to any agile team’s success, but making the blanket statement that no one can be a developer or a tester (having a primary skill set) is short sighted.  The tricky balance is building the collaboration while still allowing the efficient part of each team member doing what they are best at.  The best practices I have found, and the ones I plan on introducing with my current team, is to break the work up into small enough chunks, and keep the focus on only a story or two at a time within the sprint.  This tends to force the right balance of “that’s my skill so I’ll take that” with “I have nothing else to do in my skill area, so I’ll jump in to this other area to get this story done” mentality.  Back to the football analogy, I’m going to ask the team to run one play at a time, let them focus on that play and allow them to do what they are best at, but if the team needs the wide receiver to throw a pass to the lineman to score, then so be it.  But that offensive lineman is still an offensive lineman, and is needed to make a true team.