One of the principle practices in Scrum (and in fact most, if not all, agile methods) is the use of “cross-functional” teams. Somewhat surprisingly, there is often resistance at the team level to creating these cross-functional teams, but sometimes this is a result of misunderstanding what we mean when we say that a team is cross-functional. I have even encountered some practitioners and coaches who seem to misunderstand what a cross-functional team is (or should be). In other cases, it is the organizational culture that prevents teams from being cross-functional.

Key to the success of any development effort (regardless of our plan of attack) is that the team charged with doing the work has all the skills and resources it needs to complete the goals set before it. This, ultimately, is what it means for the team to be “cross-functional.” A colleague of mine, Michael James, CST, remarked, “Cross-functionality means the team has a wide range of skills, not necessarily each individual. We ran into this…where people thought we wanted UI designers to learn Java.” I couldn’t agree more both with Michael’s definition of cross-functionality and the misunderstanding amongst team members of what cross-functional means.

While it would be terrific (maybe) if every team was composed of people each of whom was equally facile in every discipline required (e.g. UI, middle tier, testing, business analysis, etc.), no team is ever staffed entirely with such people. There may be one or two Jacks (or Jills) of all trades, but most people specialize based on their background, unique individual skills, and personal interests. This is actually an advantage because, generally, a Jack of all trades is a master of none. Specialists have a deeper knowledge and understanding of their particular discipline than a generalist. Additionally, as Michael said, cross-functional teams don’t require that each person do every job or even be capable of doing every job. Rather, cross-functional teams only require that the team as a unit has all the skills necessary to do the job.

Now obviously another principle at the heart of Scrum is the team “swarm mentality” (i.e. the team working as a unit to accomplish some goal). In order to do this successfully, team members will have to help out other team members by doing things outside their specialty. While the “it’s not my job” mentality is certainly an impediment, the important thing is that the team itself decides how to apply the resources and skills it has available and who is going to help whom (and how). Nothing undermines team effectiveness and morale more than trying to force people to do things they are either not comfortable with or not capable of doing. A really superior UI designer may be lousy at writing Java code (to steal Michael’s example) and vice versa. Making him or her do so under the auspices of “cross-functionality” is detrimental to the team and a perversion of what it means to be cross-functional.

One other obstacle we sometimes see to cross-functional teams is poor communication or, worse, dysfunctional communication because of “disciplinary ghettos.” If people are split up by discipline either by organizational hierarchy (e.g. all testers report to the same functional manager) or by physical location or both, the natural result is a deeply ingrained culture of “us versus them” between the disciplines. The waterfall further engendered this mentality by allowing, if not encouraging, each discipline in the chain (analysis, design, development and test) to throw its work over the wall to the next group. While this is not always the case, in many organizations it is an issue. This ghetto mentality is often hard to change and some people will resent the attempt to take them out of the comfortable environment of their main peer group. The best way to get around this, at least when an organization is first transitioning to an agile method using cross-functional teams, is to get volunteers for a “pilot” Scrum team to serve as a sort of proof of concept for the rest of the people in the organization. The infectious enthusiasm of a functional and willing Scrum team is contagious and even those who initially may have opposed the idea can be turned around by witnessing first hand the benefits of being on such a team.

Jimi Fosdick
CST