The Scaled Agile Framework® (SAFe®) is a leading framework for scaling Agile in large enterprises. It is a set of workflow patterns and principles for implementing agile practices at an enterprise scale. The framework focuses on improving quality and increasing productivity. SAFe promotes a structured approach of collaboration and delivery across large agile teams. Agile, Lean Product development, and system thinking are some of the attributes of SAFe.
Depending on the levels of scale, SAFe has four configurations: Essential SAFe, Large Solution SAFe, Portfolio SAFe, and Full SAFe.
SAFe core values are fundamental framework beliefs that the leadership has to foster and how teams should adapt to the culture and collaborate work towards the goals. The four core values are: Alignment, Built-In Quality, Transparency, and Program Execution.
Alignment: SAFe help in synchronising people and keeping the information flow across all levels of the portfolio in the organisation to stay in alignment.
Built-In Quality: SAFe requires teams at all levels to deliver the work with high quality by adopting to practices and quality measures.
Transparency: SAFe facilitate teams to collaborate and share the information across all levels, inspect and adapt while the work is in progress by enabling transparency in workflow.
Program Execution: SAFe teams aim at delivering quality product and business value to the customer on a regular basis.
The Scaled Agile Framework’s principles help to improve the organisation through lean-agile and system thinking process across the organisation. It requires a shift in the mindset of people from traditional waterfall to lean-agile method.
SAFe Lean Agile Principles:
– 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 Process (WIP), reduce batch sizes, and manage queue lengths;
– Apply cadence, synchronize with cross-domain planning;
– Unlock the intrinsic motivation of knowledge workers;
– Decentralize decision making.
The SAFe or Scaled Agile Framework is an agile framework for building products in an Agile environment at large enterprises. The model works at Team, Program and Portfolio levels. This gives flexibility in managing the challenges in the large organisation on the required scale.
The WSJF SAFe is Weighted Shortest Job First (WSJF) SAFe process used as a work prioritisation model to order the work such as features, capabilities, epics to produce maximum economic benefit. The formula for calculating WSJF in SAFe is: WSJF = Cost of Delay (CoD) / job size.
The levels of SAFe include Portfolio, Value Stream, Program, and Team. The SAFe implementation type is chosen based on the solutions that need hundreds of SAFe practitioners to build the solution, deploy, and maintain the product. The 4 levels of SAFe configurations for these types include Team, Program, Large solution, and Portfolio.
Agile is the methodology and provides the basis for many frameworks that evolved from it. Agile uses an iterative method for developing a software product that focuses on the continuous delivery of work and earlier to customer to obtain feedback and improvise the product continuously. SAFe, on the other hand, is an agile framework used by an organisation or an enterprise which helps to practice Agile at large scale and adopt lean methodologies in it.
Scrum is the most widely used and popular Agile framework which is based on the agile methodology for practicing Agile principles in small teams. While SAFe is a scaling framework which is also based on Lean-Agile principles and it is helpful in implementing Scrum and Kanban frameworks for large organisations. Both these frameworks approach help to build the software products efficiently using modern techniques and agile principles.
SAFe has four core values, namely Alignment, Built-In Quality, Transparency, and Program Execution that form the value system for SAFe.
Scaled agile is also sometimes referred to as “agile at scale” is a framework that facilitates agile implementation at large organisations or enterprises. The purpose of scaled agile is to give the right amount of governance and guidelines for running complex projects with bigger teams.
Capability is a superset of product features or behaviours that span across multiple ARTs. To execute, the Capabilities are often split into multiple features (sized) so that it can be implemented in a single Program Increment (PI).
The three dimensions of Lean Agile Leadership are the elements that set the foundation of new mindset. They are SAFe Core Values, the Lean-Agile Mindset, and SAFe Principles.
Enablers are sort of solution backlogs that helps in building “user stories” needed for building Architectural Runway for expanding the business scale and running the future projects smoothly. The Infrastructure processes are set up for automating the development cycle. Enablers include exploration, architecture, infrastructure, and compliance.
Enablers in SAFe framework are a popular concept, which acts as solutions for the teams to build their “user-stories”.
Architectural enablers and Infrastructure enablers are the two types of enabler stories. The former is created to build the Architectural Runway for the projects with which smooth development can happen. The latter one is used to create an automation process for the development, testing, and deployment activities.
Scaled Agile Framework (SAFe) allows organisations to apply lean-agile practices at the enterprise level. It provides a set of workflow patterns that guide enterprises for scaling agile. Large organisations that are planning to implement SAFe get executive-level sponsorship. Scaled Agile, Inc. provides the SAFe implementation roadmap that has detailed steps on how to start and adopt scaled agile practices across portfolios. The 12 steps for implementing SAFe include:
– Reaching the tipping point
– Train lean-agile change agents
– Train executives, managers, and leaders
– Create a lean-agile center of excellence
– Identify value streams and ARTs (Agile Release Trains)
– Create the implementation plan
– Prepare for ART launch
– Train teams and launch the ART
– Coach the ART execution
– Launch more ARTs and value streams
– Extend to the portfolio
– Sustain and improve
SAFe is the most popular framework for scaling Scrum at large enterprises. Scrum at Scale was introduced by Dr. Jeff Sutherland and Alex Brown as a Scaling Agile framework. Although Scrum at Scale is good for Agile, when compared to SAFe, it is less suitable for a very complex product. The Scrum at Scale helps to create a network of Scrum teams that are linearly scaled without any new processes. They are more successful where the organisation’s have T-shaped skills, product-centric values, object-oriented technology stack, etc.
SAFe is the most popular framework for scaling Scrum at large enterprises. SAFe has four configurations to accommodate teams of greater size that deal with complex solutions, whereas LeSS has two configurations. LeSS works well with two to eight teams and as the size of the teams increases LeSS Huge configuration is suitable.
LeSS has similar activities as that of Scrum at Scale, namely Scrum events, artifacts, and roles. LeSS also focus on reducing the wastages and promotes continuous improvement. SAFe and LeSS framework emphasis on lean thinking, systems thinking, and agile principles.
SAFe is a popular scaling agile framework. Disciplined Agile (DA) enables organisations to define their own working method according to their need. Since it is evolved from Scrum and Kanban approaches, it is lightweight and follows agile principles. It is suitable in areas where transformation knowledge is seen like DevOps, HR and Finance, Portfolio Management, etc. and also organisations that are flexible in adopting the Agile.
SAFe is a popular scaling agile framework, whereas spotify is a people-driven model. It works in places where the teams are self-organised, cross-functional, co-located teams “squads”. However, SAFe has no concerns about the co-location of teams. Squads form the “tribes” as larger units. The teams collaborate and share their knowledge through “guilds” and “chapters”. Spotify emphasis on organisational culture, learning, taking risks, etc.
Agile Release Train (ART) includes expert people (stakeholders) from different areas who are needed to implement, test, deploy the build the solutions in a value stream, and release it to the customer. An ART typically has 50-125 people, and multiple ARTs can exist. Each ART acts as a virtual organisation that focuses on their solution delivery.
The Architectural Runway acts as the runway that helps in landing the flights, and when it is maintained well, it helps the future landing of flights smoothly. In SAFe, the Architectural Runway is the base architectural platform that has code components and infrastructure that will help in implementing features with little rework and re-designing to save time.
The Inspect and Adapt is the principle of empiricism in Agile. Every event has a significant space that supports this. In SAFe, the inspect and adapt (I&A) event occurs at the end of each Program Increment (PI). The teams demonstrate the solutions built (and integrated) to the stakeholders of the release train. Teams collect the feedback and identify the improvement items which goes into the backlog for review and addressing them.
Each PI starts with a Program Increment (PI) planning, which is a time boxed event occurs during an Agile Release Train (ART) or Solution Train to deliver an incremental business value (working software). The outcome of this event is PI Objectives that gives the details of what ART should build to demonstrate at the end of the PI. PIs typically take 8 – 12 weeks duration, which include four iterations followed by one Innovation and Planning (IP) Iteration. PI cadence represents the PDCA cycle (Plan-Do-Check-Act).
The Release Train Engineer (RTE) serves as a coach for the Agile Release Train (ART). RTE facilitates the ART events, communicates with all the stakeholders, removes impediments or roadblocks for the team, and helps them in delivering business value. RTEs ensure that lean-agile principles are followed in the ART processes, and teams are aligned to the larger program.
The System Demo is an important event time boxed at one hour max. to inspect the fully integrated features and solutions built by the teams in the iteration of Agile Release Train (ART). The feedback received from the stakeholders is critical and plays an important place in improving the system processes. It helps in future planning and preparing the next iteration effectively. Getting fast feedback helps teams to build the solution aligned with customer expectations and achieve a continuous flow of value to the customers.
The continuous delivery pipeline (CDP) consists of three aspects, namely Continuous exploration, Continuous Integration, and Continuous Deployment. CDP provides each ART with the ability to build new features and focus on Agile product delivery through workflows, activities, and automation solution to build it and release-on-demand of value faster to the customer.
The Team Backlog consists of user stories and enabler Stories. The Team backlog primarily is a subset of Program Backlog. It may include other work items from team context. As in Agile process, the Product Owner (PO) owns the team backlog. Team capacity is reviewed and allocated against the backlog items which accounts the team and the Agile Release Train (ART) needs.
A program backlog is a list of features required for delivery in an upcoming product release (program increment or PI) for a single Agile Release Train (ART). The program backlog is derived from the Portfolio Backlog and also from other sources directly, such as enabler features required to build the Architectural Runway.
As backlog construction and refining is a continuous process, the planning event happens concurrently aside from PI process. The outcome of the event becomes the set of features to be worked on by the team in the next PI. This is effectively managed using a program kanban, where features are listed in a series of workflow states. This is elaborated in detail in each state until the final state of features is ready for pulling into a program increment to build a working and shippable product.
The Scrum of Scrums is a scaled agile event equivalent to a Daily standup meeting in the Scrum framework. This event gives an opportunity for multiple Scrum teams to participate and work together on the goal of delivering a complex product in an ART.
The team level daily scrum standup meeting happens separately and the Scrum of Scrums event doesn’t replace it. However, not all the members will participate in the Scrum of Scrums but a representative (‘ambassadors’) from each team will be invited to share their high-level work progress on what features are being worked on, delivery plan in the sprint, discuss their impediments and any dependency constraints to take it to resolution. The teams use the program board to visualising the work across the teams. The following artifacts are used to see through the team’s delivery – program board, feature progress board, and release burn-up chart.
Program Increment is referred as PI. The teams collaborate and create the PI objectives both business and technical goals of an Agile Release Train (ART) that has to be achieved in the upcoming Program Increment (release).
The following are the roles prescribed in SAFe at various levels.
Team level: Agile Team, Scrum Master, and Product Owner.
Program level: Product Manager, Business Owner, Release Train Engineer, System Architect/Engineer, Customer.
Solution level: Solution Manager, Solution Architect/Engineer, Solution Train Engineer.
Portfolio level: Epic Owners, Enterprise Architect.
The following are the SAFe ceremonies: PI Planning, Scrum of Scrums, PI System Demo, PI Retrospective.
The SAFe Artifacts are Program Backlog, Team Backlogs, Working Software.
The 4 levels of requirements hierarchy are: Epic >> Capability >> Feature >> Story.
The capability was not part of earlier SAFe versions. It was introduced in SAFe 4.0 that requires multiple ARTs to deliver large programs. 3-level SAFe used in organisations is Epics, Features, and Stories. These levels have their own roles, practices, processes, and artifacts.
The Scrum and the equivalent SAFe events are:
Sprint planning to PI Planning, Daily standup to Scrum of Scrums, Sprint Review to System Demo, Sprint Retrospective to PI Inspect & Adapt (I&A): Problem-solving workshop.
SAFe Scrum Masters play a key role as coaches for an Agile Team. They are servant leaders who aim at implementing the best SAFe principles and practices, identifying and removing blockages, and executing the flow of Program Increment (PI) on the Agile Release Train. The SAFe Scrum Master works with Release Train Engineers, Solution Train Engineers, Agile Teams, Business Owners, etc. to improve the SAFe practices.
A critical role within SAFe is Product Owner (PO). The PO owns the Team backlogs. The PO helps the team in defining user stories, prioritizing the backlog so that the program execution is streamlined. Also, the PO liaison with the teams to bring value to the business and organisation. The role is important in maximising the value of the Agile Team.
As we know, the Kanban systems are made up of workflow states and aim at delivering value and continuously improvise the processes. SAFe Kanban teams work in a broader context that work towards building large solution with the help of multiple Agile teams collaborate together of multiple ARTs in a Solution Train. The Team Kanban method helps the teams to visualise the workflow of the tasks being delivered, limiting the Work In Process (WIP), measuring throughput, and focus on continuous improvement.
Story Mapping is the activity that involves breaking down each of the features into small functionality to deliver in a single iteration. The user stories may not be defined fully at this stage but covered in the backlog refinement phase.
Firstly, large activities or business processes are defined. This will be done to capture the end-to-end process flow from the user’s perspective. Then, each of the features is split into functions.
In order to create a minimum viable product, the minimum value of user experience is defined. This will help to map the requirements into value-based functionality.
ART is Agile Release Train. The ART has a primary role called Release Train Engineer (RTE) who is the chief scrum master, orchestrates all ART ceremonies. The Product Manager is the chief product owner who owns the PI backlog. System Architect owns the overall technical solution. Teams deliver the feature and involve in their own PI Planning. Business Stakeholders help the teams in aligning the programs (level) with strategic themes and roadmap.
The following are the ART Ceremonies:
PI Planning Preparation – Feature refinement and ranking.
PI Planning – 2 days activity which happens at every 10 weeks interval.
Scrum-Of-Scrums – It is a synchronisation event that helps teams to align during the PI time-box at least weekly. The team’s representatives participate and share their high-level updates, discusses, and remove any impediments.
System demos – This is the event where the product demo happens end-to-end after integrating the work from all the teams at the end of each iteration.
PI demo – This happens at PI level. The demo session takes place upon completion of PI.
PI retrospective (Inspect & Adapt) – This retro event happens after the completion of PI program to reflect and make necessary changes in future PI.
During the PI execution if there are any issues surfaced, then data is needed to assess the progress, impact on the PI process and accordingly necessary adjustments have to be made to the baseline plan. These artifacts help to guide the program through execution. During the Scrum-of-Scrum event, these charts or information radiators are displayed for the program team to review.
The ART artifacts are: Program Board, Feature completion reports, and PI burn-up chart.
Program Board – It is a wall-board where stickers are used on cards to indicate the work progress status: To Do, In Progress, Done.
Feature Progress Board – Re-purposed Program Board that shows the feature completion reports.
PI burn-up chart – Visualise the stories or story points completed in an iteration.
SAFe Features and capabilities are the stakeholder requirements model that are necessary in defining, planning, and implementing solution value. A Feature has a requirement that has to fulfill an acceptance criteria (which help to validate the features if they were implemented correctly) and based on that it is split into sizable work and business value to be delivered by an Agile Release Train (ART) in a Program Increment (PI). A Feature is broken down into user stories for manageable work and easier execution which can be an addition or change to existing functionality.
A capability on the other hand, is a high-level solution behaviour that can span across multiple (Agile Release Trains) ARTs. Capabilities are broken down into multiple features and each feature can turn into sizable stories to be implemented in a single Program Increment (PI). Capabilities work much similar to Features but at a higher level characteristics which take multiple ARTs to implement.
The end users are the Customers who use the solution for obtaining a business value. They can be external or internal (within the organisation) stakeholders and a part of the value stream that is part of the Lean-Agile process and contribute to the SAFe implementation practices. The Agile Teams work to satisfy the needs of the customers to provide high-quality delivery of the solution and continuously improve the quality of their products and services.
A Business Owner is a person or a lead stakeholder that represents the organisation and the management but outside the development team. The business owner is also the Team’s Sponsor or referred to as the Product Owner’s Product Owner.
They have accountability for business, governance, and return on investment, thereby achieving the roadmap of the business planning for an Agile Release Train (ART).
A Value Stream is a set of steps in a continuous flow of value to the customer in an Agile Release Train (ART). It is long-lived and sometimes it can have multiple ARTs for solution implementation. It offers greater benefits to the organisation in terms of faster delivery through iterations, higher quality, faster learning, and shorter time-to-market. A value stream includes all the stakeholders necessary to provide a value in the flow.
Whereas Agile Release Train (ART) includes all the expert people who are needed to develop, test, deploy and ship the software product or a solution. Usually an ART can have 50-125 people which acts as a virtual organisation that are committed to work together and deliver a business value to the customer.
User stories are functionalities to be built and delivered to the end-users that satisfy a set of acceptance criteria. They are written in a simple language and format that is easy to understand by the Agile team.
Enabler stories are work items that give insight into exploration, architectural and infrastructural, and compliance-related items. These functions may not be seen by the end-user, but they help to integrate the business solution as a flow of work. Since these work items are of the technical solution, they are written in a technical language that development teams and Architects can understand.
Solution train uses Lean-Agile approach to build complex solutions across multiple Agile Release Trains (ARTs) into one single solution. The stakeholders participate in this of hundreds or even thousands that are working towards a common solution goal. A SAFe Program Increment planning session happens initially to align the solution vision and the backlog. It follows a cadence and lean budget for the teams to work under the economic framework and stays within the budget. At the end of each iteration, there will be a solution demo session, which is an integrated product demo created by the ARTs to get feedback from the stakeholders. The solution demo session is followed by an Inspect and Adapt session to improvise the process and eliminate the wastages or problems identified in the next iteration. The Solution Train is a larger release train that consists of multiple Agile Release Trains.
An epic is a larger story defined at the portfolio level. It is further developed into a solution. The epics are of two types:
Business epics – These epics are customer-facing initiatives that deliver business value directly to the end user.
Enabler epics – These epics are used to construct the Architectural Runway (using existing code, components, and technical infrastructure) across different value streams that can support the future business epics.
A continuous delivery pipeline is a holistic implementation of the continuous pattern through the automation process. It uses automated builds, tests and deployment steps organised as a release workflow for the Agile Release Train (ART) to achieve a continuous flow of value. The continuous delivery pipeline consists of four elements: Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment (CD), and Release on Demand. The first three elements work together to support delivery of new functionality in small batches. Then they are released in accordance with market demand.
The SAFe house of Lean model has been derived from Lean Manufacturing. SAFe house has four pillars – a foundation and the Goal. The goal of Lean is to give maximum customer value in the shortest lead time with high quality to the end-users.
Each of the 4 pillars is as follows:
Pillar 1 – Respect for People and Culture – It becomes necessary for human intervention to implement the Lean-Agile principles. A cultural and behavioural change is necessary for the enterprise and the leaders in the organisation.
Pillar 2 – Flow – The SAFe implementation has a pipeline of a continuous flow of work for incremental delivery of business value. This enables the feedback mechanism to help in fine-tuning the processes continuously.
Pillar 3 – Innovation – SAFe facilitates innovation, it is important both at product and process levels so that the services can be built efficiently with rich new product features and improved processes.
Pillar 4 – Relentless Improvement – This pillar holds great value, and it inspires new learning and promotes process improvement.
The elements in the four-part Continuous Delivery Pipeline are Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment (CD), and Release on Demand. Release on Demand is the last element of the continuous delivery pipeline. Deployment of new functionality into production and releasing the software product to the customer is based on the customer request or market demand. The product changes are deployed incrementally and frequently as required. A constant workflow process has followed that helps to improve the quality, reliability, and turnaround time of the product.
It starts with consent is made with Epic, and the stakeholders can track the progress of features being developed through the Program Kanban Board.
Continuous Exploration – The Product Management team does the exploration on the epic amongst customers, agile teams, business owners, and other key stakeholders. Their aim is to get maximum benefit and build the Program Backlog.
Continuous Integration – The features are continuously developed, tested, integrated, and validated to deliver the business value.
Continuous Deployment – The features are built and then deployed. The automated testing process is initiated to test the features and non-functional requirements to ensure the delivery is of high quality and there are no flaws.
Release on Demand – The software once gets ready may not be deployed immediately. The deployment happens on demand. They are released whenever it is needed or requested.
Tipping point is that when an enterprise reaches the dominant organisational motive which is to achieve a change rather than resist it. At this stage, making a change is the only way forward.
Essential SAFe is the first stage of SAFe program where roles, events, and artifacts are required at a minimum to deliver business solutions in an Agile Release Train (ART). Several teams participate in this delivery process to achieve continuous delivery in a pipeline.
To know more about Essential SAFe, click here.
Large Solution SAFe is implementing larger SAFe which involves multiple Agile teams with bigger and additional roles, responsibilities, events, and practices to deliver larger applications that solve complex business problems.
To know more about Large Solution SAFe, click here.
Portfolio SAFe works at the Portfolio level of the organisation or enterprise. They align the business strategy with solution development through one or more value streams to achieve business agility. It describes the roles, practices, events, and artifacts of Portfolio configuration.
To know more about Portfolio SAFe, click here.