Scrum is one of the many frameworks emerging from agile. This agile methodology focuses on being adaptive to change and creating software iteratively. It has been widely and traditional practiced by teams of small sizes. For aligning and managing multiple teams for large or complex projects, you need an agile scaling model.

These agile scaling models provide a framework that sets down the guidelines, techniques, and workflows which ensure that working with hundreds or even thousands of practitioners, remains coordinated and easy to manage.

In this article, we have described the four popular and widely implemented scaling frameworks. After reading this article, you will realize that there is no best framework, rather you will be enlightened about the fact that before adapting any scaling method, you need to actualize what suits your environment. You will realize that just copying someone’s method is not enough. You need to deeply assess your culture to make a change and once you choose an agile scaling framework, you need to wholly and holistically apply it to extract its benefits, completely.

1. SAFe

1.1. Brief Description

Scaled Agile Framework (SAFe) allows enterprises to accomplish their organizational goals to produce the highest quality product in the shortest sustainable amount of time. It is an approach that scales Scrum to an Enterprise Level and gives you the freedom to scale according to your business needs. It introduces a philosophy of servant and lean-agile leadership and goes beyond just implementing an organizational structure, rather instills a new mindset.

Widely known enterprises that have implemented SAFe are:

DHL

Standard Bank

Cisco

Fitbit

Sony Interactive Entertainment

Philips

Hewlett-Packard Enterprise

Accenture Technology

Intel

How many teams can it work with and can it be scaled?

SAFe can be easily extended and scaled to hundreds or even thousands of team members.

1.2. Roles

Agile teams — Consisting of 5–12 members who are cross-functional and self-managing in nature. There is a dev team, product owner and a scrum master in every team.

Product owner — Prepares the team backlog by prioritizing the features.

Scrum master — Servant leaders for their agile teams as their role is extremely vital in discussing and clearing out the problems that the teams are facing. They have to be empathetic to the members of the team thus to create a healthy and productive environment for the teams to work.

Product Manager — At a higher level than the product owner, product managers prioritize the features of the Program Backlog.

Release Train Engineer — The ultimate leader of the Agile Release Train.

Solution Engineer — Similar to the duties of a Release Train Engineer but leads more than one Agile Release Train.

Enterprise Architect — Lays down the foundation of the program portfolio. They guide the direction towards creating a strategic, technical and an adaptable design.

Epic Owner — Creates an Epic which possesses economic and business value. This epic can be any feature or a user story with requirements covering a large scope. The epic owner works directly with the Agile Release Train once their epic is selected and verified by the Lean Portfolio Management.

Business Owner — A key stakeholder in the Agile Release Train.

Lean-Agile Leaders — Servant leaders that teach, coach and educate the teams on how to work in SAFe.

Lean Portfolio Management — The highest level of decision making for the strategies, portfolio operations and governance in SAFe.

1.3. Planning and Events

A major element of the Scaled Agile Framework revolves around the Program Increment (PI). Effectively planning and executing the PI is a major feat.

It is a collection of sprints that last for 8–12 weeks with sub-sprints that can last for 2–4 weeks. The date for planning the Program Increment is fixed. This ensures that it happens at a fixed cadence at a time.

It is scheduled in advance and its date is conveyed to all the members that are part of the PI. This helps to reduce costs on travel and logistics, assuring that everyone will make an attendance. Below are the five steps that describe the process of PI planning in SAFe.

1.3.1. Formation of the Agile Release Train

What is an Agile Release Train?

Agile teams that are specialized for working on one particular element, get together and board the Agile Release Train. These teams will essentially drive the Agile Release Train.

There are 5–12 teams in the train which are geared towards delivering value and in fact build what will be planned.

The Release Train Engineer leads the train and ensures that these teams are synchronized and are in constant collaboration with each other.

1.3.2. Planning the Program Increment

The planning lasts for two days. All the PI objectives are planned, dependencies are sorted and the teams are aligned in a cadence.

Product Management works with the product owners to prioritize and select the features which define the scope of the project.

