SAFe is designed to give teams flexibility and help manage some of the challenges larger organizations have when practicing agile. The framework is built for four pillars: Team, Program, Solution, and Portfolio.
As businesses grow, more and more teams start adopting agile. In this scaling phase, more challenges surface. These challenges make it difficult:
SAFe also creates change agents to continuously coach, mentor, and guide the implementation. There are four configurations in SAFe to accommodate various scale levels: Essential SAFe, Large Solution SAFe, Portfolio SAFe, and Full SAFe.
They are responsible for guiding teams through the implementation process and are tasked with encouraging workers and leadership to embrace the agile method.
The agile coach's goal is to arm agile teams with the proper knowledge, tools, and training so that they'll be able to use agile to its full potential.
Agile coaches are not just responsible for organizing an agile team; they also help the company embrace agile as a culture shift. To properly implement the methodology, an agile coach needs to encourage buy-in from employees and key stakeholders. The most common responsibilities of an Agile coach include:
An agile coach in the enterprise practicing SAFe has added responsibilities of coaching and aligning the various Agile Teams working in the ART.
In addition to the responsibility of an Agile Coach, s/he also works with the Agile Teams to improve collaboration, synchronization of alignments, and delivery of Agile Release Trains.
SAFe Agile Coach has the added accountability of ensuring the organization's vision & mission are trickled down to the various agile teams working on the same solution. S/He leads implementation workshops (value stream identification/mapping, identification of ARTs, the definition of EPIC, etc.) and supports product key people responsible for leading ARTs.
SAFe's core value is "Built-In Quality." When you are building an application at scale, quality cannot and should not be overlooked. SAFe provides guidance on the quality of code via many forums such as CoPs, support from System Architects/Engineers, and even an architectural runway.
A SAFe Agile Coach has to foster technical excellence and enable teams to have continuous attention to quality. In SAFe, many events happen at the program level involving multiple teams, for example, PI Planning.
A SAFe Agile Coach must coach teams on managing the timeboxes, dependencies, and other ambiguities considering multiple teams. Although the agile teams are responsible for solving any interdependencies, the Agile Coach is supposed to facilitate multiple teams.
The SAFe Agile Coach also needs to support the agile teams in preparation for other program events such as System Demo, Inspect and Adapt, Problem-Solving Workshops, etc.
It helps Agile Coaches, senior management, change agents, and technical folks gain the knowledge necessary to lead a Lean-Agile enterprise by leveraging the Scaled Agile Framework.
Leading SAFe is about the framework and its underlying principles derived from Lean, systems thinking, Agile development, product development flow, and DevOps.
Once you learn about SAFe, you could take your second step as a Release Train Engineer. During this three-day course for SAFe RTE, you will gain an in-depth understanding of the role and responsibilities of an RTE in the SAFe enterprise.
You will gain the skills needed to facilitate and enable end-to-end value delivery through Agile Release Trains (ARTs)—and learn how to build a high-performing ART through servant leadership and coaching—by becoming a SAFe® 5 Release Train Engineer (RTE).
As an SPC, you would also be able to train and certify others in a range of SAFe courses. During this four-day course, attendees will learn how to lead a Lean-Agile transformation by leveraging the practices and principles of the Scaled Agile Framework® (SAFe®) to achieve Business Agility in the Digital Age.
Attendees practice the steps necessary to bring an organization to the tipping point and identify value Streams and organize Agile Release Trains (ARTs), followed by learning how to prepare successfully launch and coach ARTs.
The attendees then explore launching more ARTs as part of a Solution Train and how to extend Lean-Agile practices to the Portfolio with Lean Portfolio Management. The course concludes by focusing on the areas needed to accelerate Business Agility by establishing Organizational Agility, building a Continuous Learning Culture, and identifying improvement opportunities by applying the SAFe assessments.
All frameworks for scaling Agile share five main components: inspiration from the 12 Agile Manifesto principles, cadence, synchronization, Scrum, and quality development practices.
Understanding other frameworks' origins, core differences, and the conditions for their successful application can help organizations choose which framework best suits their needs.
The purpose of S@S is to create a network of Scrum teams through a 'scale-free architecture,' meaning basic Scrum roles and events are linearly scaled without introducing new process dynamics.
For example, one Scrum of Scrum (SoS) may not be enough for a very complex product with 25 Scrum teams, so a Scrum of Scrums (SoSoS) with a Scrum of Scrums Master (SoSM) may be needed.
LeSS also differs in its stance that product owners should have complete content authority and strategic influence, whereas SAFe encourages a more democratic approach. And while in SAFe many factors inform strategy, LeSS emphasizes a customer-centric approach focused on paying customers.
It offers lightweight agile governance, which is rooted in Scrum and Kanban, along with transformation knowledge in areas like HR and finance, governance, DevOps, portfolio management, and more.
DA involves situationally employing different levels of scale for each project and emphasizes decision-making enablement to help guide strategic direction.
Spotify emphasizes self-organizing, cross-functional, and co-located teams called "squads" (the equivalent of a scrum team). Comparatively, SAFe has no such stipulation on the co-location of teams, for PI planning, it is encouraged. Squads are organized into larger units called "tribes".
Dependencies between squads are few and handled through Scrum of Scrums when they occur. Knowledge sharing is enabled through "chapters" and "guilds," informal groups organized based on skill sets and interests.