What it means to be a cross-functional team, and what it doesn’t
The Scrum Guide emphasizes that Scrum Teams should be self-organizing and cross-functional. Guides, frameworks and methodologies aside, this is very sensible advice if you want to allow a team to discover the best way to do their job and work around (or through) obstacles.
But being a cross-functional team does not mean that everyone should be able to perform any task. Nor does it mean that there can be no specialized skills in a team, like design, development, testing, analysis or UX. These definitions share the assumption that teams are at their best when skills are (mostly) homogenously distributed.
This is obviously a fantasy in the real world. Most Scrum Teams consist of designers, analysts, developers and testers that have built up their skillsets through education, hard work and experience. It doesn’t honor these people and the work they’ve done to acquire these skills by assuming that teams can be cross-trained to perform any task.
And that is not what Scrum is about anyways. Scrum is about enabling teams to self-organize towards a process that maximizes their ability to frequently deliver working software and adjust their process based on the feedback it generates from stakeholders, customers and users. And anything that stands in the way of self-organization should be removed or reduced.
A team where members have unique skillsets (e.g. design, development, testing) will struggle to become Agile in that sense. If a member drops out (even for a day), a bottleneck might cause the team to become unable to deliver working software. A similar bottlenecks appears when the sprint turns out to require a lot more design-work than a (single) designer can handle. Or imagine that a (single) back-end developer gets stuck in difficult code and there’s nobody to help. The value of Scrum’s feedback-loop is lost in these scenarios because the team fails to complete any or all of the functionality pulled into the sprint. In addition, skill specialization often forces an inefficient process unto a team. A developer can’t create nice-looking pages when the designer hasn’t finished the designs, nor can the tester test functionality if the developers haven’t finished their work. The (necessarily) fast-paced nature of Agile software development does not allow us to sit around and wait for others to complete their work.
The solution is not a matter of absolutes; there’s nothing wrong with some degree of skill specalization. This is only natural. But specialization should not cause bottlenecks in the team’s process. One strategy might be to guarantee that important skills are present in multiple members. Or members can adopt pair-coding practices to share knowledge and teach each other how to perform certain tasks. Knowledge can also be shared through code reviews, knowledge sessions or blogposts and how-to’s on a company blog or Google Drive. Another approach is to use frameworks like Bootstrap or HandleBars to dissolve the boundaries between design and development. Why shouldn’t the designer set up a styleguide and allow the developers to create pages with this guide in hand? And why should only a tester be capable of testing functionality, when developers can write automated unit- and UI-tests?
The bottom-line is that a cross-functional team is better able to deal with (inevitable) disruptions than a team that is not cross-functional. But Scrum does not force, nor require, teams to equally distribute skills. Nor does it require teams to fight skill specialization tooth-and-nails. It does require teams to be wary of anything that can prevent self-organization from taking place, and a high level of skill specialization usually does.
