SAFe
Origin
Dean Leffingwell, author of Agile Software Requirements (2011), developed SAFe based on his experience advising large organizations on the adoption of agile practices. The first public version (SAFe 1.0) was published on scaledagileframework.com in 2011. SAFe has evolved significantly: version 6.0, released in 2023, incorporates Business Agility as the top level and extends its scope beyond software development.
Level structure
SAFe organizes work into levels that reflect the different scales of the organization:
Team level
The base level: agile teams of 5-11 people working in 2-week iterations (equivalent to sprints). At this level, SAFe is compatible with Scrum, Kanban, or a combination of both.
Program Level (ART)
Teams are organized into an Agile Release Train (ART): a virtual group of between 50 and 125 people who plan, commit, and execute together. The central event is PI Planning (Program Increment Planning): a two-day, in-person session held every 8-12 weeks, in which all the teams in the ART plan the next program increment in a coordinated way.
Large Solution level
For ARTs that must coordinate with other ARTs or with external suppliers to build complex solutions. It includes a Solution Train with specific roles and events.
Portfolio level
It connects business strategy with agile execution through Lean Portfolio Management (LPM). It defines value streams, prioritizes strategic investments, and ensures that the teams' work is aligned with business objectives.
Lean-Agile Principles
SAFe is built on ten Lean-Agile principles, which include: taking an economic view, applying systems thinking, assuming variability and preserving options, building incrementally with fast, synchronized learning cycles, and empowering those who do the work.
SAFe in Perspective
SAFe is the most widely adopted scaling framework in large and medium-sized enterprises, especially in sectors such as banking, insurance, telecommunications, and defense. Its strength is its comprehensiveness: it has an answer for almost any organizational question. Its weakness is that same comprehensiveness: it can add a significant bureaucratic burden if adopted without judgement.
Critics point out that SAFe can reproduce a predictive project management mindset using agile vocabulary, especially if PI Planning becomes an exercise in detailed long-term planning rather than an adaptive alignment session.
Common mistake
Adopting SAFe without mature agile teams at the base. SAFe assumes that individual teams already work well autonomously and need coordination. If the teams at the team level are not fluent in Scrum or Kanban, adding the SAFe structure amplifies the problems instead of solving them. Fixing the team level first delivers more value than adding a coordination structure on top of dysfunctional teams.
References
- Leffingwell, Dean. (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley.
- SAFe official website.
See also
Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.