Jump to content

Scaled agile framework

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Gowtham819 (talk | contribs) at 06:27, 24 January 2024 (Minor spelling mistake). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Part of a series on
Software development
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Practices
Tools
Standards and bodies of knowledge
Glossaries
Outlines

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 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.[3][4]

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.[5]

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.[6][7] With the collaboration of others in the agile community, this was progressively refined and then first formally described in a 2007 book.[8] 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[9] while the latest edition, version 6.0, was released in March 2023.[10]

While SAFe continues to be recognised as the most common approach to scaling agile practices (at 30 percent and growing),[11][12][page needed],[13] it also has received criticism for being too hierarchical and inflexible.[14] It also receives criticism for giving organizations the illusion of adopting Agile, while keeping familiar processes intact.[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.[citation needed] The development teams will still get into detailed refinement 2-3 iterations ahead, only getting into detailed task plans for the next iteration.[citation needed]

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).[citation needed]

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.[17] Although SAFe assumes the product owner role sits with product management, it has nonetheless been criticized for separating product owners into the development organization.[18]

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.[19] 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.[17][18]

Allowing time for innovation and planning

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.[20] This is not included in recent editions of SAFe.

Implementing SAFe: A 12-Step Roadmap

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

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

Train Lean-Agile Change Agents Certify key personnel as SAFe Program Consultants (SPCs) to lead the change. SPCs understand the framework and can coach teams.

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

Create a Center of Excellence 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. [21]

See also

References

  1. ^ 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.
  2. ^ Athrow, Desiree (29 January 2015). "Why Continuous Delivery is key to speeding up software development". TechRadar. Retrieved 2017-11-27.
  3. ^ Linders, Ben (January 22, 2015). "Scaling Agile with the Disciplined Agile Delivery Framework". InfoQ. Retrieved 2017-11-27.
  4. ^ van Haaster, K (2014). Agile in-the-large: Getting from Paradox to Paradigm. Unpublished paper from Charles Sturt University.
  5. ^ King, Michael (2017). "Serving Federal Customers with SAFe Concepts" (PDF). Capability Counts Conference Proceedings.Template:Date=January 2023
  6. ^ Bridgwater, Adrian (August 7, 2013). "Real Agile Means Everybody Is Agile". Dr. Dobb's. Retrieved 2017-11-27.
  7. ^ Linders, Ben (August 28, 2014). "Death by Planning in Agile Adoption". InfoQ. Retrieved 2017-11-27.
  8. ^ Leffingwell, Dean (2007). Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley. ISBN 978-0321458193.
  9. ^ "About Scaled Agile Framework - A Brief History of SAFe". Scaled Agile Inc. Retrieved 12 August 2020.
  10. ^ "Say Hello to SAFE 6.0". Scaled Agile Inc. Retrieved 2023-03-16.
  11. ^ "13th Annual State of Agile Report". State of Agile Survey. CollabNet VersionOne. 2019. Retrieved 2019-08-27.
  12. ^ Link, P; Lewrick, M (29 September 2014). "Agile Methods in a New Area of Innovation Management" (PDF). Science to Business Marketing Conference.
  13. ^ Baptista, Roberto (28 January 2015). "Profissionais brasileiros e o interesse por treinamentos de especialização". Computerworld Brazil. Retrieved 28 January 2015.
  14. ^ Schwaber, Ken (2013-08-06). "unSAFe at any speed". Telling It Like It Is. Retrieved 2017-11-11.
  15. ^ Gothelf, Jeff (2021-10-05). "SAFe is not Agile". Retrieved 2023-05-21.
  16. ^ Eklund, U; Olsson, H; Strøm, N (2014). Industrial challenges of scaling agile in mass-produced embedded systems. Springer International Publishing. ISBN 9783319143583. {{cite book}}: |work= ignored (help)
  17. ^ a b Vaidya, 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.
  18. ^ a b Maximini, Dominik (11 September 2013). "A critical view on SAFe - Scrumorakel - Blog". Scrum Oracle. Retrieved 2017-11-27.
  19. ^ Stafford, Jan (December 9, 2013). "Scaling Agile development calls for defined practices, consultant says". SearchSoftwareQuality. Retrieved 2017-11-27.[dead link]
  20. ^ Killick, Neil (21 March 2012). "The Horror Of The Scaled Agile Framework". Agile, Scrum, Kanban, Lean, and everything that's in between. Retrieved 2017-11-27.
  21. ^ https://www.leanwisdom.com/blog/safe-implementation-roadmap/%7Ctitle=SAFe Implementation Roadmap

Further reading

Retrieved from "https://en.wikipedia.org/w/index.php?title=Scaled_agile_framework&oldid=1198478571"