Forming Scrum Teams
No matter the size or complexity of a product, Scrum Teams remain small, autonomous, self-contained, cross-functional, and self-organizing. Let's go over these in a bit more detail:
Small teams avoid the network density issues that cause inefficiencies resulting from the exponential increase in communication relationships with each added team member.
Autonomous teams have the authority to figure out the work that's required to implement the requirements described in the product backlog.
Self-contained teams have all the resources they require to complete their work.
Cross-functional teams have all the knowledge and skills they require to perform their work.
Self-organizing teams have the responsibility of assigning work tasks to team members in the most efficient manner.
Members of small Scrum Teams must collaborate to work through dependency and integration issues, they must get along, and they must be willing to jump in and help other members when meeting the commitments of the Sprint Goal are in danger.
With a product-oriented focus, Scrum Teams must have all the skills necessary to define the requirements, establish the architecture and design, construct the product, and deploy it. These software product construction skills must encompass test script development, programming, data management, component and systems integration, and testing.
Still, there are limits to what a single Scrum Team can know, such as the business drivers that justify investments in the product. Therefore, Scrum Team members must also have direct access to domain experts and other stakeholders to refine customer needs and product requirements.
Providing access to specialized skills
The Product Owner, with assistance from the Scrum manager, must make sure the developers have timely access to employees, customers, end-users, and other stakeholders who have the information they require to build the right product for their target market customers.
Ideally, Scrum Team members can reach out directly to speak to the people who have the information they require to complete their work. However, there will be times when that is not practical. The Scrum Team members may not know who has the information they need. Alternatively, the effort to locate the right resources, communicate the requirements, and get the input they need is often time-consuming.
The Product Owners and Scrum Masters must facilitate the outreach process to ensure the product's Scrum Teams have access to domain and other technical experts as needed. They also must make sure to capture all customer, market, end user, product, and Scrum Team information and ensure that the information is fully transparent – that is, that it's available to all other Scrum Teams and stakeholders.
Implementing multiple Scrum Teams
Large products may require multiple development teams to produce all the elements required by the solution. This is a fairly common reason for establishing multiple Scrum Teams. Also, organization may have multiple product lines, and each product may have one or more Scrum Teams supporting the product development efforts.
However, as a separate strategy, and often supporting a product or multiple product lines, the Scrum Team's implementations may expand to include all product promotion, order taking, delivery, and support activities, not just development activities. For example, the Scrum Teams may form by business function to include development teams, marketing teams, sales teams, order management teams, partner teams, and so on.
The formation of Scrum Teams to support business functions makes sense in that they all have information and artifacts that they develop and deliver. It also makes sense that they do so as efficiently as possible and in lock-step with the product development teams. Regardless of each Scrum Team's function, they all have the same product-oriented focus, and they all pull from the same product backlog, which is under the control of one Product Owner.
Supporting non-development activities
It's important to note that the Scrum Guide provides generalized guidance on Agile-based practices, but does not provide specific instructions regarding the types of Scrum Teams an organization may form. Scrum Teams can develop any type of product, service, or some desired outcome. Scrum supports all types of deliverable items so long as the Scrum Teams follow the basic rules mentioned at the beginning of this section; that is, small, autonomous, self-contained, cross-functional, and self-organizing.
When scaling Scrum at an enterprise-level, in support of multiple product lines, the product development teams form under the direction of the Product Owners. Scrum Teams that support business functions, such as marketing, sales, support, partner, distribution, and other functional resources, may support one or more Scrum Development teams, depending on the scope of each product. As a result, the business-oriented Scrum Teams may work with more than one Product Owner since each product should have a single, dedicated Product Owner.
For smaller products, the Scrum Teams may include members who have domain knowledge or functional skills. However, the better strategy is to have the developers work directly with these other experts when their skills are required. While it's possible to integrate those functions in a development team, there are practical limits to how much expertise the team can build across disparate domains of knowledge, and remain small.
Finally, it may make sense to combine business domain skills within a single Scrum Team to support a single product's delivery requirements. In this scenario, individuals with marketing, sales, and partnering skills may form within a single Scrum Team. This strategy works to support small products or to support product variants targeting a specific region, niche market, or type of customer.
Evolving Scrum Team formations
The construction of Scrum Teams via skills and knowledge is potentially unique across various products. But the scope of work performed by individual Scrum Teams can vary over time. Moreover, the types and the number of Scrum Teams required to support a product across its life cycle will change as market conditions and product growth change. In effect, change is the one constant you can expect across the life cycle of a product.
Each organization has to figure out what types of Scrum Teams to form based on the products they support. Moreover, those needs will evolve to support changing needs and priorities. Changing corporate strategies, customers, customer needs, customer priorities, impediments, and issues all impact the existing teams' abilities to support their product.
Now that we understand the purpose of Scrum Teams, let's take a look at the roles and responsibilities defined within the Scrum Team.