Set of organization and workflow patterns intended to guide enterprises in scaling lean and agile practices
The Scaled agile framework (SAFe) is a set of organization and workflow patterns intended to guide enterprises in scaling lean and agile practices.[1][2] Along with large-scale Scrum (LeSS), disciplined agile delivery (DAD), and Nexus, SAFe is one of a growing number of frameworks that seek to address the problems encountered when scaling beyond a single team.[3][4] SAFe is made freely available by Scaled Agile, Inc., which retains the copyrights and registered trademarks.[5]
SAFe promotes alignment, collaboration, and delivery across large numbers of agile teams. It was developed by and for practitioners, by leveraging three primary bodies of knowledge: agile software development, lean product development, and systems thinking.[6]
The primary reference for the scaled agile framework was originally the development of a big picture view of how work flowed from product management (or other stakeholders), through governance, program, and development teams, out to customers.[7][8] With the collaboration of others in the agile community, this was progressively refined and then first formally described in a 2007 book.[9] The framework continues to be developed and shared publicly; with an academy and an accreditation scheme supporting those who seek to implement, support, or train others in the adoption of SAFe.
Starting at its first release in 2011 already five major versions have been released[10] while the latest edition, version 5.1, was released in February 2021.[11]
While SAFe continues to be recognised as the most common approach to scaling agile practices (at 30 percent and growing),[12][13][page needed],[14] it also has received criticism for being too hierarchical and inflexible.[15]
Challenges of scaling agile principles and practices
Coping with longer planning horizons
Development teams typically refine their backlog up to two to three iterations ahead, but in larger organizations the product marketing team needs to plan further ahead for their commitments to market and discussions with customers.[16] They will often work with a very high level, 12 to 18-month roadmap, then plan collaboratively with the teams for three months of work.[17] The development teams will still get into detailed refinement 2-3 iterations ahead, only getting into detailed task plans for the next iteration.[18]
Keeping agile at abstract levels of responsibility
While development teams have a number of frameworks that define how they should be agile, there is very little that describes this for management. SAFe delivers many of the same principles, such as cross-functional teams, to the groups that handle the more abstract levels of responsibility and planning (product and portfolio).[19] SAFe has also been criticized for aggregating too many disparate practices.[20]
Dealing with delegated authority
In Scrum, the product owner is expected to assume responsibility for the full product life-cycle, including the return on investment of development decisions, as well as performance in market. On large-scale developments, the organization wants a view across multiple team backlogs, such as provided by a product manager.[21] Although SAFe assumes the product owner role sits with product management, it has nonetheless been criticized for separating product owners into the development organization.[22]
Synchronizing deliverables
Agile frameworks are designed to enable the development team to be autonomous and free to design how they work. SAFe acknowledges that, at the scale of many tens or hundreds of development teams, it becomes increasingly chaotic for teams to fully self-organize.[23] It therefore puts some constraints on this, so that where teams are working on the same product, their deliverables can be better synchronized for releasing together, although this has been one area in which SAFe has been criticized.[21][22]
Allowing time for innovation and planning
The SAFe planning cycle recommends including an additional iteration after a release, so that teams can improve their practices and are ready for the next planning increment. Earlier editions of SAFe also designed this to be a hardening iteration, that is to stabilize or harden the product before releasing it. This was predicated on the complications of working with large integration environments where dependencies meant that you could not test everything until the very end. SAFe was criticized for this as it represented an anti-agile or waterfall element, but was in line with lean 90-day increments which make 13 weeks, and if doing two-week sprints you need six of them plus a one-week planning or hardening cycle.[24] This is not included in recent editions of SAFe.
Implementation
This section may rely excessively on sources too closely associated with the subject, potentially preventing the article from being verifiable and neutral. Please help improve it by replacing them with more appropriate citations to reliable, independent, third-party sources.(July 2018) (Learn how and when to remove this template message)
Underlying principles of SAFe
According to its authors, SAFe is based upon ten underlying concepts, which are derived from existing lean and agile principles, as well as observation:[25]
Take an economic view
Apply systems thinking
Assume variability; preserve options
Build incrementally with fast integrated learning cycles
Base milestones on objective evaluation of working systems
Visualize and limit work-in-progress, reduce batch sizes, and manage queue lengths
Apply cadence (timing), synchronize with cross-domain planning
Unlock the intrinsic motivation of knowledge workers
Decentralize decision-making
Organize around value
The SAFe framework
In SAFe version 5.1, there are four configurations: essential, portfolio, large solution and full:[26]
Essential SAFe is the most basic configuration. It describes the most critical elements needed and is intended to provide the majority of the framework's benefits. It includes the team and program level (which it calls agile release trains or ARTs).
Large Solution SAFe allows for coordination and synchronization across multiple programs, but without the portfolio considerations. In earlier versions of SAFe, this level was referred to as value stream.
Portfolio SAFe includes concerns for strategic direction, investment funding, and lean governance.
Full SAFe combines the other three levels.
Certifications
Scaled Agile provides certifications that cover different areas and knowledge levels.[27]
^Hayes, Will; Lapham, Mary Ann; Miller, Suzanne; Wrubel, Eileen; Capell, Peter (2016). Scaling Agile Methods for Department of Defense Programs. Software Engineering Institute. CMU/SEI-2016-TN-005.
^Schwaber, Ken (2013-08-06). "unSAFe at any speed". Telling It Like It Is. Retrieved 2017-11-11.
^Eklund, U; Olsson, H; Strøm, N (2014). Industrial challenges of scaling agile in mass-produced embedded systems. Agile Methods. Large-Scale Development, Refactoring, Testing, and Estimation. Springer International Publishing. ISBN 9783319143583.
^Stettina, C; Horz, J (2015). "Agile portfolio management: An empirical perspective on the practice in use". International Journal of Project Management. 33 (1): 140–152. doi:10.1016/j.ijproman.2014.03.008.
^Laanti, M (2014). Characteristics and Principles of Scaled Agile. XP 2014 Workshops. Springer International Publishing.
^ abVaidya, A (2014). Does DAD Know Best, Is it Better to do LeSS or Just be SAFe? Adapting Scaling Agile Practices into the Enterprise. Excerpt from PNSQC 2014 Proceedings. pp. 8–9.
Heusser, Matthew (17 June 2015), Introducing the scaled agile framework, CIO, pp. 1–2 — contains a review of the pros and cons of the methodology and concludes it is a half-way-house to a fully agile system.
Leffingwell, Dean (2011), Lean Requirements Practices for Teams, Programs, and the Enterprise, Addison-Wesley Professional, ISBN 978-0321635846
10:57
