Something bigger than Scrum

A while back Scrum and Kanban were quite enough for the majority of the projects I worked with. Within the sustainable projects growing I had to think about alternative ways to build bigger teams without any fundamental processes transformations. After a recent Agile transformation project for one of the Global 500 clients, I decided to structure knowledge about Scaled approaches. I’ve been looking for such an article for a long time, but could only find some excerpts, that's why I decided to write it by myself.

Scrum of Scrums

Let’s start with the simple one: Scrum of Scrums. I'd hardly call it by a new framework or methodology. Basically we split a big Scrum team into sub-teams. Each team uses Scrum, in addition to daily stand-up we have one more daily meeting together with the ambassadors from each team. 

In simple terms, we just add one more meeting, where teams can synchronize their work. The frequency of such meetings can vary depending on business needs. Still, it is encouraged to have an additional daily stand-up at least twice a week. This particular meeting is called Scrum of Scrums. In rare cases, one more level - Scrum of Scrum of Scrums can be used.

Nexus

The next approach to review is Nexus. It is developed and maintained by Ken Schwaber and Scrum.org. Nexus is an extension of Scrum that allows you to coordinate the work of several teams on one increment. Like scrum, it consists of such elements as roles, ceremonies, and artifacts.

What is new: 

• A new role: Nexus Integration Team. It facilitates the coordination, coaching, monitoring and control of processes.
• New artifacts: Nexus Sprint Backlog and Integrated Increment. Teams work on a single Product Backlog, each of them has own Sprint Backlog during every Sprint. There is also Nexus Sprint Backlog - basically, a sum of all teams’ backlogs that ensures transparency of everybody’s work. Integrated Increment – the result of teams’ collaborative work. 
• New Ceremonies: they are, actually, not that new. Everything is same-as in Scrum, just a level higher and with the Nexus prefix:

1. Nexus Sprint Planning·       
2. Nexus Sprint Backlog 
3. Nexus Sprint Retrospective  
4. Nexus Sprint Review 
5. Nexus Daily Scrum (alike Scrum of Scrums) 

I believe that everyone familiar with Scrum is likely to understand the specifics of ceremonies listed above. You can read more about the approach here.

Let’s take a look at Nexus team in more detail. Nexus team is just another Scrum team aimed to resolve all integration issues. This team is responsible for the successful integration of the work done by all Scrum teams in Nexus. The integration includes dealing with all technical and non-technical cross-teams constraints that can prevent the Integrated Increment delivery during each sprint.

The composition of Nexus Integration Team can change over time to address current needs. Nexus Integration Team consists of:

• Product Owner 
• Scrum Master 
• One or more Integration Team members

Members of Nexus Integration Team may also work in scrum teams if it is possible and necessary. In this case, work in Nexus Integration Team is prioritized.

You can find more details about Nexus Integration Team here. 

LeSS and Less Huge

If our team grows to 20+ members, we add to Scrum one more sync-up meeting for teams’ representatives, thus getting Scrum of Scrums. Our team grows further, and there are already 30+ members, so we organize a separate team that integrates other teams’ work. We also add one more level of ceremonies: like in Scrum, just a level higher. We get Nexus. 

Lets further look at Large Scaled Scrum (LeSS). It resembles Nexus but still has some differences. Here are the common features of Less and Nexus:

• Up to 8 scrum teams  
• One Product Owner
• Common backlog  
• Common DoD
• Aligned sprints  
• Common increment

Differences between the two approaches:

• In LeSS, not just teams’ representatives, but a whole team is invited to the first stage of planning
• At the second stage, LeSS introduces the idea of concurrent planning
• Nexus is described in a single document, written in 12-pages document, while LeSS suggests resource database (less.works) with a description of numerous principles and practices  

When the number of teams exceeds 8, LeSS scales up to an expanded version - LeSS Huge.

What is in common between LeSS and LeSS Huge:

• One Product Backlog
• Common Definition of Done
• One Potentially Shippable Product Increment
• One (common) Product Owner
• Common, Synchronized Sprint 

The new LeSS Huge features comparing to LeSS:

• A new role - Area Product Owner. 
• New artifacts “Requirement areas” in Product Backlog and Area Backlog. 

