Scaling Agile – How to get started

The term Scaling Agile seems to pop up everywhere you look. On IT conferences, among management and when HR people initiate recruitment etc. But scaling agile is not just one specific and well defined model to apply. It is a range of frameworks, combinations of frameworks and hand crafted approaches specific to an organisation. And yes, it does matter how you get started on scaling agile.

Scaling agile is a range of skills that can be learned, just like addition in the math classes in the first grades of primary school. But where addition is uniquely defined and has a specific logic (2 + 3 = 5, always) then scaling agile is not uniquely defined and does not have a ‘logic’ in that sense.

Before we dig into these aspects, let’s first recap what agile is.

Agile

The word agile is not new but widely used in everyday language. According to Miriam-Webster, the word Agile has two explanations, namely

1. Marked by ready ability to move with quick easy grace
   // an agile dancer
2. Having a quick resourceful and adaptable character
   // an agile mind

In relation to development of new solutions technology, the more widely used starting point is the agile manifesto

This list of agile techniques is long, where the most widely used are Scrum, Kanban and XP, although the list is far longer. Generally speaking, when being agile, one product is being worked on by one team only, although there are exceptions.

As the agile techniques are structurally different (e.g. organised around an iteration or not), there are also more than one way you can organise your scaling agile efforts.  

A key difference to team-level agile, is that more than one team work on the same product. Whether it is 5-8 teams, 25 teams or 1000 teams working on the same product, depends on the nature of the product (the product definition). Wider product definitions typically have more teams working on the same product, and thereby enable them to handle synergies and dependencies within the domain of the product. Slimmer product definitions leads to a higher number of products in the organisation.  

We will now dig further into the main scaling agile frameworks. And by main frameworks we refer to the frameworks being applied by the Danish organisations, found in the survey by VILMA Consulting you can read more about here.

Levels in Scaling Agile

A key difference between agile for a team (or a number of teams) and scaled agile, is that with an agile team, there is only one level. There is no portfolio-management-like structure ‘above’ or ‘around’ the team; that is, the stakeholdes liase directly with the Product Owner for the teams’ backlog. And each product is worked on by only one team, so coordination needed is between products and not within products. I often Refer to this as team-level agile.

When we talk on scaled agile, we have coordination within a product as more teams pulls work from the same cross-team backlog. This cross-team backlog operates across teams and may therefore be referred to as a higher level. Usually 4-8 teams are grouped together, although examples of 10 and even 11 teams have been seen.

Such grouping of teams may repeat again, so that we could end up having 3, 4 or even 6 levels in the scaling agile structure within an organisation.

• Level 1: Teams (e.g. 5 teams)
• Level 2: Group of teams (e.g. 5 x 5 teams = 25 teams)
• Level 3: Groups of level 2-groups (e.g. 5 x 25 teams = 125 teams)
• Level 4: Groups of level 3-groups (e.g. 5 x 125 teams = 625 teams)
• Level 5: Groups of level 4-groups (e.g. 5 x 625 teams = 3,125 teams)
• etc.

If each team consist of 6 people average, then level 4 would include 3,750 persons, while level 5 would include 18,750, for the number of teams listed above.

Scaling Agile Frameworks

There are basically three ways to scale an agile organisation; 1) Apply a well-defined scaling agile framework. 2) Define your own structure, -or, 3) Form a hybrid of the two. In Denmark we have examples of all three approaches as described in the paper Scaled Agile Organisations in Denmark 2019, which you can read https://www.vilma-consulting.dk/papers/.

The most widely used and well-defined frameworks for scaling agile are SAFe, Nexus, Scrum@Scale and LeSS, all published between 2011 and 2018. Therefore we will focus on these four below.

Nexus

Nexus was developed by Ken Schwaber (co-founder of Scrum) and a group at Scrum Inc. The framework has been available since 2015.

