The Scaled Agile Framework (abbreviated as SAFe), is a registered trademark of Scaled Agile, Inc. It is intended to guide enterprises in scaling lean and agile practices. Along with Large-Scale Scrum (LeSS), Disciplined Agile Delivery (DAD), and Nexus, this is one of a growing number of frameworks that seek to address the problems encountered when scaling beyond a single team.
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.
The primary reference for the scaled agile framework was originally the development of a big picture view of how work flowed from product management, through governance, program teams, and development teams, out to customers. With the collaboration of others in the agile community, this was progressively refined and formalized, then included in a 2007 book. Since then, the framework has continued to be developed and released into the public domain, also supported by an academy and an accreditation scheme for third-party consultants. The latest release, as version 4.5, was released in June 2017.
Although SAFe has been recognised as the most common approach to scaling agile practices, it has been criticised for being too top-down and inflexible.
Video Scaled agile framework
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. They will often work with a very high level, 12-18-month roadmap, then plan collaboratively with the teams for three months of work. The development teams will still get into detailed refinement 2-3 iterations ahead, only getting into detailed task plans for the next iteration.
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). SAFe has also been criticized for aggregating too many disparate practices.
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 needs a view across multiple team backlogs, such as provided by a product manager. Although SAFe assumes the product owner role sits with product management, it has nonetheless been criticized for separating product owners into the development organization.
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. 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 that SAFe has been criticized.
Allowing time for innovation and planning
The SAFe planning cycle recommends including an additional iteration after a release, so that teams can improve their practices and are ready for the next planning increment. Earlier editions of SAFe also designed this to be a hardening iteration, that is to stabilize or harden the product before releasing it. This was predicated on the complications of working with large integration environments where dependencies meant that you could not test everything until the very end. SAFe was criticized for this as it represented an anti-agile or waterfall element. This is not included in recent editions of SAFe.
Maps Scaled agile framework
Underlying principles of SAFe
SAFe is based on nine underlying lean and agile principles, that drive the roles and practices in SAFe :
- 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
- Decentralize decision-making
The SAFe framework
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.
3-level SAFe
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.
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.
Agile Teams typically consist of 5-9 people who work in a two-week sprints 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 sprints 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".
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.
4-level SAFe
4-level SAFe includes an additional Value Stream level between the Program and Portfolio levels. This is designed for organizations building large systems, although any enterprise can benefit by incorporating from various value stream constructs in their implementation.
Value Stream
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.
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.
- SAFe Agilist (SA)
- SAFe Practitioner (SP)
- SAFe Program Consultant (SPC)
- SAFe Product Manager / Product Owner (SPMPO)
- SAFe Program Consultant Trainer (SPCT)
- SAFe Scrum Master (SSM)
- SAFe Advanced Scrum Master (SASM)
See also
- Scrum of Scrums
References
Further reading
- Heusser, Matthew (17 June 2015), Introducing the scaled agile framework, CIO, pp. 1-2 -- contains a review of the pros and cons of the methodology and concludes it is a half-way-house to a fully agile system.
- Leffingwell, Dean (2011), Lean Requirements Practices for Teams, Programs, and the Enterprise, Addison-Wesley Professional, ISBN 978-0321635846
- Linders, Ben (15 January 2015), Lean and Agile Leadership with the Scaled Agile Framework (SAFe), InfoQ
- Richards, Mark (20 January 2013), Scaled Agile Framework Applied - Part 1/5: Introduction and Context, A is for Agile, not Anarchy
- Swanson, Brad (7 April 2014), Blog: A Scaled Agile Framework® (SAFe(TM)) Case Study, agile42 - The Agile Coaching Company
External links
- Scaled Agile Framework - SAFe for Lean Enterprises, Scaled Agile, retrieved 2017-09-22 -- home page of Scaled Agile Incorporated, the owner of the registered trademark "SAFe ®".
Source of the article : Wikipedia
0 Comments