The Scaled Agile Framework (abbreviated as SAFe) is a collection of organizational and workflow guidelines designed to guide organizations in scaling lean and agile practices.
In addition to large-scale Scrum (LeSS), disciplined agile delivery (DAD) and Nexus, SAFe is one of a growing number of frameworks aimed at solving the challenges faced when scaling beyond a single team. This was developed by and for practitioners through incorporating three main knowledge bodies:
- agile software development
- lean product development
- system thinking
Initially, the main context for the scalable agile framework was to develop a broad picture view of how research worked from product management (or other stakeholders), through management, program and development teams.
Version 4.5, published in June 2017, while the new version, version 5.0, was published in January 2020.
While SAFe continues to be recognized as the most common approach to scaling agile practices (at 30 percent and increasing) , it is often criticized for being too hierarchical and inflexible. SAFe imparts many of the same values, such as cross-functional teams, to organizations concerned with the more complex levels of accountability and preparation (product and portfolio) SAFe has often been criticized for aggregating so many different practices.
Working with delegated authority In Scrum, the product owner is required to assume full product life cycle accountability. For large-scale projects, the company needs a view of numerous team backlogs, as given by a product manager.
SAFe assumptions and restrictions
While SAFe assumes the position of the product owner with product management, it has also been criticized for separating product owners into the development organization. SAFe admits that, on the scale of several tens or hundreds of development teams, it is becoming increasingly difficult for teams to completely self-organize. Thus, it puts some restrictions on this, so that where teams are working on the same product, their deliverables can be better organized for release together, although this was one area where SAFe was criticized.
SAFe’s earlier versions have conceived this as a hardening version, that is to stabilize or harden the commodity before publishing it. It was focused on the complexities of dealing with large integration environments where dependencies meant that, until the very end, you couldn’t check anything. SAFe has been criticized for this, because it was an anti-agile or waterfall element. It is not included in recent SAFe versions.
SAFe’s underlying principles according to its founders, SAFe is based on ten fundamental concepts, derived from current lean and agile principles, as well as observation:
- Take an economic view
- Apply systems thinking
- Assumes variability; retain options
- Build incrementally with quick integrated learning cycles
- Base milestones on objective evaluation of working systems
This defines the most important elements required and attempts to deliver the benefits of the remainder of the system. This requires the level of the team and the software (called agile release trains, or ARTs). Full SAFe is a combination of the other three levels.
The SAFe portfolio contains issues about:
- strategic direction
- investment management
- lean governance
Wide Solution SAFe allows communication and synchronization across various programs, but without considerations of the portfolio. This level was called value stream in earlier versions of SAFe.
Let us know your thoughts.