Scaled agile framework: Difference between revisions

Revision as of 05:55, 24 January 2024

Latest revision as of 09:43, 23 May 2025

(18 intermediate revisions by 10 users not shown)

Line 3:

The '''scaled agile framework''' ('''SAFe''') is a set of organization and workflow patterns intended to guide enterprises in [[Scaling of innovations|scaling]] [[Lean software development|lean]] and [[Agile software development|agile]] practices.<ref>{{Cite book|title=Scaling Agile Methods for Department of Defense Programs|last1=Hayes|first1=Will|last2=Lapham|first2=Mary Ann|last3=Miller|first3=Suzanne|last4=Wrubel|first4=Eileen|last5=Capell|first5=Peter|publisher=Software Engineering Institute|year=2016|id=CMU/SEI-2016-TN-005}}</ref><ref>{{Cite news|url=http://www.techradar.com/news/software/why-continuous-delivery-is-key-to-speeding-up-software-development-1282498|title=Why Continuous Delivery is key to speeding up software development|last=Athrow|first=Desiree|date=29 January 2015|work=TechRadar|access-date=2017-11-27}}</ref> Along with [[disciplined agile delivery]] (DAD) and S@S (Scrum@Scale), SAFe is one of a growing number of frameworks that seek to address the problems encountered when scaling beyond a single team.<ref>{{Cite web|url=https://www.infoq.com/news/2015/01/disciplined-agile-delivery|title=Scaling Agile with the Disciplined Agile Delivery Framework|last=Linders|first=Ben|date=January 22, 2015|website=InfoQ|access-date=2017-11-27}}</ref><ref>{{Cite book|title=Agile in-the-large: Getting from Paradox to Paradigm|last=van Haaster|first=K|publisher=Unpublished paper from Charles Sturt University|year=2014}}</ref>

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]].<ref>{{Cite journal|last=King|first=Michael|year=2017|title=Serving Federal Customers with SAFe Concepts|url=httpshttp://www.leanwisdomcmmiinstitute.com/blogsites/wpdefault/files/resource_asset/Serving%20Federal%20Customers%20Using%20Agile%2C%20SAFe%2C%20And%20CMMI%20Principles.pdf|archive-contenturl=https:/uploads/2024web.archive.org/01web/20171003030023/http://cmmiinstitute.com/sites/default/files/resource_asset/Serving-Federal-Customers-with-SAFe-Concepts%20Federal%20Customers%20Using%20Agile%2C%20SAFe%2C%20And%20CMMI%20Principles.pdf|url-status=dead|archive-date=October 3, 2017|journal=Capability Counts Conference Proceedings}}{{date=January 2023}} </ref>

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 [[Project stakeholder|stakeholders]]), through [[Project governance|governance]], [[Program management|program]], and [[Software developer|development teams]], out to [[customer]]s.<ref>{{Cite news|url=http://www.drdobbs.com/tools/real-agile-means-everybody-is-agile/240159622|title=Real Agile Means Everybody Is Agile|last=Bridgwater|first=Adrian|date=August 7, 2013|work=Dr. Dobb's|access-date=2017-11-27}}</ref><ref>{{Cite web|url=https://www.infoq.com/news/2014/08/death-by-planning-agile|title=Death by Planning in Agile Adoption|last=Linders|first=Ben|date=August 28, 2014|website=InfoQ|access-date=2017-11-27}}</ref> With the collaboration of others in the agile community, this was progressively refined and then first formally described in a 2007 book.<ref>{{Cite book|title=Scaling Software Agility: Best Practices for Large Enterprises|last=Leffingwell|first=Dean|publisher=Addison-Wesley|year=2007|isbn=978-0321458193}}</ref> 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, six major versions have been released<ref name="History of SAFe">{{cite web |title=About Scaled Agile Framework - A Brief History of SAFe |url=https://www.scaledagileframework.com/about/ |publisher=Scaled Agile Inc. |access-date=12 August 2020}}</ref> while the latest edition, version 6.0, was released in March 2023.<ref>{{Cite web|url=https://scaledagileframework.com/blog/say-hello-to-safe-6-0/|title=Say Hello to SAFE 6.0|date=15 March 2023 |publisher=Scaled Agile Inc|access-date=2023-03-16}}</ref>

While SAFe continues to be recognised as the most common approach to scaling agile practices (at 30 percent and growing),<ref>{{Cite web|url=https://www.stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report/473508|title=13th Annual State of Agile Report|date=2019|website=State of Agile Survey|publisher=CollabNet VersionOne|access-date=2019-08-27}}</ref><ref>{{cite journal|last1=Link|first1=P|last2=Lewrick|first2=M|date=29 September 2014|title=Agile Methods in a New Area of Innovation Management|url=http://www.brainguide.de/upload/publication/b0/2c3xg/c51b33fd2c6a9d032a7387f3273b9c62_1402133130.pdf|journal=Science to Business Marketing Conference}}</ref>{{page needed|date=April 2019}},<ref>{{cite web|url=http://computerworld.com.br/carreira/2015/01/28/profissionais-brasileiros-e-o-interesse-por-treinamentos-de-especializacao/|title=Profissionais brasileiros e o interesse por treinamentos de especialização|last=Baptista|first=Roberto|date=28 January 2015|publisher=Computerworld Brazil|access-date=28 January 2015}}</ref> it also has received criticism for being too [[Hierarchy|hierarchical]] and inflexible.<ref>{{Cite news|url=https://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/|title=unSAFe at any speed|last=Schwaber|first=Ken|author-link=Ken Schwaber|date=2013-08-06|work=Telling It Like It Is|access-date=2017-11-11}}</ref> It also receives criticism for giving organizations the illusion of adopting [[Agile software development|Agile]], while keeping familiar processes intact.<ref>{{Cite news|url=https://jeffgothelf.com/blog/safe-is-not-agile/|title=SAFe is not Agile|last=Gothelf|first=Jeff|author-link=Jeff Gothelf|date=2021-10-05|access-date=2023-05-21}}</ref>

Line 15:

=== 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.<ref>{{Cite book|title=Industrial challenges of scaling agile in mass-produced embedded systems.|last1=Eklund|first1=U|last2=Olsson|first2=H|last3=Strøm|first3=N|work=Agile Methods. Large-Scale Development, Refactoring, Testing, and Estimation|publisher=Springer International Publishing|year=2014|isbn=9783319143583}}</ref> 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.{{cn|date=September 2022}} The development teams will still get into detailed refinement 2-32–3 iterations ahead, only getting into detailed task plans for the next iteration.{{cn|date=September 2022}}

=== Keeping agile at abstract levels of responsibility ===

Line 24:

=== 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.<ref name=":1">{{Cite news |urllast=http://searchsoftwarequality.techtarget.com/answer/Scaling-Agile-development-calls-for-defined-practices-consultant-saysStafford |first=Jan |date=December 9, 2013 |title=Scaling Agile development calls for defined practices, consultant says |lasturl=Stafford|first=Jan|date=Decemberhttps://www.techtarget.com/searchsoftwarequality/definition/agile-software-development 9, 2013|work=SearchSoftwareQuality|access-date=2017-11-27}}{{dead link|datework=September 2022SearchSoftwareQuality}}</ref> 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.<ref name=":2" /><ref name=":3" />

=== Allowing time for innovation and planning ===

Line 30:

The SAFe planning cycle recommends including an additional iteration after a release, allowing teams to improve their practices and are ready for the next planning increment. Earlier editions of SAFe also designed this to be a ''hardening'' iteration, namely to stabilize or harden the product before releasing it. This was predicated on the complications of working with large integration environments where dependencies prevented several matters from being tested until the very end. SAFe was criticized for this because 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.<ref>{{Cite news|url=https://neilkillick.wordpress.com/2012/03/21/the-horror-of-the-scaled-agile-framework/|title=The Horror Of The Scaled Agile Framework|last=Killick|first=Neil|date=21 March 2012|work=Agile, Scrum, Kanban, Lean, and everything that's in between|access-date=2017-11-27}}</ref> This is not included in recent editions of SAFe.

==Implementation==

== Implementing SAFe: A 12-Step Roadmap ==

{{third-party|section|date=July 2018}}

=== Underlying principles of SAFe ===

Scaling Agile across an enterprise is challenging. To guide companies through the journey, SAFe defines a clear implementation roadmap with 12 key steps:

According to its authors, SAFe is based upon ten underlying concepts, which are derived from existing lean and agile principles, as well as observation:<ref name=":0">{{cite web|url=http://scaledagileframework.com/safe-lean-agile-principles/|title=SAFe Lean-Agile Principles|access-date=19 February 2016}}</ref>

# 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

#[[Decentralization|Decentralize]] decision-making

# Organize around value

SAFe has been criticized for aggregating too many disparate practices.<ref>{{Cite web|url=https://www.infoq.com/news/2013/08/safe|title=Has SAFe Cracked the Large Agile Adoption Nut?|last=Elssamadisy|first=Amr|website=InfoQ|access-date=2017-11-11}}</ref>

'''Reach the Tipping Point'''

Decide that change is needed due to business pressures or leadership vision. Identify the triggers necessitating a transformation.

=== The SAFe framework ===

'''Train Lean-Agile Change Agents'''

In SAFe version 5.1, there are four configurations: essential, portfolio, large solution and full:<ref>{{Cite book|url=https://books.google.com/books?id=qppNDwAAQBAJ|title=Enterprise Agility For Dummies|last=Rose|first=Doug|date=2018|publisher=John Wiley & Sons|isbn=9781119446095|pages=87–89|language=en}}</ref>

Certify key personnel as SAFe Program Consultants (SPCs) to lead the change. SPCs understand the framework and can coach teams.

* 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).

'''Train Leaders'''

* 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]].

Educate executives, managers, and leaders on SAFe so they can exemplify the new mindset. Leading SAFe certification is ideal.

* Portfolio SAFe includes concerns for strategic direction, investment funding, and lean governance.

* Full SAFe combines the other three levels.

=== Certifications ===

'''Create a Center of Excellence'''

Scaled Agile provides [[Professional certification (computer technology)|certifications]] that cover different areas and knowledge levels.<ref>{{cite web|url=http://www.scaledagile.com/which-course/|title=Certification|work=Scaled Agile|access-date=19 February 2016}}</ref>

Establish a team to drive adoption, train practitioners, facilitate value stream mapping, and foster communities of practice.

'''Identify Value Streams and ARTs'''

Map product delivery processes from idea to customer to surface key steps, flows, and cycle times. Organize Agile Release Trains (ARTs) around value streams.

'''Create an Implementation Plan'''

Outline the rollout sequence. Typically begin with one ART and plan activities over the next 2-3 Program Increments (PIs).

'''Prepare for the ART Launch'''

Train those in key roles (Product Owners, Scrum Masters, etc.) on how SAFe impacts their responsibilities.

'''Train Teams and Launch the ART'''

Educate the developers, testers, etc. who build solutions. Then conduct the first PI Planning to launch that ART.

'''Coach ART Execution'''

Help launch Scrums, iterations, inspect & adapt events, and facilitate coordination for maximum value delivery.

'''Launch More ARTs'''

After the first ART demonstrates progress, expand to new ARTs aligned to other value streams.

'''Extend to the Portfolio'''

Once multiple ARTs are humming, apply SAFe portfolio principles to strategy, budgeting, governance, and funding flows.

'''Accelerate'''

Benchmark progress with assessments. Apply learnings across the organization to increase agility.

In summary, this roadmap allows methodical SAFe adoption by engaging people across the company to iteratively build capabilities.

<ref>[https://www.leanwisdom.com/blog/safe-implementation-roadmap </ref>SAFe Implementation Roadmap

== See also ==