What are the 10 essential SAFe elements?
The Scaled Agile Framework® (SAFe®) has different configurations. Many aspects are optional or depend on the configuration that you have chosen to use. However, there are 10 elements of SAFe that are considered so important to the framework that, if they are not used, then SAFe is not being used. These 10 essential SAFe elements are:
1) SAFe Lean-Agile Principles
The leaders, managers and team members must be mindful of the 10 SAFe Lean-Agile Principles and apply them to the work being done. These are:
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
Visualise and limit WIP, reduce batch sizes, and manage queue lengths
Apply cadence, synchronise with cross-domain planning
Unlock the intrinsic motivation of knowledge workers
Decentralise decision-making
Organise around value
For more on these principles visit
www.scaledagileframework.com/safe-lean-agile-principles/
2) Real Agile Teams and Trains
Agile teams need to be cross-functional and work in a short time-box period (typically 2 weeks long) called iterations to deliver valuable increments in each iteration. They apply built-in quality practices and should be self-organising, both at the team level and as a team of teams.
The product manager, system architect and release train engineer provide context, technical authority and an effective development process to allow the teams to frequently integrate, and to deliver value to the organisation and its customers.
Product owners and scrum masters help the agile teams meet their team objectives for the PI. Agile teams are teams that engage with their customer throughout the process rather than just at the end.
3) Cadence and Synchronisation
Cadence is about things happening with a steady, predictable rhythm so that events, such as PI Planning and system demos, can be planned into the schedule in advance. This means that there is not much overhead or time spent looking in diaries or rescheduling these events.
Synchronisation means that the events across a whole agile release train (ART) or even solution train occur at the same time so that planning can be done across the whole ART and regular integrations and reviews can take place with the teams at the same point in the programme increment (PI). It also helps the ART assess how well it is progressing towards the PI objectives that were agreed at PI planning (see element 4).
4) Programme Increment (PI) Planning
This is a two-day planning event where all of the people working in an agile release train (ART) get together to plan the work for the next programme increment (PI). The duration of the PI is typically 8-12 weeks and is agreed in advance and applies to all teams in the ART.
The teams forecast the features that they will be able to deliver during the PI and work with other teams to identify, understand and resolve dependencies between teams, and risks to feature delivery. Objectives are agreed for each team and the PI so that it is clear what each time is expecting to achieve by the end of the PI and also what the ART expects to achieve as a team of teams.
5) Customer Centricity, DevOps and Release on Demand
The customer is, ultimately, the person who decides the value of any work completed. These are the people who consume the output of the ART which may be external or internal. Creating a positive experience for the customer includes understanding the customer’s needs, thinking like them and understanding the lifetime value of the customer.
Customer-centricity uses design thinking to fully understand the problem and design the right solution.
A DevOps approach means looking to reduce or eliminate the gap between development and operations by thinking about the culture, automation, lean flow, measurement and recovery capabilities. This is often referred to as the CALMR approach to DevOps.
Release on Demand means the capability to frequently deliver value to customers, in line with the demands of the market.
6) System Demo
One of the principles of the Agile Manifesto is that working software is the only measure of progress. To review progress towards the programme increment objectives, the work from all of the teams is integrated, and the working software is demonstrated after every iteration.
7) Inspect & Adapt
At the end of every programme increment, an inspect and adapt workshop is run to review the solution, collect and assess data, and then decide on improvements that could be made for the next programme Increment. This is done in addition to team-level retrospectives.
8) IP Iteration
The ‘innovation and planning’ (IP) iteration is the final iteration (or sprint) within every programme increment. It has a variety of purposes:
A chance to finish off the work required to meet the PI objectives
Work on some innovation that may be useful in the next programme increment
Team members can do some professional development or training
The inspect and adapt workshop takes place during the IP iteration (see element 7)
PI planning for the next PI also takes place during the IP iteration (see element 4)
By being both an opportunity to clear the work from the current PI and plan the next one it gives the product manager the ability to set the new priorities. The opportunity to inspect & adapt, train and innovate can lead to a rejuvenated agile release train.
9) Architectural Runway
This is the technical infrastructure, components and code that is necessary to support the implementation of the high-priority features that teams are soon to work on. The architecture needs to be prepared far enough ahead of the teams so that their work is not slowed by it not being in place.
10) Lean-Agile Leadership
Organisational leaders must take responsibility for the implementation of an agile transformation or it will likely fail. To be effective in this, organisational leaders must be trained in lean-agile ways of thinking so that they can support and guide others to a successful agile transformation.