Scrum Guide and Scaling: Part 2 - The Scrum Teams

• Scrum Guide and Scaling: Part 1 - Scrum Theory
• Scrum Guide and Scaling: Part 2 - Scrum Teams
• Scrum Guide and Scaling: Part 3 - Scrum Events
• Scrum Guide and Scaling: Part 4 - Scrum Artifacts

Cross-functional Scrum Teams make sense for sure.  If a single Scrum team should already be cross-functional, then it is even more valid for a constellation of multiple Scrum Teams. However, here lurks already an important pitfall. One could also draw the conclusion that, for a constellation of multiple Scrum Teams, each team could be staffed within one discipline - a team of architects, a designer team, a team of programmers, a team of testers, etc. Though, this is contradicted by the following expression:

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback.

This means that each Scrum Team must be able to provide working product increments. Wherein the same also applies to the overall constellation. We will consider the contents of the product increments later.

Therefore, self-organizing Scrum Teams work self-organized also across the teams. A popular misinterpretation in introducing scaled Scrum organizations is the usage of auxiliary roles such as project managers to manage the scaling problems. This is exactly what is contrary to the spirit of self-organized work. If a single team can organize themselves in order to achieve a specific goal within the given business conditions, then it must also work for several teams. Therefore, scaled constellations of Scrum Teams have also only the three Scrum roles.

A Scrum team consists of the three roles. If we scale the number of development teams, the question arises how many role owners of the respective Scrum roles will be needed. What concerns the Scrum Master, it is simple. Each development team should have a Scrum Master. Ideally, a dedicated Scrum Master pro team, so the role scales more or less together with the number of development teams. But how does it look like with the Product Owner? There should be a single Product Owner per product, but each Scrum Team should have a separate Product Owner?

2.1 The Product Owner

In a constellation of several Scrum Teams there is only one Product Owner independent of the number of development teams. This follows from:

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog.

If there would be several equally positioned Product Owners in their respective Scrum Teams, this responsibility could not be clearly attributed to one person. Now one can of course argue that a single person could be quickly overburdened with the tasks of the Product Owner for a greater product development. That's right. The Product Owner is responsible, among other things, for the management of the Product Backlog, what includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

These tasks can however also be done, using the Development Teams or with the support of employees, without questioning the position of the single Product Owner. This also applies when the Product Owner delegates portions of the Product Backlog to employees who may then independently decide on issues and priorities within their sphere of influence  in line with their agreement with the Product Owner.

2.2 The Development Teams

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.

Development Teams are structured and empowered by the organization to organize and manage their own work.

According Scrum Guide, there is a maximum reasonable number of members in a Development Team. However, this number is not to be understood as an absolute benchmark. There are certainly cases of well-functioning Development Teams of 12 or more members. Generally not later than at this point there should be a split. A scaled Scrum constellation is already there if two Development Teams need to align with each other. As a result of a breakdown we need to get new well-functioning development teams again. The ability to self-organization and interdisciplinarity should not be sacrificed for the idea of resource optimization - certainly well-intentioned.

2.3 The Scrum Master

The Scrum Master is the most misunderstood and the most miss-respected role in Scrum. This is particularly true when the number of Scrum Masters - and thus their capacity to support the Development Team, the Product Owner and their employees and the organization - does not grow with the number of Scrum Teams. This does not necessarily mean a 1: 1 ratio of Scrum Teams and Scrum Masters. But the list of the main services of the Scrum Master shows that the distribution and spread of the work of a single Scrum Master are limited:

Scrum Master Service to the Product Owner The Scrum Master serves the Product Owner in several ways, including:

• Finding techniques for effective Product Backlog management;
• Helping the Scrum Team understand the need for clear and concise Product Backlog items;
• Understanding product planning in an empirical environment;
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
• Understanding and practicing agility; and,
• Facilitating Scrum events as requested or needed.

Scrum Master Service to the Development Team The Scrum Master serves the Development Team in several ways, including:

• Coaching the Development Team in self-organization and cross-functionality;
• Helping the Development Team to create high-value products;
• Removing impediments to the Development Team’s progress;
• Facilitating Scrum events as requested or needed; and,
• Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Scrum Master Service to the Organization The Scrum Master serves the organization in several ways, including:

• Leading and coaching the organization in its Scrum adoption;
• Planning Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact Scrum and empirical product development;
• Causing change that increases the productivity of the Scrum Team; and,
• Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

No rules concerning the extent to which Scrum Masters are required in a scaled Scrum constellation can directly be derived from the Scrum Guide. This certainly depends also on the available capacity, qualifications and experience of the team. Many problems of scaled Scrum implementations, however, arise from the misunderstanding of the importance of this role.

... The next article is about Scrum Events. ...