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 9 SAFe Lean-Agile Principles and apply them to the work being done. These 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 – Visualise and limit WIP, reduce batch sizes, and manage queue lengths
7 – Apply cadence, synchronise with cross-domain planning
8 – Unlock the intrinsic motivation of knowledge workers
9 – Decentralise decision-making
For more on these principles visit
2) Real Agile Teams and Trains
Teams need to be cross functional and able to deliver working, tested increments. They should be self-organising, both at 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 with each other, and to deliver value to the organisation and its customers.
Product owners and scrum masters help the development 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 help 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 for 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) DevOps and Releasability
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.
Releasability means the capability to frequently deliver value to customers, in line with the demands of the market. The two aspects combine to help the organisation generate better economic results by putting features into the market and testing their value.
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 sprint.
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 architectural 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.