What are the SAFe events?
In the Scaled Agile Framework® (SAFe®), there are regular events (meetings) at different levels. What are they, who should attend, and what is their purpose?
Different configurations
SAFe is made up of an essential part and two optional levels. The essential part includes ‘team’ and ‘programme’ levels. The optional levels are ‘large solution’ and ‘portfolio’.
Events at each level
Essential – Team Level
In SAFe an agile team is made up of 5-11 people and works in iterations, typically two weeks long. Iterations between 1 and 4 weeks long are acceptable. Each iteration has 3 events facilitated by the team’s scrum master, plus a ‘stand up’ event each day.
Iteration planning
The agile team meet to forecast which of the stories from the team backlog can be completed during the next iteration and form a plan to deliver them. They also agree on an iteration goal. The team may invite relevant subject matter experts to specific meetings, or for part of those meetings, to help them understand the details of the story or how it could be delivered.
Daily stand up
The agile team meet at the same time and place each day to discuss progress towards their iteration goal and make a plan for the day.
Iteration review
The agile team demonstrate the stories completed during the iteration and invites feedback from customers, business owners and other stakeholders.
Iteration retrospective
The agile team identify and agree to implement, potential improvements to their processes, practices and team working agreements.
Essential – Programme Level
In SAFe, a programme is worked on by an agile release train (ART), which is typically made up of
5-12 agile teams
Their associated business owners
Shared services teams
A systems team
The release train engineer (RTE) for the ART
The product manager for the ART
The system architect/engineer for the ART
Collectively they work in increments of 8-12 weeks called a programme increment (PI).
PI Planning
Programme increment planning (PI Planning) is a two-day event where everyone in the ART gets together to agree on team and overall PI objectives. They also forecast which iteration of the priority features on the programme backlog will be completed. As part of this, dependencies between teams are identified and planned, while risks are identified and either resolved, owned, accepted or mitigated.
ART Sync, Scrum of Scrums and PO Sync
Over the course of the PI, there are regular check-in sessions for team representatives to discuss progress towards the PI objectives and other topics.
For large ARTs, it is likely there will be a scrum of scrums events where the RTE, scrum masters and other selected team members discuss progress, impediments and inter-team dependencies. There will also be PO Sync events where the product manager, product owner and other selected stakeholders discuss progress, priorities and scope adjustment.
For smaller ARTs, the above meetings can be combined into a meeting with all of the attendees, called an ART Sync.
System Demo
Shortly after the end of each iteration in the PI, the completed work from all of the teams is integrated into a staging environment and is demonstrated to business owners and other stakeholders. It is essential that the demonstration is of fully integrated work. This event does not replace, but is in addition to, the team’s iteration reviews.
Inspect and Adapt workshop
This event takes place right at the end of the PI and is made up of three parts: the PI system demo; quantitative and qualitative measurement; and the problem‑solving workshop.
The PI system demo is similar to the system demo but it show the current state of the solution, highlighting the work done throughout the whole PI, not just in the last iteration. Also, the entire ART (the members of every team) is invited and many of these people will not have been to the system demos.
During the quantitative and qualitative measurement part, the RTE presents ART metrics to the members of the ART.
In the problem-solving workshop, the teams conduct a relatively short (1-2 hours) retrospective on the PI. The focus is to identify the root causes of problems and identify actions that can address the root cause to stop the issues from presenting themselves in future programme increments.
Optional - Large Solution level
For a large solution, the cadence does not change from the programme level, it is still a programme increment of 8-12 weeks. At the large solution level, we refer to the capabilities of the system, rather than features or stories.
Pre- and Post-PI Planning
In order to coordinate work across multiple ARTs and also with suppliers, there is an alignment meeting both before and after the individual ART PI planning sessions. Synchronisation of the PI planning events is essential in order for the pre-and post-PI planning events to be meaningful and happen within a few days of each other.
Solution Demo
During the solution demo, the development efforts of the solution train (multiple ARTs and work from suppliers) are made visible to customers and other stakeholders. This event is a both a celebration of the work achieved in the last PI and an opportunity to gain feedback ahead of the next one. It is an opportunity for the customer and other stakeholders to influence upcoming work. During the event, capabilities are demonstrated, including any stated compliance and non-functional requirements.
Attendees usually include customers, large solution stakeholders, representatives from each of the ART (e.g. product managers and product owners), solution management, lean portfolio management (if used) and the solution train engineer (STE), who is likely to be facilitating this event.
Optional – Portfolio Level
The events at the portfolio level are much less prescribed, as they vary greatly based on the structure of the organisation. Below are examples of events that may take place at this level.
Lean Budget Review
A periodic review of how the portfolio budget is distributed across the different value streams. This could be done using a technique such as participatory budgeting where the LPM collaborate with business owners and other stakeholder to agree on how much budget is needed to run the business and how much remains in order to grow the business.
This kind of event is likely to take place twice per year.
Communities of Practice
The agile programme management office (APMO) can support communities of practice for RTEs and STEs, as well as scrum masters, to help the sharing of ideas across the portfolio.
Portfolio Sync
The APMO, or other lean portfolio management (LPM) stakeholders may facilitate a portfolio sync event. The purpose of which is to see how well the portfolio is progressing towards meeting strategic objectives. The events may also review value stream and programme execution. This should be no more frequent than every two weeks.
Roadshow
This is an enterprise-level demonstration of work completed across multiple solution trains. Can be used to get feedback and input, ahead of a lean budget review event.