After setting the PI objectives, each Agile team works on their own set target and manages their work in independent Sprints.

Development is incremental and iterative.

1.3.3. Ensuring Synchronization of the Agile Release Train

Scrum of Scrums: The Release Train Engineer acts as the chief scrum master and has the scrum of scrums where all the scrum masters of all the agile teams of the Agile Release Train are present. It is held weekly or twice a week, whatever suits them, to discuss any impediments or challenges being faced.

Product Owner Sync: All the product owners of the teams meet with the Release Train Engineer or the Product Manager to talk about how the PI objectives can be achieved.

1.3.4. System Demo

Held once a week, all the features that are implemented by the Agile Release Train to present, are demonstrated to the stakeholders.

The stakeholders give their feedback.

This is beneficial as it sheds light on how well the agile teams in the Agile Release Train are integrated together.

The Agile Release Train has a better idea of what the stakeholders really want and it also gives an opportunity to improve.

1.3.5. Pre-Planning

Near to the end of the PI, a pre-planning session is done to plan for the upcoming program increment.

The Release Train Engineer and the Product Managers work on refining the program backlog for mapping out the PI objectives for the upcoming Program Increment.

1.4. Levels of SAFe

The implementation of SAFe is done at four levels.

Portfolio Level — The level at which the inception of strategies and planning of budget comes into being. It fosters the development of Value Streams thereby organizing the Lean-Agile Enterprise into delivering a solution.

Program Level — The level which orbits around the Agile Release Train to give continuous delivery of solution to the customer. The development teams and stakeholders plan, commit, execute, inspect and adapt in the Agile Release Train to deliver a full or part of the solution incrementally.

Team Level — Critical for organizing and defining the roles necessary in the Agile Teams that powers the Agile Release Train. It is part of the Program Level where the Agile Release Trains develops, tests and delivers the working software at the end of an iteration. Ensures coordination with multiple Agile Teams to create an integrated system.

Value Stream Level — An optional level in SAFe to build large solutions requiring collaboration from multiple Agile Release Trains which may have thousands of practitioners. It demands a Lean-Agile approach at a very large scale. Economic framework and financial boundaries support this level for the value stream. It is organized around the Program Increment, which is connected with the Agile Release Trains in the value stream.

1.5. Retrospectives

At the end of the PI, there is an Inspect and Adapt session. This event sums up the entire work done by the Agile Release Train. It is a staged event that is attended by the stakeholders, business owners, agile teams and customers. It is organized by the Product Management and supported by the Release Train Engineer.

The PI is evaluated by the Program Increment Performance Report, where the business owners rate the business value. This business value helps attain the achievement percentage.

Followed by the Program Predictability measure, these findings help identify any issues with the Program Increment. Once the issues are identified, Root Cause Analysis is used and then brainstorming for finding the solutions.

Can it be adopted in a current organization?

You need to change your existing organizational structure to adopt SAFe. It is not an overnight process. It will take its time. There are guides available on the Scaled Agile Framework’s website that gives a step by step insight into transitioning to SAFe. Learn more about transforming to SAFe here.

1.6. Features

According to Forrester’s Q2 2015 Global Agile Software Application Development Online Survey, 33% of enterprises are implementing SAFe.

Designed for large enterprises, makes it easier to work with multiple teams.

Well defined organizational structure, with designated roles and responsibilities.

Lean processes that mean there is a minimal waste, thus ensuring that the teams focus on what really needs to be done.

The formation of the Agile Release Train helps to maintain collaboration amongst teams.

Very well documented which is available for consultation.

Comprehensive and innovative approach as the teams relentlessly improves and adopt newer ways of working.

Limits the Work in Process (WIP) to keep the teams more focused to produce a higher quality of work.

Elaborate handling of processes from the team level to the high level. An active interaction between the development team and the team consisting of the Vice President and the C-Level individuals.

Promotes trust, collaboration, and transparency between the development and the top management.

Emphasizes on attaining business value in the shortest sustainable time.