Nexus is a further developments of Scrum, and is formed around repeating the structures of Scrum for several teams, and at two levels in the organisation. In other words, it is based on the analogy that a structure that works for teams, can work for teams of teams and beyond.

In brief, the framework works by having up to 8 teams in a Nexus (team of teams), where they all work from the same Product Backlog with only one Product Owner serving all teams. Team members from all teams participate in the Product Backlog refinement. All teams deliver one integrated potentially shippable product increment, which is demonstrated at the shared Nexus Sprint Review. To continually inspect and adapt, the teams hold a Daily Standup following the Nexus Daily Scrum, and Retrospectives at both team and Nexus level.  

Nexus works in 2 levels (team + team-of-teams), while Nexus+ works for 3 levels, with a number of Nexus’ in parallel.

The structure in a scaling agile framework is designed to optimise for a parameter. In this case Nexus optimises for value realisation. In other words, the objective when using Nexus is to maximise the realised (business) value via the potential shippable product increment done at the end of the iterations.

Scrum@Scale

Scrum@Scale was developed by Jeff Sutherland (co-founder of Scrum) and the framework has been available since 2018.

Scrum@Scale is a further development of Scrum, and is formed around repeating the structures of Scrum at multiple levels of the organisation. In other words, it is based on the condition that the structure that works for teams, can also work for teams of teams and all the way up to the portfolio level and C-level.

In brief, the framework works by having up to 5 teams in a team of teams. Each team has their own Product Backlog and Product Owner, where items are flowing from the Product Backlog at the team-of-teams level (Level 2) to the backlog at the team level (Level 1). Team members participate in the Product Backlog refinement at the team level.

At each level, there is at least one Product Owner with a Product Backlog. There is one Product Owner (PO) for each Team (Level 1), one Chief Product Owner (CPO) for each Team-of-Team (Level 2), one Chief Chief Product Owner (CCPO) for each Team-of-Team-of-team (Level 3) etc. And for each Product Owner (PO, CPO, CCPO etc) there is a Product Backlog.

The Product Owners (PO, CPO..) work in the Product Owner Cycle from strategic vision (at the highest level) to prioritised Product Backlogs at all levels prior to the teams Sprint Planning. And thereby ensure consistency from vision to each teams’ prioritised product backlog, at any time.

All teams deliver an integrated potentially shipable product increment, which is demonstrated at the teams Sprint Review at the end of the iteration. To continually inspect and adapt, the teams hold Daily Standup followed by Scrum-of-Scrums (Level 2), Scrum-of-Scrum-of Scrums (Level 3) etc until the top level is reached. As an example, an organisation with 3,750 persons would need 4 standup meetings of 15 minutes (60 minutes in total), to escalate from team to top level.

Further, the inspect and adapt workshop, the sprint retrospective, is held at the team level.

Scrum@Scale works for (in theory) any number of levels, starting from 2 and up.

The structure in a scaling agile framework is designed to optimise for a parameter. In this case Scrum@Scale optimises for value realisation. In other words, the objective when using Scrum@Scale is to maximise the realised (business) value via the potential shippable product increment done at the end of the iterations.

LeSS (Large Scale Scrum)

LeSS was developed by Craig Larman & Bas Wodde. The framework has been available since 2014. LeSS is a further development of the patterns that works for teams in Scrum, combined with organisational design, systemic design and Lean principles.

The starting point for LeSS is to reduce the organisational complexity (descale the organisation), prior to scaling the organisation. Thereby the amount of complexity, internal constraints and dependencies have been reduced, which in turn leads to that the scaled setup also becoming less complex. 

LeSS is centered around the product with the Product Owner having the full responsibility. From idea to shippable product, the idea is worked on by the Product Owner and the team, while relevant stakeholders shed light on relevant details. Effectively this means the teams are far more involved in the refinement process, from initial idea and until the item is ready to be pulled into a sprint.

