Scaling Agile Frameworks: SAFe, LeSS or Nexus to Roll Out Agile at Scale?

If managing simple projects is already hard enough, then multiple teams working on the same product might turn into a disaster. Well, a team of 50-200 professionals faces similar issues to a small one but multiplied by five. You get the point: big teams are followed by even bigger problems. When choosing an easy way is not an option, Scaling Agile Frameworks are the magic tools that help teams stay sane & productive.

SAFe, LeSS or Nexus demand cultural transformation and require very good Scrum Maturity for all teams involved. So, let’s take a look at all of them separately.

SAFe: Leading Framework for Scaling Agile Across the Enterprise

Just imagine: the number of people on your team skyrocketed to 100-150. What is your next move? How are you going to communicate? Can you even keep up with your team members?

In situations like this, SAFe enters the game. As it is specially designed for coordination of big Agile projects and teams, since its foundation in 2011, this Agile framework has already helped the largest enterprises in the world to find a new way to develop software and deliver value.

#SAFe principles:

Apply systems thinking
Assume variability and preserve options
Build incrementally with fast, integrated learning cycles
Base milestones on the objective evaluation of working systems
Visualize and limit WIP, reduce batch sizes, and manage queue lengths
Apply cadence, synchronize with cross-domain planning
Unlock the intrinsic motivation of knowledge workers
Decentralize decision-making

Everything has an end-goal, application of SAFe framework is a guarantee that all players involved in the process of developing a product are on the same page when they have to go from business strategy to execution.

Scaling Agile using the SAFe framework proved to be quite efficient with impressive results:

30-75% Faster Time to Market
10-50% increased employee engagement
25-75% increase in productivity
20-50% improvements in quality

According to the 13th Annual State of Agile Report, SAFe remains one of the most popular Agile frameworks that organizations are ready to follow when scaling Agile. Many organizations tend to prefer for this option as it offers a possibility to get early benefits and achieve first milestones.

For a team of 50-120 people that work in a traditional enterprise, SAFe is a relevant choice and a needed “push” to evolve.

This leader among the scaling Agile frameworks has certain prerequisites that are key to ensure its successful implementation:

Agile management style
Agile teams’ mentality
Agile process
Development framework
User stories

All these factors revolve around the idea that the team is open to change, can take decisions fast and has good user stories with acceptance criteria.

#The three levels that collaborate in SAFe:

The Portfolio is a selection of the investment themes along with appointing budget for them.
The Program has an important role called Agile Release Train (ART), representing several teams that work on the same business outcome.
The Team consists of a Product Owner, a Scrum Master and a Development Team.

If you know Scrum, you are probably already familiar with Artifacts. The SAFe framework is not an exception in this regard! It has 2 artifacts: Team/Product Backlog and Sprint Backlog.

It might sound easy to implement SAFe until you start doing it. Initially, the team should have an Agile mindset. Right from the start, it is necessary to train each member of the team in SAFe and to launch the first Agile release trains; this way you can prepare the ground for the application of the framework. Definition of the value stream and its adjustability will determine the project’s performance. To top it off, create an environment where the team’s self-organization with roles proposed by SAFe will flourish.

Scrum Artifacts are more important than you might think, as they provide essential information for the Scrum Team and the Stakeholders.

#Advantages of SAFe:

It represents a combination of best ideas borrowed from Agile and Lean processes
Possibility to recognize dependencies and negotiate them during PI Planning and using the Program Board
High level of engagement from stakeholders as business owners decide the priorities and the value
Synchronicity, efficiency and predictability to the delivery across the group thanks to the Agile Release Train
The teams structured on the feature basis

More with LeSS: An Agile Framework For Continuous Improvement Towards Perfection

Is there a way to ensure that the team’s attention is focused on the whole product and not on a particular part? Here’s where LeSS comes in handy!

LeSS, an organizational design framework alongside Scrum, requires examining the purpose of one-team Scrum elements and figuring out how to reach the same purpose while staying within the constraints of the standard Scrum rules.

For teams, LeSS is one of the Agile frameworks with rules that allows product groups to experiment and discover what works best for them at a certain moment.

The two large-scale Scrum frameworks of LeSS are single-team Scrum scaled up: LeSS (up to eight teams) and LeSS Huge (up to a few thousand people on one product).

