Scaling Agile Methodology Comparison

Why?

I was originally writing an article on why I think the basics of Agile are often the root of the problem when it comes to scaling your practice. I started putting together a quick overview of the first scaling levels of the four most popular (in my opinion) scaling methodologies. When the overview became a third of my original article, I decided to move it to its own space to allow people to review it at their leisure.

Yes, this has been done before. Kendis.io compared SAFe®, LeSS, Nexus™, and Spotify (not a scaling model, or intended for use by anyone other than Spotify). I wanted to do this research for myself, to make sure I was coming at it from the right angle, so here it is.

What?

This comparison is from the perspective of structure, roles, artifacts, and events. It covers, primarily, the next level up from the team though it does touch a little higher up in some places.

It is not meant to be exhaustive, and every practitioner should do their due diligence before recommending (for or against) a framework. This is intended as informational, and I am not speaking as a representative of any of these frameworks.

No alt text provided for this image

SAFe®

The latest version of SAFe (5.0) has an “Essential” level which is the first level of scale. There are a lot of pieces of SAFe, having more to do with organizational values and competencies, but I’m going to focus on the nuts and bolts pieces, as far as the team scaling. 

Structure: Virtual organization, called an Agile Release Train (ART) which they roughly define as 50-125 people, made up of individual teams, organized around a Value Stream.  

New Roles:

  • Release Train Engineer (RTE) – “Servant leader and coach for the Agile Release Train (ART)”. Chief Scrum Master, facilitates major events and optimizes the value of the Train.
  • Product Management – Collaborates to identify and define customer needs, context, and plans to meet those (Vision, Roadmap, Features, etc). Supports the ART in delivering value. SAFe sums up the responsibilities as “Meet business goals, get it built, get it off the shelf, and leverage support”. This role manages the Program Backlog, which is the central Feature backlog that the teams work on to deliver.
  • System Architect/Engineer – Defines and communicates the shared technical and architectural vision for the ART.
  • Business Owners – SAFe incorporates this as a role but represents your key stakeholders.

New Artifacts:

  • Program Backlog/Kanban – Program level backlog of Features (SAFe Features = Jira Epic delivered by a Feature team), which include business value and enabling Features, progress measured through a Kanban board.
  • Program Epics – Sets of Features delivered by an ART
  • PI Objectives – Program objectives with assigned business value, separate from individual team story-delivery-reliability, Teams also have Team-level Objectives in a given PI.
  • Vision/Roadmap/Architectural Runway – Program level artifacts to align the business focus and architectural path for the ART.
  • There are more artifacts at higher levels of scale for SAFe, but this is plenty to chew on.

New Events:

  • Backlog refinement – A Program level backlog means the Product Owners, in conjunction with the Product Management, refine the Program Backlog.
  • Program Increment (PI) – Not an event, but an established cadence of 8-12 weeks. 
  • PI Planning – A once every PI planning exercise involving all Teams on the ART, predominantly face-to-face, to plan and commit to Feature delivery for a given PI. The goal is an alignment of all teams for a shared mission. 
  • Scrum of Scrums – Periodic (weekly or bi-weekly) stand-up for Scrum Masters on each team, facilitated by the RTE, to coordinate dependencies and provide visibility.
  • Product Owner (PO) Sync – Visibility to objectives, discuss problems or opportunities and discuss scope changes
  • ART Sync (optional) – Combines, and replaces, the prior two events. Provides visibility, discussion of dependencies and issues, and scope discussions. 
  • System Demo – Integrated demo held periodically throughout the Program Increment to demonstrate the Feature(s) being delivered by the ART. (Teams are still expected to hold a Demo every Sprint)
  • Inspect & Adapt – ART level retrospective workshop, held once/PI. (Teams are still expected to hold a retrospective every Sprint)

LeSS

Standard LeSS implementation is very bare, so this takes a look at a combination of LeSS and LeSS Huge options.

New Roles: 

  • Scaled Product Owner – responsible for overall Product Backlog, with whole-product focus. LeSS states that in other large-scale product groups there are many Product Managers, which this one PO takes the place of, and LeSS removes the team-based PO for standard LeSS.
  • Area Product Owner – LeSS reintroduces a lower layer PO for LeSS Huge, where it is needed to have area focus instead of the overall product. 
  • Communities of Practice – LeSS expects practice areas to organize around themselves for technical excellence, and are voluntary.

New Artifacts:

  • Product Backlog – Centralized Product Backlog managed by the Scaled PO. Teams don’t have a Product Backlog, only Sprint Backlogs pulling work from the one Product Backlog.
  • Definition of Done (DoD) – LeSS requires a centralized Definition of Done for all teams.

New Events:

  • Sprint Planning One – Planning meeting with all Teams meant to divvy up work from the Product Backlog into the Sprint.
  • Sprint Planning Two – Just a new name for the standard team-level Sprint planning.
  • Scrum of Scrums – Not actually recommended in LeSS, but accepted as an option if it’s an existing event working for the team. Worth noting that there is no scaled communication/daily scrum in LeSS, but the expectation is that it is the responsibility of each team to work together as needed. For teams that work together, it is recommended to send silent observers to the other team’s Daily Scrum.
  • Multi-team meetings (optional): Additional meetings/events as needed for teams to work together effectively
  • Leading Teams (optional): For large Features, a team may take a lead role in keeping track and synchronizing the work of multiple teams
  • Sprint Review – Sprint review happens at a Product level, involving all teams. 
  • Overall Retrospective – Similar to SAFe®’s Inspect & Adapt, the Overall Retrospective is attended by all teams. 
  • Product Backlog Refinement (PBR) – PBR is expected to be done at the overall product level, as well as the team and multi-team level. 

Nexus™

Nexus plans for an “integrated increment” so the structure is around scaling the existing Scrum practice. 

New Roles:

  • Nexus Integration Team – The Scrum Master and Product Owner are joined by “Nexus Integration Team Members”. The Nexus guide isn’t prescriptive on who/how many of these people exist, but their purpose is to “…coordinate, coach, and supervise the application of Nexus and the operation of Scrum so the best outcomes are derived”. The Integration Team members may come from other existing teams. The Product Owner appears to be consolidated in this one role, but the Scrum Master is separate though they may be the Scrum Master of another team.

New Artifacts:

  • Product Backlog – There is one single Product Backlog.
  • Nexus Sprint Backlog – I expect this is the Product level Sprint Backlog, representing all the teams’ work selected for the given Sprint. 
  • Integrated Increment – Sum of work completed in a Sprint by all teams in the Nexus.
  • Nexus Sprint Goal – Nexus level Sprint Goal
  • Definition of Done (DoD) – Central DoD defined by the Nexus Integration Team

New Events:

  • Refining the Backlog – Similar to LeSS 
  • Nexus Sprint Planning – Attended by representatives from each team, the Product Backlog is reviewed and work selected for the Nexus Sprint Backlog.
  • Nexus Daily Scrum – a Scrum of Scrums attended by appropriate representatives from each team to discuss integration issues. 
  • Nexus Sprint Review – Review covering all the work in the Integrated Increment 

Scrum @ Scale

Scrum @ Scale wants an organization to have a strong Reference Model to base the scaled organization on. New may also mean “additional”.

New Roles:

  • Scrum of Scrums (SoS) Team – Team of scrum masters, representing the teams they are scrum masters for. Acts as a Release Team, and has the same roles, artifacts, and events as any other Scrum team.
  • Release/Integration Team (optional) – Team formed to overcome “engineering deficiencies” identified by the SoS Team.
  • Scrum of Scrums Master (SoSM) – Accountable for the release of the SoS team’s efforts. NOTE: This then scales directly, so SoSoS and SoSoSM
  • Executive Action Team – “Final stop” for impediments that can’t be solved by the below SoS teams. Has a PO and an SM.
  • MetaScrum – Team of Product Owners, similar to the SoS Team.
  • Chief Product Owner(s) – Coordinate priorities among POs in the MetaScrum. NOTE: This also then scales directly, and is a separate team and structure from the SoS. Chief of Chief Product Owners (CCPO) w/associated MetaScrums.
  • Executive MetaScrum – Similar to the EAT, this is the top of the PO scaling
  • Knowledge and Infrastructure Teams (optional) – At certain levels of scale, it may make sense to have Knowledge teams (Communities of Practice) or Infrastructure Teams, virtual teams of specialists.

New Artifacts:

  • All the backlogs. All of them. Being “scale-less” each team operates as an individual Scrum team would and has it’s own (visible) backlog. So not new, per se, but there are a whole lot more of them when scaling in this model.
  • PO Organizational Items – Strategic Vision, Backlog Prioritization, Backlog Decomposition & Refinement, and Release Planning. All of this is intended to communicate the necessary information to have all the teams below the EAT and EMS do what they need to do.

New Events:

  • Feedback Cycles – All of the various layers will require the same feedback cycles as any Scrum team. Again, not a new event per se, but the expectations at scale are different. 
  • Metrics – S@S expects metrics to help an organization assess progress, “and inspect and adapt products and processes”.