All teams deliver one integrated potentially shipable product increment, which is then demonstrated at the shared Sprint Review. The continually inspect and adapt, is handled by the teams as and when needed. Retrospectives are held at both team (Level 1) and team-of-team level (Level 2).

LeSS works in 2 levels (team + team-of-teams), while LeSS Huge is 3 levels, still aligned in one Product Backlog and one Product Owner.

The structure in a scaling agile framework is designed to optimise for a parameter. The scaling agile framework LeSS is flexible as the organisation is reorganised and may optimise for the desired parameter eg value, secrecy, busyness or any other relevant parameter.

SAFe (Scaled Agile Framework)

SAFe was developed by Dean Leffingwell and was the first scaling agile framework to be released, as early as 2011. The current version 5.0 was released in 2020. SAFe combines Lean and agile principles into a set of lean-agile principles. SAFe is the only scaling agile framework that starts implementing scaling agile at team level and team-of-team level in parallel.

SAFe starts with the organisation’s portfolio level and Lean Portfolio Management. The objective is to have a lean enterprise with a clear description of roles and responsibilities. SAFe is not directly linked to neither Scrum nor Kanban, as teams are free to choose their structure, although within boundaries of a fixed cadence across teams. The cadence is typically 2 weeks iterations, bundled in five 2-week iterations as a longer planning horizon (PI).

The overview of the SAFe framework is actually four overview, depending on the size of the organisations. Above is shown the Full version, covering 4 Levels. Furthermore, there is a version for 2 levels named Essential SAFe, and two versions for 3 levels; Portfolio SAFe and Large Solution SAFe.

The structure in a scaling agile framework is designed to optimise for a parameter. In this case SAFe optimises for outcome. In other words, the objective when using SAFe is to maximise the outcome via the potential shippable product increment done at the end of the iterations.

Other Frameworks

Further, a number of organisations have been inspired by the structure formerly applied at Spotify. The structure has not been described to the same extent as the above mentioned frameworks, just as the people involved in forming the way of working at Spotify, did not consider it being a framework. Their way of working is described in videos, e.g. in these on YouTube here and here. 

The hybrids of scaling agile frameworks often combine one structure for the team level with one or more structures for the portfolio level. There is no clear recipe for the hybrids, but a number of them factor in Lean Portfolio Management.

So, which of the Scaling Agile Frameworks should I choose

Well, that is a very frequently asked question when we talk scaling agile. But first, you need to identify the goal of the scaling agile. What do you want to achieve?

Knowing the goal, you are ready to ask whether you should 1) de-scale the organisation, 2) start agile at team level (rather than start scaling agile at level 2+), or 3) scaling agile is the right next step for you.

Despite the simple nature of these questions, these steps should not be missed – just as you should not skip a step on a maturity model.

And the answer to the question on which scaling agile framework to choose. Well, it really depends on your context. There is no universally right, nor universally wrong framework. The right thing to do for you, is the one that brings you closer to the goal. And the goals are not identical across organisations, just as they are not identical across borders and business domains.

Recommendations

Before you embark on an agile transformation, consider why you want to transform to a scaling agile organisation, what you expect to achieve (the goal) from being a scaled agile organisation and whether you could descale the organisation (or do something else), to achieve the goal.

As the next step, make a comparison on how well 3-4 different scaling agile frameworks could assist you, considering both risk, cost and the people aspect of a transition. The comparison could be structured as a business case, and thereby comparable across alternatives.

When you have made the decisions to embark on scaling agile in your organisation, you are ready to make your first backlog, the transition backlog. And then prioritise the backlog by likelihood of bringing you closer to the goal.  

We at VILMA Consulting are ready to help you on all these steps.

So good luck starting – or continuing- with a scaling agile transformation!

Majken Vildrik Thougaard, Independent Agile Specialist & Owner of VILMA Consulting

PS: If you have started your scaling agile transformation time ago, there is plenty of inspiration to continuously improve to find in the other scaling agile frameworks. Could be if you are interested in Continuous Learning…