Ensures consistent approach towards planning, execution, and delivery.

Promotes the sharing of strategy, common vision, and architecture amongst the development and the managerial teams.

Constant feedback from customers helps maintain a successful business relationship leaving room for improvement throughout the entire process.

Educate yourself on SAFe by clicking here.

2. LeSS

2.1. Brief Description

Large Scaled Scrum, abbreviated as LeSS, is one of the leading frameworks of agile software development. It is a multi-team scrum framework which can be applied to an agile team consisting of twelve, hundred or even thousands of individuals, all of whom are working together on one specific shared product.

Using LeSS you can create large or small sized products. It is a simple and minimalistic framework where there is less enforcement of rules, processes, roles or artifacts. There are only conventional scrum roles such as the product owner, scrum master and the team.

LeSS is very customer-centric as teams get to interact directly with the customer while the product owner focuses on setting the roadmap, priorities and the long-term vision of the product.

There are two types of LeSS:

Basic LeSS is for 2–8 Teams

LeSS Huge is for more than 8 Teams.

Enterprises that have implemented LeSS are:

Agfa Healthcare

Huawei

BMW

John Deere

RBS

Port of Rotterdam

Ericsson

Bank of America Merill Lynch

How many teams can it work with and can it be scaled?

Multiple teams can work. It can be scaled by having LESS huge which is implementing multiple basic LeSS frameworks altogether.

2.2. Roles

Teams — The teams range from having 8–12 members. They are cross-functional and self-managing. Teams are also called Feature Teams.

Scrum Master — Facilitates 1–3 teams. A scrum master guides and teaches the teams on how to work in LeSS.

Product owner — Manages the product backlog which consists of the list of features. One product owner can only manage up to 8 teams.

Area product owner — When there is LeSS huge they are responsible for their respective team product backlogs. Only three teams can work under one Area Product Owner.

Chief Product Owner — Leads the area product owners and focuses on the entire product.

Undone Department — A list of tasks that were not done in a sprint. Normally, this department does not exist. But sometimes the teams are not able to complete their tasks so they are shifted to the next sprint. This is the case when creating a large project while working in LeSS Huge.

2.3. Planning and Events

A deliverable product is created in every sprint. These sprints may last for 1–4 weeks. The development is iterative and incremental.

The first stage of the sprint planning involves the selection of items from the product backlog. Two members of each team, meet with their product owner to make the selection of high priority items from the backlog.

In the second stage of planning, the team discusses selected items. Once a team has chosen its items from the product backlog, planning is done to achieve the sprint goals.

There is also a product backlog refinement session. The customer and the teams discuss how the existing requirements can be improved or if new requirements should be added. This session is also essential in talking about what work needs to be done in the upcoming sprints.

DevOps and Continuous Integration is key for smooth delivery to the customer. A team should deliver a shippable increment at the end of every sprint.

2.4. Retrospectives

There is also a retrospective where all the teams, product owners, scrum masters and the management work to understand any impediments that affect the delivery of the product. Teams regularly have their own retrospectives, reviewing what is done to continuously improve.

Can it be adopted in a current organization?

You may need to abandon your current organizational structure and change your present development techniques drastically in order to embrace LeSS completely. The organizational structure is completely different from traditional program management. It is recommended by LeSS to start applying principles of LeSS with one scrum team and adapt the change step by step.

2.5. Features

LeSS provides the entire product view which guarantees transparency in the work you do.

The teams are in direct contact with the customer which enables the teams to grasp the actual idea of what the customer really needs.

With lean thinking, there is minimal waste, thus ensuring focus on what really needs to be done.

There is ample room for the team to learn and grow consistently.

Teams are feature-oriented, customer-centric and their approach is multi-component.

Dependencies are handled at the integration level by sharing the code base with other teams. More frequent code integration is recommended to avoid complexities.

The role of management is focused on defining the vision and nurturing of the team members. Product Owner defines and prioritizes the high-level requirements for the teams.

