Agile Scaling Playbook

Have you noticed, as I did, that the SAFe (Scaled Agile Framework for enterprises) training material focuses mainly on the basics of Agility? Well, it’s normal! Even if big organizations have found Agile scaling frameworks to their measure (SAFe, DaD[1], Nexus, and LeSS[2]), it does not exclude the fact that to implement them, the foundations remain the same: the Agile Manifesto, Scrum, Lean, Extreme Programming, Emergent Design, planning by business value, etc.

This made me want to design a small Agile Scaling Playbook, without a framework, for all people who have some Agile experience and who want to address scaling directly.

Basic Play — the Big Team

One of Scrum’s strengths is to have put forward an important condition for success: the multidisciplinary and self-organized team. That is to say, a single team with all the skills to autonomously build a new product increment. To this, add the recommendation that it be collocated and you have a winning recipe to reduce complexity caused by exchanges, dependencies, infrequent feedback, individuals’ lack of availability, poor motivation, and lack of engagement. Unfortunately, the complexity caused by synchronization increases again as soon as a new team is added.

That is why, if there is no tension within your team, I would recommend to keep it as is, no matter the limits recommended by the Scrum Guide (3 to 9 individuals) or Mike Cohn (7 ± 2 individuals). I have myself been part of Agile teams of more than ten people for which there was no advantage of being divided. On the other hand, having exceeded the recommendations of the literature, we were ready to revise our configuration if certain symptoms appeared:

Clearly insufficient velocity requiring the addition of an important number of new members
Inability to maintain a direct relationship between all of us (e.g. one-on-one), leading to the creation of unofficial subgroups within the team
Team meetings that are too long and exhausting, where the shared understanding and involvement of all are difficult to maintain

Play #1 — Multidisciplinary Teams (Feature Teams)

When the Big Team reaches its limit, there can be benefits to dividing it. With Agile approaches, the most natural way to do it is to create multidisciplinary teams. Much like the basic team, multidisciplinary teams have all the skills to autonomously build a new product increment.

All multidisciplinary teams can work autonomously on the same code base. They can thus draw from the same product backlog and collaborate with the same Product Owner.

For this configuration to be sustainable, it is important for all the teams to have the same Definition of Done (DOD). It is also preferable for the teams to synchronize the code between themselves as often as possible.

Pros

Offers great planning flexibility since each team can take any item without imposing constraints on the sprints’ planning (neither regarding the content nor the duration)

Cons

Requires great discipline from all the teams to maintain product integrity. This discipline is usually ensured by a common DOD
Requires to have enough players with the right skills

Important consideration: To allow the planning of sprints of different durations, teams will have to agree on mechanisms for submitting, updating the base code, integrating, and managing dependencies. What’s important is to find a way to reduce the inspection loop between the different teams’ versions to avoid bad surprises when a team’s code is merged with the common core.

Play #2 — Component Teams

When it is impossible to create multidisciplinary teams because there are not enough experts or because the skill sets do not easily combine, component teams can become interesting. There are two axes along which it is possible to divide the teams: business activities and design layers.

For example, for an online purchase solution, a breakdown by activities would look like this: the purchase process team, the payment process team, and the delivery process team. As for the breakdown by design layers, it would look as follows: the mobile applications team, the web team, the web services team, and the infrastructure team.

Even though this configuration is useful in certain contexts, it results in an important constraint: the synchronization of iterations. Since none of the teams is able to deliver a feature autonomously, and because we expect to have an increment abiding by the definition of done at the end of every iteration, the teams need to coordinate the inter-team work in order to deliver a single integrated increment at the end of each iteration. Without this rule of operation, the teams risk having a debt of additional work because the validation of the work that is allegedly done will not be complete before integration in a subsequent sprint.

Pros

Enables to regroup experts due to limited resources or for efficiency
Allows a Product Owner to distribute the burden of product backlog management to other Product Owners

Cons

Requires sprints to be synchronized
Requires the planning of the different iterations’ backlogs to be synchronized
Requires adjustment of the composition to balance the pace among the teams

Dynamic Play System

Even if we tend to keep the configuration stable to increase predictability, it is possible to change the configuration to adapt to a situation that requires it.

Here is a real life example. In a business responsible for a platform broadcasting European football games, we were divided into two teams: one responsible for Internet broadcasts and one responsible for mobile broadcasts. Both teams were multidisciplinary because we could deliver new increments autonomously on our respective platforms, even if we were sharing the broadcasting platform’s code.

One day, important work had to be done on the platform, and it was hard to imagine that this work could be planned through joint work with both teams. For a few iterations, we then switched to component teams while we accomplished those tasks. Once the work was done, we went back to our multidisciplinary configuration to retrieve our autonomy.

This example shows how scaling is not necessarily static, and that it is possible to switch from one play to another according to your needs. This knowledge of the different plays can provide organizations and programs with the flexibility that is sometimes required to face a complex situation that involves multiple teams.

[1] Disciplined Agile Delivery

[2] Large-Scale Scrum