Scaled Agile Framework

Software development process
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Tools
Standards and BOKs

Scaled Agile Framework (or SAFe) is an Agile software development framework designed by Scaled Agile, Inc. It consists of a knowledge base of integrated patterns intended for enterprise-scale Lean-Agile development. Its proponents consider SAFe to be scalable and modular, allowing an organization to apply it in a way that suits its need.

Introduction

SAFe synchronizes alignment, collaboration, and delivery for large numbers of agile teams. It supports both software and systems development, from the modest scale of under 100 practitioners to the largest software solutions and complex cyber-physical systems; systems that require thousands of people to create and maintain. SAFe was developed in the field, based on helping customers solve their most challenging scaling problems. SAFe leverages three primary bodies of knowledge: Agile development, Lean product development, and systems thinking.

SAFe was initially developed in the field and was elaborated in Dean Leffingwell's books and blog. Version 1.0 of SAFe, the first official release, was published in its current web site form in 2011. The latest version renamed "SAFe 4.0 for Lean Software and Systems Engineering", was released in January 2016.[1]

Principles

SAFe is based on a number of immutable, underlying Lean and Agile principles. These are the fundamental tenets, the basic truths and economic underpinnings that drive the roles and practices that make SAFe effective.[2] The nine SAFe principles are:

  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 WIP, 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

Levels

There are two different types of SAFe 4.0 implementation, 3-Level SAFe and 4-Level SAFe. 3-Level SAFe is for smaller implementations with 100 people or less, or multiple such programs that do not require significant collaboration. 4-Level SAFe is for solutions that typically require many hundreds of practitioners to develop, deploy and maintain.

The levels in 3-Level SAFe are Team, Program & Portfolio.

Team

All SAFe teams are agile teams. There is more than one type of team for example there may be a Systems Team and architectural teams, and the more common Agile development teams which are called "Agile Teams" in the SAFe methodology.[3]

A Systems Team is a specialised team which is responsible for maintaining the development environment used by the Agile Teams and for testing solutions end-to-end.[3]

Agile Teams typically consist of 5-9 people who work in a two-week scrums using XP (Extreme Programming) methods, and have the skills they need to define, develop, test and deliver value. However unlike traditional development scrums they do not work independently and autonomously. For example, their team backlog consists of items pulled from the Program backlog, and the length of their scrums are synchronised with all the other teams on the same "Agile Release Train" (see the next section), because the SAFe methodology is built around the idea that "basing routine development activities on a fast, synchronous cadence—a regular, predictive rhythm of important events—helps manage the inherent variability in systems development".[3]

Program

Together, 5-10 SAFe teams create an "Agile Release Train", with typically 50 to 125 persons, including the development teams and other stakeholders. They synchronize their iteration boundaries and deliver integrated, working systems every two weeks.

The Program Increment (PI) is a larger, quantum measuring point, which typically occurs on a cadence of 3-5 development iterations, followed by one Innovation and Planning (IP) Iteration. Each PI concludes with a demo of all the functionality that has been developed through the course of the PI. This is accompanied by an Inspect and Adapt session that includes root cause analysis and identification of systematic improvements.

The Innovation and Planning iteration supports the dedicated time for PI system demo, innovation and face to face PI planning. This describes the basic development cadence, which synchronizes teams to a common mission and cadence, and focuses on the frequent integration of the full system. However, Teams and Programs can release functionality at any time the market demands, including continuous delivery.

Portfolio

A portfolio is a collection of value streams which are budgeted via lean-agile budgeting mechanisms. The portfolio is connected to the enterprise strategy by a set of strategic themes. A portfolio kanban system is used to capture and analyze epics - large,cross-cutting initiatives that affect multiple Agile Release Trains.

Value Stream

4-level SAFe includes a new Value Stream level. This level is designed for those organizations which are building large systems, although any enterprise can benefit by incorporating from various value stream constructs in their implementation.

A value stream is a long-lived series of steps used to deliver value, from concept or customer order to delivery or a tangible result for the Customer. The flow of value is triggered by some important event, perhaps a Customer purchase order or new feature request. It ends when some value has been delivered - a shipment, customer purchase, or solution deployment. A value stream contains the people who do the work, the systems they develop or operate, and the flow of information and materials. The time from the trigger to the value delivery is the lead time. Shortening the lead time shortens the time to market. That is the focus. [4]

Certifications

There are a number of different SAFe certifications which provide the training, knowledge and necessary tools for various levels of the Scaled Agile Framework.[5]

  1. SAFe Agilist (SA)
  2. SAFe Practitioner (SP)
  3. SAFe Program Consultant (SPC)
  4. SAFe Product Manager / Product Owner (SPMPO)

Criticism

The main criticism of SAFe is its lack of maturity and field testing. At least one article [6] seems to lead in that direction. The attraction of agile to developers is the freedom to be creative, yet still be accountable for your work. Scrum is about the team being responsible for itself which empowers the members. SAFe appears to erode some of that empowerment.

See also

Notes

  1. ↑ "Welcome to SAFe 4.0! – Scaled Agile Framework". www.scaledagileframework.com. Retrieved 2016-05-19.
  2. ↑ "SAFe Lean-Agile Principles". Retrieved 19 February 2016.
  3. 1 2 3 Glossary – Scaled Agile Framework, Scaled Agile, 2 December 2015
  4. ↑ http://www.scaledagileframework.com/value-streams/
  5. ↑ "Certification". Scaled Agile. Retrieved 19 February 2016.
  6. ↑ https://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/

References

Further reading

This article is issued from Wikipedia - version of the 11/30/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.