Teams coordinate with each other frequently and share the code base.

There are design and architecture workshops to align synergy across all the teams and focus towards the end product.

Frequent retrospectives and inspect and adapt sessions are helpful in ensuring continuous improvement.

Heavily focused on the Product Owner.

No guidelines on portfolio management.

Items are in basic LeSS while Epics exist in LeSS Huge.

The role of the scrum master fades away once the teams become proficient in LeSS.

To know more about LeSS, click here.

3. Nexus

3.1. Brief Description

Nexus is a simple framework which implements scrum at scale across multiple teams to deliver a single integrated product. Teams work in a common development environment and are focused on producing a combined increment every sprint with minimal dependencies.

Enterprises that have implemented Nexus are:

Asian Airline

Cathay Pacific

Security Software Co

Terminales

Net Health

HVAC Manufacturers

How many teams can it work with and can it be scaled?

It can be applied to 3–9 scrum teams. So cannot be scaled to more than 9 teams and not more than a hundred practitioners.

3.2. Roles

Teams: 5–12 members that are Self-managing and cross-functional

Scrum Master

Product Owner

Nexus Team: Constituted of 1–2 members from each scrum team. Responsible for planning the vision and the bigger picture of the overall product.

Nexus Integration Team: Essential for keeping multiple teams technically and successfully integrated.

3.3. Planning

The Product Owner comes up with a refined Product Backlog. The teams select items from the Nexus Product Backlog. The backlog can have stories, tasks, business initiatives, epics or any item of any size that suits the teams.

Items in the product backlog are continually refined to minimize or clear away any dependencies. New requirements can also be added. The product owner is the ultimate responsibility for the backlog but if the size of the team exceeds then they may have to delegate some of their tasks to the scrum team, business analysts, project managers or other roles.

Then there is a sprint planning session that has two parts.

In the first part, the Nexus Team conducts a sprint planning session in which they plan the bigger picture of the project. Information and decisions made based on dependencies. Scrum Teams work on their individual sprint backlog. During these sprint planning session, teams interact and collaborate with each other. Teams align themselves in order to achieve their sprint goals. At the completion of all teams sprint backlog planning, Nexus Sprint Backlog gets ready. It is a collection of sprint backlogs of each team which envisions the bigger picture.

Scrum teams have their own scrum cadence in which they create a sprint routine and have their respective sprint backlog.

3.4. Retrospectives

A Nexus Sprint Review is held at the end of the sprint in which all the scrum teams meet with the product owner and review the integrated increment. Scrum teams do not have their own sprint reviews. There is only one collective sprint review in which the integrated increment is the subject.

Finally, there is a Nexus Sprint Retrospective. The essence of every retrospective is to meet and identify shared challenges. The solutions are discussed by sharing ideas and how they can improve. The Nexus Team and the scrum teams have their individual retrospectives. Then there is a collective retrospective where solutions are shared with the entire nexus and the scrum teams.

Can it be adopted in a current organization?

No change in existing organizational structure is needed. It can be adopted in your current organization all you need is knowledge of Scrum.

3.5. Features

This framework promotes and ensures transparency, continuous integration and relentless improvement.

Having a single product and sprint backlog boasts transparency as all the teams sprint data can be easily visualized. Daily scrums enhance communication and help erase dependencies.

Working in a shared environment where work is constantly being integrated into one.

Final product guarantees continuous integration.

Teams use automation to manage any complexities.

The Nexus Integration teams give the necessary support and facilitation to the teams in order to keep in them in line.

Thus eliminating the need of scrum of scrums meeting that is an essential part of other scaling frameworks. They make sure if the processes are followed and truly work as servant leaders to ensure that the teams flourish.

The teams confirm relentless improvement with activities like the refinement of the product backlog, sprint review and retrospective.

Listening to feedback from the stakeholders is paramount. It is vital to adapt to any changing requirements and to eliminate any waste with Lean-Thinking.

Find out more about Nexus here.

4. Spotify

4.1. Brief Description

