The Scrum Team is cross-functional

The Scrum Team consists of a cross-functional or multidisciplinary set of people who together have all the knowledge and skills needed to conduct the end-to-end product development work. As such, its members together are able to perform any type of work that is necessary to implement the product’s features, creating one or more releasable Increments in each Sprint (see the chapter Increment).

In addition to all the tasks of building the product itself, this work is likely to include the use of quality assurance methods, creating one or more types of documentation, defining, and understanding the business details, ordering of the work items to generate the next greatest value and actual application of the Scrum framework and different agile techniques, among others.

The Product Owner continually makes decisions about defining the product, which includes ordering what will be implemented. She therefore has the knowledge and skills to do so. The Scrum Master is responsible for facilitating interactions between Scrum Team members, teaching Scrum to those he deems relevant and acting as a change agent, among others. He should therefore possess the knowledge and skills to do that. Among the Developers of a Scrum Team, there is no distinction between accountabilities. Together they are accountable for implementing one or more done Increments according to the Definition of Done and according to what was established together with the Product Owner for each Sprint (see the chapter Commitment: Definition of Done). The Developers therefore jointly possess the knowledge and skills necessary to conduct this work.

To be part of an Increment, each Sprint Backlog item should be done in the Sprint, according to the Definition of Done. For this reason, the Definition of Done is decisive to defining the work to be performed and is thus directly linked to the knowledge and skills that the Scrum Team members have.

Note that the recommended size for a Scrum Team is small, with ten members or less (see the section The Scrum Team is small in the chapter How is the Scrum team?). Nevertheless, all the knowledge and skills needed to develop the product should exist among the members of this team.

Also, the cross-functionality of the Scrum Team does not imply the cross-functionality of the individual. This difference becomes clear when dealing with the Product Owner and Scrum Master, who have well-defined accountabilities. But the same is not true among the different Developers, who share their work with equal accountability. Scrum, therefore, does not require each Developer to have all the knowledge and skills needed to develop the product – that would be utopian – but rather that they have them together. It is natural for people to have their specific specialties, knowledge, and areas of interest.

Cross-pollinated

Working with Scrum generates accountability for the realization of the Sprint Goal to the set of Developers, and not to certain individuals. In this way, Developers are constantly stimulated to work together, exchange knowledge, seek to learn what is necessary and thereby develop secondary skills.

This “cross-pollination” reduces reliance on the specialties of certain Developers, decreasing the risk of queues and waits that threaten the achievement of the Sprint Goal. The absence or imminent overload of an individual at a given moment, for example, is less likely to become an impediment to the group’s work, as there will usually be others at least minimally capable of performing the work or assisting in carrying it out.

Sharing knowledge also reduces the chances that, at certain times, some Developers may run out of things to do and therefore try to work on lower-order items within their comfort zone, or even find themselves having to work on more than one team at the same time. An expert who only knows about quality control, for example, would face this problem, as this person would only have work at specific moments during the Sprint.

With cross-pollination, it is also common for Developers to learn facilitation techniques from the Scrum Master and business skills and knowledge of the product from the Product Owner. It is equally common for both the Scrum Master and the Product Owner to acquire some technical – albeit basic – knowledge from their interaction with the Developers.

Learning oriented

In general, we expect that a significant part of the necessary knowledge and skills will already exist among the Scrum Team members from the moment they are selected and the team is formed. That is, we seek to assign a new product to be developed to a Scrum Team that is capable of carrying out the work. Notwithstanding, new challenges that may require new learning can naturally arise throughout the work and this is true for both the Developers and the Product Owner and Scrum Master.

The way knowledge and skills are acquired and shared among Scrum Team members varies greatly from team to team. Nevertheless, we can classify the activities that promote this learning into formal and informal.

Many organizations contract formal training for their employees, but there is usually a limited budget for this objective. On the other hand, it is common for the organization’s own employees to conduct training sessions periodically or occasionally for their colleagues. These sessions are usually focused on subjects in which these individuals are experts or which they have recently learned, either on their own or through contracted training (ARMONY, 2010).

Another formal technical training method for this type of work that is typical among software developers, is the Coding Dojo. Given its playful aspect, the practice of dojo can appear informal, however it is an extremely disciplined and effective way of cultivating skills for software development.

Coding Dojo Coding Dojo is a meeting where a group of software developers get together to work on a programming challenge. They are there to have fun and engage in activities aimed at improving their skills, providing for feedback (both on the code produced and the techniques used) that fosters learning.For more information, visit: https://codingdojo.org/.

Informal training involves the sharing of knowledge between co-workers or from other people outside the team or the organization. This acquisition of knowledge can occur during the day-to-day work or, for example, by participating in fairs and events. Through on the “cross-pollination” I mentioned earlier, both newly-acquired and existing knowledge and skills are disseminated among the different members of the Scrum Team, especially among the Developers.

Originating from Extreme Programming, the practice of pair programming has proven to be a very effective form of informal training for software development work. The equivalent practice of working in pairs can be extended to various other areas. Among the various benefits, when putting two people together on the same task, with one less or not qualified in a certain area and the other more qualified, the latter can teach the former while both perform the work. Another benefit is the better quality of the product generated from the joint construction. This practice can occur full time, on a scheduled basis for a few hours a day or just occasionally.