Team Size and Geographical Distribution

What do you do when faced with a large and distributed team? The larger the team, the more challenging it is to keep it moving forward with cohesion and productivity, whether you are doing Agile or a variant of waterfall. The question is: How do you configure teams to keep sizes manageable, have the skills that are needed, and be as colocated as possible, while aligning with the Agile mindset in team configuration?

The first step is to promote small yet appropriately skilled teams. The team should be large enough to have the right skills and experience in design, development, and testing to build the product—but small enough to self-organize and maintain high productivity. When teams get too large, they are harder to self-organize and this negatively affects productivity. For example, for a project team size of 35, it is best to divide the team into five Scrum teams of seven, with each team having the skills and experience to thrive.

The second step is to promote ownership of a functional piece of the product. When a team feels ownership of a piece, they will begin to take pride in their work and become more productive over time as they become more familiar with their component. This requires that the product be designed in such a manner that functional components are clear and Scrum Teams can align with those areas. For example, the product may be made up of 12 components or functional areas and the first Scrum Team owns the order entry and billing functionalities.

The third step is to promote colocation. Because it is not uncommon to have distributed product teams, you attempt to configure each Scrum Team to have as many of the team members to be colocated and near-shore as possible. Colocation means that team members are in the same physical location. Near-shore means that team members are within the same campus or within the same time zone or two. In the same scenario, if you have a project team of 35 and find that 15 are in India, 7 are in Europe, and 13 are in the eastern part of the United States, then it makes sense to have two teams of 7 and 8, respectively, in India, one team of 7 in Europe, and two teams of 6 and 7 in the eastern part of the United States. If you find that, within the United States, five of the team members are colocated in Massachusetts, then it makes sense to have those five on one team.

Agile Roles beyond Team

Although there are core team roles discussed within Agile, engaging the whole organization in applying the values and principles helps with the overall business success. Aside from the Scrum Master, Product Owner, and Development Team, there are the actual customers, executives, senior management, middle management, sales and marketing, finance, human resources, and other roles that must change to allow for an inspect-and-adapt approach to building software. For a refreshed understanding of Agile core and beyond roles and responsibilities, revisit Chapter 12.

Scrum of Scrums

When a product team is comprised of two or more Scrum Teams, a Scrum of Scrums (SoS) may be established. An SoS is a coordinating body made up of representatives from each of the Scrum Teams to focus on the many cross-team issues and dependencies that need to be resolved and to keep large teams synchronized and operating effectively.

Most agile processes such as Scrum are ideally suited for colocated team sizes of seven plus or minus two people. When you have a large project team of 35, there needs to be a way to coordinate the work and ensure common issues across those teams get addressed in an effective manner. The benefits of a SoS are that it:

• Enhances communications across teams, so each team knows what the other is doing.
• Avoids duplication of effort across teams.
• Reduces suboptimization, when a team is doing work that is best for them but that negatively affects another team.
• Builds a strong support system for Agile teams because change is hard for one team to manage on their own.
• Helps Scrum Teams prioritize the work because some teams may be dependent on work from others.

The purpose of the SoS helps specify who should represent their team. To start, the common representative from each team is the Scrum Master. Figure 15-1 illustrates the Scrum Master from each Scrum Team meeting to discuss project progress, risks, and more.

The generic SoS focuses on project progress, risks, issues, and dependencies. This Project Progress Scrum of Scrums is usually comprised of the Scrum Masters, the Product Owners, and an Agile project manager. The Project Progress SoS is responsible for the following:

• Monitors release burn-up with velocity to determine scope to release date and whether adjustments to either scope or schedule need to occur.
• Identifies and mitigates blocking issues that are beyond the scope of a Scrum Team, with the goal of removing the blockage or escalating it to management.
• Discusses story dependencies among Scrum Teams and ensures that the highest priority stories are optimized to the project level.

If there is still a lot of uncertainty regarding customer needs or prioritization of current functionality and user stories, there may be a benefit to convoking a Product Owner Scrum of Scrums. The Product Owners from each Scrum Team should attend. A development lead from each Development Team may also attend if technical insight is needed to prioritize the work. The Product Owner SoS is responsible for the following:

• Communicates stories that need to be added to the Product Backlog and negotiates the priority of these stories.
• Explains changes to the backlog—specifically, why stories have been added or removed from the backlog or had their priorities changed.
• Identifies dependencies or overlap of stories between Scrum Teams. Teams can add backlog items for other teams and negotiate priority.

The resulting information helps shape the direction of the product and sprints.

If there is still a lot of technical uncertainty and complexity, then there may be a benefit to initiating a Technical Scrum of Scrums. The Technical SoS is comprised of each Scrum Team’s lead developer and QA, and the lead architect on the product. The Technical SoS is responsible for the following:

• Evaluates and makes technical decisions that affect Scrum Teams and the overall direction of the product.
• Serves as a working group for solving technical problems across Scrum Teams.
• Establishes code standards by which all the Scrum Teams should operate.
• Identifies new common services to eliminate duplicate coding efforts between teams.
• Identifies and applies the QA vision and the integration (and other) testing needed.