Spotify has become a popular music player well known for providing original and a limitless collection of music content. It was launched in 2008 and has now grown to nearly 1600 employees. They now have 30 agile teams that are spread over 4 cities in 3 different time zones. They owe their success to their deeply rooted agile methodologies and the utilization of scaling agile, with their own flavour.

Although the makers of this agile scaling method do not guarantee that it will work for every enterprise, they do however encourage tuning the model in a way that it better suits your organization.

Some enterprises that are rapidly growing or medium-sized companies have taken inspiration from it at some level with ING Bank being one of its famous adapters.

How many teams can it work with and can it be scaled?

It can be scaled and extended to multiple teams.

4.2. Structure and Roles

Squads — Similar to scrum teams, a squad is autonomous, self-organizing and self-managing.

Tribes — Multiple squads that work on the related feature area makes a tribe. A tribe may consist of 40–150 people but ideally, a tribe should have 100 individuals. A tribe has a tribe lead who is responsible for creating a productive and innovative environment for the squads.

Chapter — At the horizontal level of the functional organization, there are chapters which are also known as the specialists. A chapter consists of individuals from different squads to be grouped into one and formed within a tribe.

Guild — An informal group constituted of people from different tribes, who have a common interest, form a guild. A person from any squad, chapter or tribe can be a part of a guild.

Trio — A trio is formed when for every tribe there is a design, product area, and a tribe lead.

Alliance — A combination of three trios makes an alliance. It is led by a product, design and a tribe lead.

Chief Architect — A crucial member of the organization that defines the architectural vision and who also guides the designs and deals with the system architecture’s dependency issues.

4.3. Planning and Events

The squads use KANBAN, scrum sprints, XP or a mix of these agile methodologies to carry out their duties. Each squad has direct contact with the stakeholders. Face to face communication is encouraged over documentation.

Release Train dates are pre-scheduled and each team can add their part of the code whenever suitable. Operation teams act as a squad and their job is not to just deploy the code into production, but to build a structure that enables squad teams to deploy their code themselves. Development is iterative and incremental.

Tribes have gatherings on a regular basis. They have an informal get together where they show the rest of the tribe what they are working on and what they have delivered. This includes demos of working software and which tools have been used. Teams have Scrum of Scrums to discuss any roadblocks.

Feature Toggling is encouraged as you can deploy code into production, which remains hidden, that can be enabled or disabled depending on the user or the environment.

For planning, the teams use a matrix called DIBBs, which is an abbreviation for Data, Insights, Believe, and Bets. High-level planning is based on the company bets and beliefs that are supported by data and insights. Strategic alignment comes from squad level bets, that leads to tribe bets and functional bets.

4.4. Retrospectives

The agile coach conducts retrospectives while sprint planning meetings are kept optional. There is consistent communication with stakeholders and customers.

Can it be adopted in a current organization?

You need to change your current organizational structure. Start from the departmental level of your organization and see if it has the potential to successfully fit into your organization.

4.5. Features

Adapting a unique Agile Scaling Method has made Spotify achieve their goals quicker in an environment which is accommodating for every individual in the company.

Enhanced delivery velocity.

Emphasizes continuous integration and integrating the code in a delivery patch.

Processes are reduced to a minimum.

Feature toggling is helpful as it gives you an understanding of how the users will react when new features are added. You do this by rolling out a new feature to select users. Upon their feedback, you can have the opportunity to thoroughly test or make any improvements to the feature if needed, while having the simple option of toggling back to the older functionality, if need be.

Addresses short-term challenges effectively.

Minimized dependencies within teams.

Lack of a firm structure makes problem-solving easier.

Not a traditional organizational structure where the manager tells the teams what to do.

Teams are autonomous and self-managing with minimum control.

Promotes trust, clarity, and transparency.

Servant leadership is practiced.

Focuses on evaluating the team members’ motivation level to ensure maximum productivity.

Believes in learning by delivering and continuously adapting.

Ample room for continuous improvement.

Responds to change quickly.