So, sum up one more interim conclusion. As you can see from the article, we analyze approaches on a "simple-to-complex" basis. The first approach (Scrum of Scrums) as such has a form of additional meeting, the second one (Nexus) is indeed a clear extension of Scrum process, while the third and fourth approaches (LeSS and LeSS Huge) are not just processes, but a knowledge base containing information about various team-work related aspects. LeSS also contains hidden meaning in its name less not the only abbreviation for Large Scaled Scrum, but also synonym to lean. Comparing to the next framework it has less roles, less meetings and ceremonies, less artifacts. However, it work only when your product can be easily split into several streams and there are not too many cross dependencies between teams. If the modules of your system are closely coupled there are dependencies that needs to be figured out and tracked the next framework, which might be the better choice.

SAFe

The following approach is equally valuable as methodology and a set of best practices and body of knowledge (analogous to PMBoK in Agile world) - Scaled Agile Framework (SAFe). 

As the knowledge base is constantly updated and enlarged, it has versioning. At the time of this article writing, 4.6. version is up-to-date. SAFe does not appeal for something brand-new – it’s a mix of existing practices, united under one big umbrella. Its database is well-structured and has good navigation through the main page with clickable icons. So even if you do not plan to implement SAFe, you can just read about those aspects of Agile teamwork that are of interest to you.

SAFe consists of four-level and has four configurations.

? Scaled Agile, Inc.

Essential Configuration works up to 125 FTE (in real life it can be more). There are two levels here Program and Team. On the Team level SAFe follows Scrum, XP or Kanban. The only difference is PI Plannings and Planning and Innovation sprints. All teams should follow SAFe Principles and Core Values. Teams also should use the same duration of the iterations. One more deviation from the ScrumGuide is that SAFe differs Dev Team and Agile Team.

On the Program Level SAFe draws an analogy with trains as scheduled value pipeline. In sum, Agile Release Train is the program for 5-12 teams or 50-125 team members working on the same solution. By this level we have a new set of roles:

• Product Management - responsible for the content of work on the program level (for Release Train). Also supervise POs.
• System Architect - responsible for technical and architectural vision for the Release Train.
• RTE (Release Train Engineer) - facilitate and guide the work of ART.

Unlike Nexus where all members of Nexus team are peers to other team members in SAFe we have already hierarchy where Program level roles supervise Team Level. There are many other attributes and best practices on this level like: WSJF, Architectural Runway, DevOps and many others, but we are not going to stop here.

Similar to Nexus we have one more level of ceremonies here:

• Scrum of Scrums and PO sync-ups are just higher level of daily stand-up.
• Cadence - 8-12 weeks Program level iteration. As an outcome of it we have PI (Program Increment).
• Innovation and Planning Iteration - instead of backlog grooming we dedicate one full iteration to elaborate and elicitate the scope for the next cadence.
• PI Planning - similar to Sprint Planning, but one level higher.

Portfolio Configuration adds one more level to Essential Configuration. It provides needed processes, roles and tools to help organizations to meet their strategic objectives via building necessary systems and solutions.

From the role perspective we have another layer of similar three roles to the previous Program and Team Level:

• Lean Portfolio Management
• Epic Owners
• Enterprise Architect

Also, this configuration provides set of artifacts appropriate for this level. The most commonly used is another level of Backlog items called Themes and Epics. To resolve our solution by Themes, rather than by Epics, Feature, and User Stories we build classical WBS. Lean Portfolio Management offers similar to the Business Model Canvas called Portfolio Canvas even though it includes Lean approaches.

Large Solution Configuration designed for complex systems development that consists of several streams (ARTs). Portfolio level gives the governance on the enterprise level, aligning value streams with ARTs, while Large Solution gives the ability to grow the development team and number of streams within one product. In a nutshell Portfolio level is vertical scaling, Large Solution is horizontal scale. From all described above approaches Large Solution Configuration can be compared with LeSS Huge.

The structure of this level is similar to Program level. Instead of Agile Release Train on this level we have solution train, which consist from multiple ARTs. Solution train integrates all ARTs with enterprise mission and business goal. Enable coordination between ARTs, common vision, and goals. Three new roles are introduced on this level:

