Scaled agile framework: Difference between revisions

Revision as of 06:30, 24 January 2024

Revision as of 08:29, 24 January 2024

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/wp-contentdefault/uploadsfiles/2024/01resource_asset/Serving-Federal-Customers-with-SAFe-Concepts%20Federal%20Customers%20Using%20Agile%2C%20SAFe%2C%20And%20CMMI%20Principles.pdf|journal=Capability Counts Conference Proceedings}}{{dead link|date=JanuarySeptember 20232022}} </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.

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 [https://www.leanwisdom.com/agile/safe-program-consultant-spc-certification SAFe Practice Consultant] (SPC) 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>

== See also ==