Each SoS may meet as often as every day (but for only 15 minutes) to once a week, depending on various factors. For the Project Progress SoS, the frequency may vary based on the risks, issues, and dependencies that must be addressed. For the Product Owner SoS, the frequency may vary based on the level of uncertainty and the focus on prioritization. For the Technical SoS, the frequency may vary based on the technical complexity.

Sprint 0

Sprint 0 is a Sprint designed to help teams envision the work ahead. It is primarily used by teams new to Agile to help in their readiness to begin Agile or by teams beginning a complex project that requires thought for visioning and getting organized. Sprint 0 is not a replacement for big up-front activities found within the waterfall and phase-based methods, but instead serves to establish a basic vision of where the project is headed while acknowledging that things will adapt as the team moves forward. The length of this Sprint should be no longer than the standard Sprint length. Here are some tasks that typically occur during a Sprint 0.

• Define teams, including team size, need for multiple teams, and team distribution.
• Define Sprint length.
• Educate teams on agile processes and practices.
• Collect and groom stories within the backlog with an emphasis on prioritization.
• Establish Scrum of Scrums.
• Work on spike solutions per the XP definition.
• Identify project risks, issues, and dependencies.
• Establish the product, technical, QA, and CM visions.

Some may argue that Sprint 0 is not true to Scrum, and they are correct because no working software is produced. However, in some cases, these tasks need to occur prior to Sprint 1, irrespective of what you call this time-boxed period.

For clarity, a vision provides enough detail for team members to understand the general direction of the topic area. It is not meant to be detailed or fixed, because in an Agile mindset you cannot possibly know everything up front, and you expect that it will evolve. Visions should be brief and easily digestible. They may live in the team document repository, such as the wiki. Also, if the vision remains mostly the same from one release to the other, then the vision should primarily include what is changing.

The various visions that can help a team include:

• Product vision: provides business context of the product to include business performance, market share, and measures of customer satisfaction, high-level product roadmap, and a prioritized list of business objectives. It may also include an elevator pitch encapsulating the project in succinct but compelling terms.
• Technical vision: provides the direction of the architecture, including known and emerging elements of the technology stack, frameworks, common infrastructure and operating platforms, needs for refactoring, and system-level nonfunctional requirements such as usability, performance, reliability, security, and any governing regulatory or industry standards that must be followed.
• QA vision: provides an overview of the proposed testing framework, testing process and how it interacts with the development process, testing types, test tools, and who may perform the various types of testing.
• CM vision: provides an overview of the proposed version control tool, branching and merging processes, and build management tool and process.

It is best to implement Sprint 0 much like any other Sprint. The team starts with a form of Sprint Planning, a Sprint 0 backlog is used to manage the work, and daily stand-ups occur to share progress and roadblocks. Instead of a Sprint Review and retrospective, I recommend that you conclude the Sprint 0 with Agile Release Planning. This is a session in which everyone is together (physically or virtually) sharing the results of Sprint 0 at the same time.

Agile Release Planning

Agile Release Planning is an activity that replaces the detailed planning phase in a more traditional waterfall model. It is made up of a session, often two or three days, where all Agile Team members are involved, including management, and anyone else who can materially participate. A major part of Agile Release Planning is grooming the backlog as a team (or as individual Scrum Teams) to gain an understanding of the breadth of the work ahead. The benefits of the Agile Release Planning are:

• Shares the release and Sprint schedule.
• Gains team insight into the product vision and business context for the release.
• Informs the team on the latest on technical, QA, and CM within their respective visions.
• Provides overview of who will be on which team and who are on other teams.
• Shares structure and participants of Scrum of Scrums.
• Provides the team with clarifications of the objectives, epics, and stories.
• Gains team commitment (a critical factor).
• Helps resolve conflicts of vision (what we would like to accomplish) versus reality (what we can accomplish).
• Raises dependencies and risks early.

This is done to ensure the whole team participates, gains insight into the work ahead, and promotes an initial commitment to the work. An example agenda of a two-day Agile Release Planning may look like this:

• Introduction of attendees and agenda: facilitator (may be a Scrum Master).
• Welcome address: executive.
• Product vision: Product Owner.
• Technical, QA, CM visions: respective leads in these areas.
• Backlog grooming: team(s)—this is the biggest part of the two days.
• Sharing results from grooming: common themes, risks, issues, and dependencies.
• Retrospective: facilitator (similar to a Sprint Retro­spective)
• Wrap-up: executive, product owner—next steps and thank you.

There are two approaches to timing Agile Release Planning. The first is at the beginning of a project, in a Sprint 0 context or otherwise. The second is that it occurs every 90 days to periodically visit the visions and direction of the product.

Automation

One aspect of scaling is reducing manual steps and automating the necessary steps. Eliminating and automating provides the team an opportunity to scale and increase their velocity. It is recommended to automate any process that is repeated by enough people for which the team will see a cost and time benefit in doing so. Because the team can focus less on the manual steps of a process and more on the work of building product, they have a real opportunity of increasing their team velocity.

As an Agile Team gets up and running, given the continuous nature of building, migrating, and testing code and the increasing size of the code base with new functionality, a lack or minimal amount of automation may start to affect velocity fairly quickly in a negative way. Please understand that at a certain point velocity may remain constant even with automation, but you can be certain that without automation or with minimal automation the team’s velocity will plateau.