• Solution Management - responsible for the content of work on the large solution level (for Solution Train). Also, supervise PdMs.
• Solution Architect - responsible for technical and architectural vision for the Solution Train.
• STE (Solution Train Engineer) - facilitate and guide the work of Solution Train.

As you may notice they are very similar to the Program level.

Beside new roles we have a new set of meetings on this level:

As it is shown in the picture above on the Large Solution Level we have some common meetings with the Program level. For example, Prepare for PI Planning and Inspect & Adapt workshop. Some meetings are similar to Program Level but just occur on the higher level like Solution Demo and Solution Train Sync. Some are meetings that are quite new and serve to align the work of all ARTs together e.g. Architect Sync, Pre- and Post-PI Plannings.

Beside new roles and new ceremonies, there are other best practices that provide guidance and governance on this level e.g. Solution Intent, Solution Context, Economic Framework, etc.

The Full-cycle combines Portfolio Configuration and Large Solution Configuration creating scalable governance to drive multiple ARTs and align them with enterprise objectives.

A great summary of the SAFe hierarchy is presented in the article of Darren Wilmshurst in his blog.

This ERD Diagram shows the dependencies between different level of SAFe and how they interact with each other. Beside Enterprise version SAFe offers the best practices for the government.

Summarizing all listed above SAFe is a quite heavy framework, provides an extensive view on different aspects of the software development not covered by others (e.g. DevOps, Quality, Backlog structure). However, it works well for the large product with many internal cross dependencies. It is not always easy to split the product into several parts and just assign different teams to work on them, without any coordination. SAFe provides governance and supervision model for that up to the enterprise level.

A good story about approaching the different frameworks in one company is here.

The next approach seems even more alike a knowledge base or Agile Wikipedia than a framework or methodology. It affords tools and freedom to act but requires solid experience from its implementor. 

Disciplined Agile Delivery (DAD) will be the last in this review. First of all, let’s clarify what, as its authors call it, The Disciplined Agile (DA) is. It’s a process decision toolkit, or in other words, a set of tools for making process decisions. Namely, it gives guidance on how to choose processes depending on the situation.

DAD describes how different approaches work together and in which case they should be used. It has 4 levels alike SAFe but still differs in structure:

In this article, we will focus only on the first level of DAD. DAD is even more similar to PMBoK by its structure.

Its processes are organized into groups of processes. The processes are presented in the form of goals (it answers the questions that we want to achieve). Process groups correspond to project stages:

1.     Inception 

2.     Construction 

3.     Transition 

Additionally, DAD has a wide range of roles. There are Primary Roles that can be found at projects of any scale and Secondary Roles, which can appear on the scale for a temporary period on an as-needed basis. 

DAD describes itself as a toolkit that helps to select a proper approach, methodology, or framework from an existing range:

As the title implies, DAD is primarily focused on Delivery. A generalized description of the process description is presented below:

The audience is suggested to choose from 6 different types of the development lifecycle:

• The Agile lifecycle and The Continuous Delivery: Agile lifecycle. These lifecycles are based on Scrum and slightly expanded to ensure a well- functioning from start to finish.
• The Lean lifecycle и The Continuous Delivery: Lean lifecycle.  These lifecycles are Kanban-based.  
• The Exploratory/Lean Startup lifecycle. This lifecycle is based on the Lean Startup strategy.
• Program lifecycle. Lifecycle to organize the work of several teams. 

DAD team adapts the most suitable for its lifecycle. A more detailed description of how to select a lifecycle can be found here: A Full Agile Delivery Lifecycle 

Not so long time ago DAD was purchased by PMI.

These are the most common approaches/practices to work with large teams using Agile, but there are many more that are not listed here. Just to have a broader view on the "Agile World" please view this mind map.

As you can see above all frameworks are different and each should be picked based on the business needs and constraints. For better navigation among frameworks, you may use this excel file.

Talking about the most popular framework from my own observations is SAFe (due to good marketing) and Scrum of Scrums (due to simplicity). Latest polls confirm it:

Based on 2nd Annual Agile at Scale Report 2019:

Based on 2019 Scrum Master Trends Report:

Based on the 13th annual State of Agile report:

From my own perspective during the agile transformation consulting we provide for our clients it is not only important to choose the right framework, but also to adopt it properly, tailor, and maybe even adjust based on the circumstances.

And as always, there is no silver bullet :)