Scaled Agile Framework (SAFe)

The definition of Scaled Agile Framework (SAFe)

The Scaled Agile Framework (SAFe) was created by Dean Leffingwell–a devout Lean-Agile practitioner and author–as a way to systematically scale Agile throughout larger software organizations.

It has evolved over the years as the founder and other SAFe contributors have learned to apply the principles more efficiently and to an audience beyond the technology organization within a company.

The framework comprises a set of roles, ceremonies (activities), and artifacts (inputs and outputs) that help scale agile more efficiently.

SAFe has four different configurations, depending on an organization’s size, needs, and complexity. Each configuration adds in additional layers and processes.

Essential SAFe is the most basic and is typically where an organization will start, even if it plans to scale up to Large Solution SAFe or beyond.

There are two groups of SAFe roles which represent the two “layers” of Essential SAFe, the simplest configuration of the framework:

  • Program Level - Product managers, system architects & engineers, and the Release Train Engineer (RTE).
  • Team Level - Engineers, QA, dev managers, product owners.

The ceremonies, or activities, are similar to Scrum but add in higher-level activities centered around the Program (a group of teams making up the Agile Release Train) and deal with planning the Program Increment (PI), which is the set period of 8-12 weeks where the whole group focuses on a common set of objectives. These ceremonies are the Pre- and Post-PI Planning meetings and the PI Planning Event.

More advanced SAFe configurations utilize Pre- and Post-PI Planning, but all configurations require the PI Planning Event. This is the grand ceremony of SAFe and is essential to its function and success.

The primary artifact or output of PI Planning is the Program Board. This is a sprint-by-sprint program-level representation of what the organization has committed to delivering during the program increment (PI) and is used throughout the PI as a blueprint and to track progress. Additionally, the Program Board will highlight inter-team dependencies and key milestones.