What is Scaled Agile?

Scaled Agile implements Agile for more than one team.

Agile & Lean techniques have found their way into many companies and help them to be more responsive and to successfully deal with complex challenges. Until recently, this was usually limited to the team level. For the overall organization to be responsive,i.e. to compete successfully in environments characterized by surprises, it is important to build on the positive team-level experiences with Agile. That means applying Agile & Lean techniques to large projects, units and the organization. Such Agile approaches for the entire organization are called "Scaled Agile" or "Agile Scaling". They address the collaboration of multiple teams and entire organizations and build on the principles of Agile (see: Agile Manifesto).

The path to Scaled Agile should also be agile

By "Scaled Agile" we mean that you scale Agile. If you want the values and principles of Agile for your organization, then the way to scale should also be Agile. Therefore, the path to a "Scaled Agile" organization is through an Agile Transformation.

Scrum is primarily about one team and one product. We talk about scaling Scrum in the case of multiple teams and/or multiple products.

The graphic shows four typical cases of one or more products, and of one or more teams.

• Bottom left: The typical Scrum team works on a product and has a product backlog. 

• Bottom right: A Scrum team works on multiple products. It has multiple product backlogs from which work is pulled according to specific rules.

• Top left: Several teams work on one product. They have a common product backlog.

• Top right: several teams work on a portfolio of products. Products and teams are largely independent of each other.

We talk about "Agile Scaling" in the top two cases.

Golden rule of Scaled Agile: As much decoupling as possible, as much scaling as necessary.

Collaboration of many people is expensive: the costs increase exponentially with the number of people. Therefore, it makes sense to put investments into decoupling teams before we organize collaboration. Decoupling can be done, for example, by architecture(-redesign) or the separation of a product into several products. Sometimes you hear people saying, "If you are thinking about scaling, don't do it." This is, of course, an exaggeration, but it helps to always keep decoupling in mind and to actively work on it ...

Agile scaling has two basic "social" building blocks: teams smaller than 10 people, value streams smaller than 150 people.

Teams (<= 10 people) are the basic units of agile scaling. Only in this size is true self-organization feasible, otherwise diffusion of responsibility begins.

A unit of <= 150 people should be the maximum for collaboration in an end-2-end value stream. 100 - 150 people is a size where people still know each other personally (Dunbar number). With larger numbers of people, decoupling is necessary (see above) and e.g. the use of a portfolio is helpful.

Various frameworks offer patterns for Scaled Agile.

For scaling Agile, there are several Agile frameworks that offer proven solution patterns. There are patterns for all work situations and for all flight levels. Let's classify the most important frameworks in the two axes "type of work" and "flight level" (see the image below):

• Scrum addresses development (of a product or service) at the team level;

• LeSSand Scrum@Scale address the development (of a product or service) by multiple teams (value stream level);

• Kanban Addresses all types of work at all levels (team, value stream, and portfolio);

• SAFe addresses all types of work at all levels. As an "encyclopedia" for "Business Agility", SAFe integrates many agile frameworks, including Lean Startup, Lean Budgeting, Design Thinking and others.