#LeSS Principles:

Large-Scale Scrum is Scrum
Empirical process control
Transparency
More with less
Whole-product focus
Customer-centric
Continuous improvement towards perfection
Systems thinking
Lean thinking
Queuing theory

In LeSS each team has a dedicated full-time Scrum Master that helps its members to have a whole-product focus. Additionally, the Product Owner is responsible for prioritizing and clarifying items in the backlog for the entire product. The Development team, that incorporates from 2 to 8 teams, is a cross-functional and self-organized building block with a shared work product.

As most Agile frameworks, LeSS implies that all teams will participate in events like Sprint Planning One & Two, Product Backlog Refinement (PBR), Daily Scrum, Sprint Review, Retrospective and Overall Retrospective. Each team will have a sprint backlog that derives from a single Product Backlog.

In the case of bigger teams, LeSS Huge is a proper solution.

#LeSS Huge roles:

Product Owner – one PO for the entire product
Area Product Owner – one area PO for each requirement
Scrum Master – one SM for each team
Development teams – 2 to 8 teams for each area, not more than 3 areas

#LeSS Huge artifacts:

Product Backlog – a general overview of all the work that needs to be done
Area Backlog – a view into the PB based on the requirement area, where items are split, clarified and prioritized independently.
Sprint Backlog – the list of work that needs to be implemented by the team to complete the selected Area Backlog Items.

#Advantages of LeSS:

Scales Scrum patterns up to the large using small batches to deliver benefit realization to the business every sprint
Structures teams around features
Supports across multiple teams working on a product
Emphasizes customer collaboration over contract negotiation
Focuses more on collaboration and learning across teams

Nexus: A Process Scaling Agile Framework for Multiple Scrum Teams

The Nexus framework means that up to 80 people are divided into three to nine Scrum teams working on a single Product Backlog.

In terms of the organization process, Nexus differs from other previously mentioned frameworks.

#Nexus Team Roles:

Nexus Integration Team that consists of the Product Owner, a Scrum Master and Nexus Integration Team Members with the main responsibility to coordinate & supervise the application of Nexus and the operation of Scrum.
Three to Nine Scrum Teams

So, how does the workflow look like in Nexus?

Refinement of the Product Backlog – identification of dependencies in the Product Backlog to minimize or remove them.
Nexus Sprint Planning – review of the Product Backlog by representatives from each Scrum Team.
Development Work – integration of all work into a common environment, so that it could be tested.
Nexus Daily Scrum – daily meetings of representatives from each Development Team.
Nexus Sprint Review – a meeting at the end of the Sprint to provide feedback on the Integrated Increment that was built over the sprint.
Nexus Sprint Retrospective – a meeting of appropriate representatives from each Scrum Team to identify shared challenges. Nexus Sprint Retrospective is followed by Individual Sprint Retrospectives.

Nexus, as any Scrum Framework, consists of Scrum teams and their associated components: roles, events, artifacts, and rules.

#Nexus Events:

Refinement of the Product Backlog – a forecast of which team will deliver which Product Backlog items and identification of dependencies across those teams.
Nexus Sprint Planning – coordination of all activities for all Scrum teams during one Sprint.
Nexus Sprint Goal – an objective set for the Sprint.
Nexus Daily Scrum – an inspection of the Integrated Increment’s current state to identify integration issues or cross-team dependencies/cross-team impacts.
Nexus Sprint Review – an event that is held at the end of the Sprint to provide feedback on the Integrated Increment to provide feedback on the Integrated Increment built over the Sprint.
Nexus Sprint Retrospective – a meeting to inspect the previous Sprint to create a plan of improvements for the next one, this way ensuring continuous improvement.

Nexus is also defined by Artifacts, opportunities for inspection and adaptation, that are crucial in providing transparency.

#Nexus Artifacts

Product Backlog – a single Product Backlog for all Nexus Scrum Teams managed by the Product Owner.
Nexus Sprint Backlog – a combination of Product Backlog items from the Sprint Backlogs of the individual Scrum teams.
Integrated Increment – the sum of all integrated work completed by a Nexus that is inspected at the Nexus Sprint Review.

#Advantages of Nexus: