Thu Anh Pham

SAFe (Scaled Agile Framework) — an introduction

SAFe

SAFe is a template to scale Agile to large organisations. It has two to four levels:

  • Team level
  • Program level
  • Large solution level (optional)
  • Portfolio level (optional)

Here’s a picture used to show Full SAFe, the most complete version of the Scaled Agile Framework:

SAFe

Team level

At the team level (called Agile team) SAFe says to work just like Scrum, however teams can also work in Kanban or Scrumban. Teams work together to deliver working software every two weeks. The Product Owner is responsible for the Team Backlog. Iteration Planning, Stand-up Review and Retrospective are more or less the same as their standard Scrum equivalents. However SAFe is proposing all kinds of best practices. Then there’s Built-In Quality. Built-In Quality are practices that should be followed for every increment. This resembles the Definition of Done from Scrum, although the latter is determined by the Development Team. SAFe also works with a Definition of Done on team level, but this is basically overshadowed by “Built-In Quality”.

Program Level

At the program level SAFe says to work with exactly the same elements, but then scaled. Here we are talking about multiple teams working to deliver something together. This can be scaled to up to 150 people. The teams work to create a Program Increment, to be delivered after 5 Sprints (10 weeks).

The teams and stakeholders together are called the Agile Release Train. Agile Release Trains are aligned to a common business or technology mission. They plan, develop and deploy together.

The apparent advantage of Agile Release Trains is that they have a set frequency (about every 10 weeks). Business features that miss a train can catch the next train. Releasing is typically decoupled from development cadence.

The content for each Release Train, a Potentially Shippable Increment, is determined by a Product Manager by means of a Program Backlog. This Program Backlog has most of the items that fill the Team Backlogs. The Release Train Engineer is the train Scrum Master, equivalent to a Program Manager (according to SAFe).

A Program Increment starts with a Planning meeting which has everyone from the teams attending. The vision and the roadmap for the train are determined. Then the teams break up to discuss what they can do within the train while aligning with other teams. They basically look a number of Sprints ahead on feature level, unlike Scrum does (Scrum only plans one Sprint ahead to optimize empiricism). Then the commitments of the teams are mapped on a Program Board, including dependencies between teams.

Scrum Masters and the Release Train Engineer have bi-weekly meetings to make sure that the goals remain within reach. The aim is to have the whole train sprinting together and that teams are not working ahead or lagging.

At this level there are four Sprints to deliver the Potentially Shippable Increment. The fifth Sprint is for hardening, innovation and planning. This is also unlike standard Scrum. Hardening is for a final verification and for testing. Innovation is about exploring new ideas. Planning entails the demo on program level, maintenance on the train and the planning for the next cycle of 10 weeks.

This level also has the architectural runway. In each 10 weeks cycle you are to lay down the tracks for the next 10-week cycle. This is the responsibility of the architect.

Large Solution Level

This level is intended to manage large solutions that can’t be handled by a single program (Agile Release Train). The larger solution is coordinated by a Solution Train, consisting of a Solution Manager, Solution Architect and a Solution Train Engineer. They align and coordinate multiple Agile Release Trains.

Portfolio Level

Portfolio Management dictates the direction of the trains by allocating the budget. At this level a Backlog of Portfolio level Epics which will trickle down to the trains Product Managers. Kanban is used at this level to limit the overhead.

Four flavours

  • SAFe has four different flavours:
  • Essential SAFe, consisting of Team level and Program level
  • Large solution SAFe, consisting of Team level, Program level and Large solution level
  • Portfolio SAFe, consisting of Team level, Program level and Portfolio Level
  • Full SAFe, consisting of all four levels.

SAFe

Here are some items where SAFe differs from Scrum

SAFe recognizes many different roles that work outside of the Scrum area. SAFe also deviates from Scrum on some other pivotal areas:

  • Product Owners don’t own the Product Backlog but instead own the Team Backlog. This Team Backlog is filled from the Program Backlog, owned by the Product Manager. The Program Backlog is — in full SAFe — filled from Portfolio level or Large Solution level.
  • SAFe works with Design Sprints, not supported by Scrum. You wish to deliver “a potentially releasable Increment of “Done” product at the end of each Sprint.” — Scrum Guide 2017
  • SAFe works with Architectural Runways, not supported by Scrum for the same reason
  • SAFe has Hardening Sprints, not supported by Scrum for the same reason.

There are many more differences, but these are the crucial ones in my book.

Bottom Line

SAFe is created to cater for large organisations with large solutions where alignment is deemed key. As a result, SAFe prescribes many practices on 4 different levels and recognises many roles. SAFe adds a lot of roles, events and artifacts to Scrum. It is by far the heaviest known scaling framework of Agile practices.

Source: https://medium.com/serious-scrum/safe-scaled-agile-framework-an-introduction-b30bae91ebf6