Scaled agile framework

Last updated

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]

Contents

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.

Implementation

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: [21]

  1. Take an economic view
  2. Apply systems thinking
  3. Assume variability; preserve options
  4. Build incrementally with fast integrated learning cycles
  5. Base milestones on objective evaluation of working systems
  6. Visualize and limit work-in-progress, reduce batch sizes, and manage queue lengths
  7. Apply cadence (timing), synchronize with cross-domain planning
  8. Unlock the intrinsic motivation of knowledge workers
  9. Decentralize decision-making
  10. Organize around value

SAFe has been criticized for aggregating too many disparate practices. [22]

The SAFe framework

In SAFe version 5.1, there are four configurations: essential, portfolio, large solution and full: [23]

Certifications

Scaled Agile provides certifications that cover different areas and knowledge levels. [24]

See also

Related Research Articles

The rational unified process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

Agile software development is the mindset for developing software that derives from values agreed upon by The Agile Alliance, a group of 17 software practitioners in 2001. As documented in their Manifesto for Agile Software Development the practitioners value:

<span class="mw-page-title-main">Dynamic systems development method</span> Agile project delivery framework

Dynamic systems development method (DSDM) is an agile project delivery framework, initially used as a software development method. First released in 1994, DSDM originally sought to provide some discipline to the rapid application development (RAD) method. In later versions the DSDM Agile Project Framework was revised and became a generic approach to project management and solution delivery rather than being focused specifically on software development and code creation and could be used for non-IT projects. The DSDM Agile Project Framework covers a wide range of activities across the whole project lifecycle and includes strong foundations and governance, which set it apart from some other Agile methods. The DSDM Agile Project Framework is an iterative and incremental approach that embraces principles of Agile development, including continuous user/customer involvement.

<span class="mw-page-title-main">Craig Larman</span> Canadian-born computer scientist, author, and organizational development consultant

Craig Larman is a Canadian computer scientist, author, and organizational development consultant. With Bas Vodde, he is best known for formulating LeSS, and for several books on product and software development.

Capability Maturity Model Integration (CMMI) is a process level improvement training and appraisal program. Administered by the CMMI Institute, a subsidiary of ISACA, it was developed at Carnegie Mellon University (CMU). It is required by many U.S. Government contracts, especially in software development. CMU claims CMMI can be used to guide process improvement across a project, division, or an entire organization.

In agile principles, timeboxing allocates a maximum unit of time to an activity, called a timebox, within which a planned activity takes place. It is used by agile principles-based project management approaches and for personal time management.

Lean software development is a translation of lean manufacturing principles and practices to the software development domain. Adapted from the Toyota Production System, it is emerging with the support of a pro-lean subculture within the agile community. Lean offers a solid conceptual framework, values and principles, as well as good practices, derived from experience, that support agile organizations.

<span class="mw-page-title-main">Scrum (software development)</span> Management framework

Scrum is an agile team collaboration framework commonly used in software development and other industries.

<span class="mw-page-title-main">Unified Process</span> Object oriented software development process framework

The unified software development process or unified process is an iterative and incremental software development process framework. The best-known and extensively documented refinement of the unified process is the rational unified process (RUP). Other examples are OpenUP and agile unified process.

<span class="mw-page-title-main">Jeff Sutherland</span> American computer scientist

Jeff Sutherland is one of the creators of Scrum, a framework for product management. Together with Ken Schwaber, he presented Scrum at OOPSLA'95. Sutherland contributed to the creation of the Agile Manifesto in 2001. Along with Ken Schwaber, he wrote and maintains The Scrum Guide, which contains the official definition of the framework.

Strategic planning software is a category of software that covers a wide range of strategic topics, methodologies, modeling and reporting.

A glossary of terms relating to project management and consulting.

In software engineering, a software development process or software development life cycle (SDLC) is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

Enterprise release management (ERM) is a multi-disciplinary IT governance framework for managing software delivery and software change across multiple departments in a large organization. ERM builds upon release management and combines it with other aspects of IT management including Business-IT alignment, IT service management, IT Governance, and Configuration management. ERM places considerable emphasis on project management and IT portfolio management supporting the orchestration of people, process, and technology across multiple departments and application development teams to deliver large, highly integrated software changes within the context of an IT portfolio.

Specification by example (SBE) is a collaborative approach to defining requirements and business-oriented functional tests for software products based on capturing and illustrating requirements using realistic examples instead of abstract statements. It is applied in the context of agile software development methods, in particular behavior-driven development. This approach is particularly successful for managing requirements and functional tests on large-scale projects of significant domain and organisational complexity.

Disciplined agile delivery (DAD) is the software development portion of the Disciplined Agile Toolkit. DAD enables teams to make simplified process decisions around incremental and iterative solution delivery. DAD builds on the many practices espoused by advocates of agile software development, including scrum, agile modeling, lean software development, and others.

eXtreme Manufacturing (XM) is an iterative and incremental framework for manufacturing improvement and new product development that was inspired by the software development methodology Scrum and the systematic waste-elimination (lean) production scheduling system Kanban(かんばん ).

Agile architecture means how enterprise architects, system architects and software architects apply architectural practice in agile software development. A number of commentators have identified a tension between traditional software architecture and agile methods along the axis of adaptation versus anticipation.

<span class="mw-page-title-main">Mike Beedle</span> American software engineer

Miguel "Mike" Beedle was an American software engineer and theoretical physicist who was a co-author of the Agile Manifesto.

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.[ dead link ]
  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. 1 2 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. 1 2 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. ↑ "SAFe Lean-Agile Principles" . Retrieved 19 February 2016.
  22. ↑ Elssamadisy, Amr. "Has SAFe Cracked the Large Agile Adoption Nut?". InfoQ. Retrieved 2017-11-11.
  23. ↑ Rose, Doug (2018). Enterprise Agility For Dummies. John Wiley & Sons. pp. 87–89. ISBN   9781119446095.
  24. ↑ "Certification". Scaled Agile. Retrieved 19 February 2016.

Further reading

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.