Organizational Paradigms to Scale Agile
Organizational Paradigms to Scale Agile
By Bruno Collet
This article provides an overview of issues that arise when scaling agile projects and organizational paradigms that help solve these issues. The analysis is based on personal experience and some research (see references at the end).
To preserve agile strengths, all agree that the team size should be limited (upper limit is 8-to-12 depending on opinions). Consequently, scaling agile necessarily implies setting up a multi-team organization.
Additional needs for multi-team agile include (but are not limited to):
- Handling cross-team impediments
- Ensuring alignment with strategic objectives
- Dividing the work among multiple teams
- Integrating the work of multiple teams in cohesive product releases
- Maintaining a common foundation of practices and tools across multiple teams
- Facilitating the emergence of a sound product-level architecture
We will explore a few organizational structures that may help cope with these extra needs. These structures are provided as a starting point and should be adjusted and combined according to the context. Rather than focusing on a specific agile framework (such as Scrum), we will use framework-neutral terminology. You can easily map these practices to your agile framework of choice.
The organizational paradigms consist essentially in setting up one or more additional teams to deal with the issues mentioned above. These additional teams are:
Coordination Team
Purpose
The purpose of the Coordination Team is to solve cross-team issues. Its Scrum equivalent is the Scrum of Scrums.
Roles
A technical member (neither the Coach nor the Product Owner) of each Development Team participates to the Coordination Team. The participants are chosen by each Development Team based on the issues at hand. Consequently, the Coordination Team is transient (it exists only during meetings) and virtual (it is made of members of Development Teams). Since the Coordination Team doesn’t manage any work queue, it doesn’t need a Product Owner.
Practices
The Coordination Team meets as often as daily or as seldom as weekly. The Coordination Team meeting is typically a 30-minute meeting that, unlike a daily stand-up meeting, can also be used to address problems right away. The Coordination Team has no work queue and therefore requires neither planning nor reviewing.
Optionally, the Coordination Team may be used to track overall progress by consolidating the Development Team’s progress reports, such as producing a product-level progress chart based on the Development Teams’ progress charts for example.
Artefacts
- Cross-team issue list
- Product progress chart (optional)
Integration Team
Purpose
Also called the Release Team, the Integration Team’s purpose is to integrate the work produced by individual Development Teams and package it in product releases.
Roles
The Integration Team is usually permanent and composed of (1) people with a good understanding of the product-wide technical aspects and (2) people capable of integrating the modules. The Integration Team owns the product work queue and has the Product Owner for the whole product (aka Chief Product Owner).
Practices
The Integration Team owns the product work queue and is responsible for decomposing the product into modules (i.e. define module work queues according to the product work queue) allocated to Development Teams and to manage the dependencies between these modules. Alternatively, individual Development Teams can pull work items from a single product work queue.
Technical integration includes collecting the artefacts, managing versioning, producing baselines, and packaging the product for the product-level review.
Like an ordinary Development Team, the Integration Team undergoes planning, daily stand-up meetings, reviews, and retrospectives. However, the Integration Team’s iterations are based on product releases and typically span multiple development iterations.
Artefacts
- Product work queue
- Product progress chart
- Release plan
Meta Team
Purpose
The Meta Team focuses on coordinating multiple Development Teams and ensuring their alignment with strategic objectives. It is not meant to deal with technical issues. In contrast, the Coordination Team is tactical in nature. The Meta Team is an attempt to reconcile Agile with the steering committee that many organizations require and therefore enforces vertical transparency. Unfortunately, it also creates an implied hierarchy that is contrary to agile principles.
Roles
The Meta Team is Product Owner-centered. It is composed of a Chief Product Owner, the Product Owner of each Development Team, and other stakeholders (typically executives and project sponsors).
Practices
The Chief Product Owner is responsible for the plan and for conducting the Meta Team meeting. The meeting helps stakeholders evaluate and validate the Chief Product Owner’s work products and plans along with the value being achieved.
The meeting also examines how the work of Development Teams satisfies the expectations and constraints present in a complex organization, such as high level requirements, budgets, and schedules.
Artefacts
- Release plan
- Roadmap (or vision chart)
Support Team
Purpose
The Support Team’s role is to support the Development Teams by providing tools and guidelines to facilitate development. In essence, the Development Teams are the clients of the Support Team. The Support Team tries to deal with two problems arising when scaling agile: (1) losing economies of scale because of the relative independence of individual Development Teams, and (2) the difficulty of having an effective product-level design emerging from the work of the Development Teams.
Roles
The Support Team’s composition is similar to that of a Development Team, including a dedicated Product Owner. The Support Team’s Product Owner represents the interests of the Product Owners’ of the Development Teams.
Practices
The Product Owner is responsible to identify tools, frameworks, and guidelines that can benefit Development Teams. The Support Team has its own iterative cycle to deliver these elements. It is also responsible to set up the tools and frameworks in Development Teams, which may involve activities such as training. The Support Team must find the best compromise to build a common foundation for Development Teams while respecting their independence.
Tools typically refer to productivity tools that help Development Team become more efficient, such as code generators for example. Technical frameworks facilitate the emergence of an architectural consensus among Development Teams, which will in turn facilitate development and integration. Guidelines emphasize shared practices, such as coding standards and user documentation templates for example.
In organizations delivering multiple products, the Support Team can support multiple projects and contribute to the accumulation of practice expertise.
Artefacts
- Tools
- Guidelines
- Design frameworks
- Same as Development Teams
Bruno Collet combines business acumen with technology know-how. His successful track record comprises Daimler-Chrysler, Siemens, and Loto-Quebec, with roles such as management consultant, project manager, SAP consultant, and software architect. Bruno Collet’s skills are firmly grounded in academic excellence by achieving an MBA at John Molson School of Business and a Master of Computer Science. He maintains a professional website: brunocollet.com.
