There is a line in the latest (2011) Scrum Guide that says:
This statement seems to have been be misunderstood by some who interpret it to mean that Scrum prescribes that there should be no specialisation within the team (see for example this blog post and the description of the Team here). Also, that every individual team member must be a highly cross-functional generalist as an individual including being able to contribute code.
That is not, however, what is meant.
This is not the only terse statement out that may give people the wrong impression either. For example, the previous versions of the Scrum Guide, e.g. the original March 2009 edition, reads in part:
“Teams are also cross-functional; Team members must have all of the skills necessary to create an increment of work.”
Upon first read, you might think this is saying that “individual Team members must have all of the skills necessary to create an increment of work”. But, could it not also be suggesting that “Team members as a collective must have all of the skills necessary to create an increment of work”? Unfortunately, what the latest (2011) version of the Scrum Guide omits is the following, longer and more explicit explanation given in the 2009 version.
“Team members often have specialized skills, such as programming, quality control, business analysis, architecture, user interface design, or database design. However, the skills that Team member share – that is, the skill of addressing a requirement and turning it into a usable product – tend to be more important than the ones that they do not. People who refuse to code because they are architects or designers are not good fits for Teams. Everyone chips in, even if that requires learning new skills or remembering old ones. There are no titles on Teams, and there are no exceptions to this rule. Teams do not contain sub-Teams dedicated to particular domains like testing or business analysis, either.”
– Scrum Guide, March 2009
The intent here really hasn’t changed since the Black Book written about 10 years ago now.
“There are no titles on teams. Teams self-organise to turn the requirements and technology into product functionality. This type of stateless, ego-less, development team is flexible to address any work that arises. Scrum avoids people who refuse to code because they are system architects, or designers. Everyone chips in and does his or her best, doing or learning how to do what is needed. Scrum Team members don’t have job descriptions other than doing the best possible.”
– Agile Software Development with Scrum p.38
One of the most recently published books on Scrum puts it as follows.
“In general, people can either be specialists or generalists, and the Scrum Team may be made up of both.”
– Exploring Scrum: The Fundamentals
Actually, I would add that pure-play specialist and jack-of-all-trades generalist are two extremes. To consider these cases only is to miss the shades of grey in-between and leads to black and white binary thinking. How many experienced specialists do you know that cannot do a single thing to do with software development outside of their specialisation? Consider this statement: “I’ve spent several years specialising in testing and am happy work with the Product Owner and Subject Matter Experts to analyse requirements and identify functional scenarios / test cases. I have written Visual Basic code some years ago and, if needed, could write basic automation scripts in Ruby – once I come up to speed with the syntax. I’m familiar with SQL and can create test data configurations as needed too.” In reality, people have a variety of skills and knowledge levels in a variety of areas beyond what a specialisation pigeon holes them into. Any gaps can be overcome by being resourceful whether that be a little online research or pairing with a colleague.
In general, having at least some team members with the sort of flexibility described above makes for a team that is more resilient to the challenges of variable demand and bottlenecking that are key to high performance in a complex software development environment. Always having the specialist do the job because they may be quickest is not necessarily going to optimise throughput when the specialist is already full to capacity with work. For some strategies for the team to consider on how to managing their work distribution with this in mind, see Bas Vodde’s excellent article on the Scrum Alliance website.
The central point here is that there is a big difference between people who use their specialisation as an excuse or justification for not helping-out outside of their specialist focus… and…specialists who happily pick up tasks outside of their niche when they have sufficient skills and when needed to help the team achieve its goals.
Having team members who volunteer to help-out outside of their specialist area when needed is not a pipe dream. When I think of all the software development groups I have worked with, I could identify at least one in every team I’ve seen. This is the sort of person many might describe as ‘dynamic’. They might have spent years specialising in Java programming but they are someone who, in a group situation, moves seamlessly between discussions of analysis, high level design, technical design, testing strategy, team process and development practices with equal enthusiasm. Someone who follows-up discussion with hands-on investigation and work in all of these areas and more as necessary, without hesitation. To this sort of dynamic team member, all of these aspects are part of the story of developing software and often they are linked. To them, it makes no sense to put waterfall-based boundaries around different portions of the end-to-end process. Saying to such a person that “you should only talk about technical design and defer all asking of questions about requirements to our BA” would seem like introducing artificial and unnecessary boundaries that greatly hinder their ability to get things done (and get to “Done”).
Don’t assume that the dynamic team member does everything themselves though. I’ve been lucky to work with a number who are wonderful team players. Being asserting and initiating a discussion at a whiteboard when they need to, consulting their peers and listing carefully, inviting others to contribute and, importantly, knowing their limitations and being vulnerable enough to say “I don’t know much about this area, who can help?” This is the sort of dynamic team player we are keen to cultivate on agile teams. With deep knowledge in at least one area but willing and able to step-in to help out in other aspects of software development. Perhaps not to the same level of excellence or speed for all tasks but, through collaboration with other team members (e.g. pairing) able to pull things together and get the job done.
Does that seem like the sort of team member you would like more of?
What do you think? Myth busted? To have your say, add your comments at the bottom of the blog post.
For more on this, see the following articles by well-respected authors.
Bas Vodde: excellent article on the Scrum Alliance website
Mike Cohn’s article on agile teamwork
Mike’s recent post reflecting on the rise of “Hyperspecialisation”.
Clinton Keith’s post: Scrum prohibits all specializations?
…and the follow-up: More on specialization
If you would like to learn more about the basics of Scrum, feel free to check out my introductory Scrum Master Course.
