What is Scaled Agile?
This is an abstract.
Scaled Agile means applying the principles and techniques of Agile beyond the team level. Examples of this: Agile collaboration of multiple teams and/or Agile portfolio management. The goal of scaling agile is for the entire organization to become more responsive.
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.
Agile scaling has three "flight levels"
Let's describe them from the bottom up:
Operational / Team (Level 1): ;The work of individual teams that are part of a value stream or provide a service to other teams in the organization. Level 1 improvements are localized and typically provide little to no optimization to the organization's value stream.
Value Stream: Coordination for one product or one service (Level 2): Coordination of multiple teams in a common end-to-end value stream of a company (from idea or order to delivery to the customer). This can be a joint product development, but also a joint service. Improvements have a global impact on the entire value creation process, not just locally.
Strategy and Portfolio (Level 3): This level supports the organization in operationalizing its strategy. Successful improvements at this flight level usually lead to increased clarity among employees and thus stronger joint action by the entire organization.
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.
A Scaled Agile solution is always an individual solution.
No Scaled Agile framework replaces your own organizational design and development. All Scaled Agile Frameworks - understood as a blueprint and simply rolled out - are wrong, because they are only models. Nevertheless, all frameworks are extremely helpful in designing one's own agile organization:
They provide patterns and save reinventing the wheel;
They show how elements like Scrum, Kanban or Design Thinking etc. can be combined;
Different frameworks offer different alternatives, which can also be combined with each other.
When designing your own agile organization, the Scaled Agile Frameworks are important because they provide proven patterns. However, they are no substitute for investing in your own organization design.