SAFe Agile Ceremonies And Events

SAFe levels involve two types: two Essential (Team, Program)

Events At Various Levels

1. Team Level

In the SAFe workplace, various agile teams gather to work on a common goal, and each team comprises 5-11 people.

They work on iterations of 2 weeks, and 1-4 weeks are also acceptable. The teams’ Scrum Master manages every iteration.

Iteration Planning:

• The scrum team meets to predict which team's backlog history can be replenished in the future iteration and prepare a presentation plan for them.

• They also agree on the purpose of the iteration.

• They invite SMEs (Subject Matter Experts) on relevant topics to the meetings to help understand the story details or how to deliver it.

Daily Stand-up:

• The agile team conducts it and meets at the same place/time to discuss the iteration goal’s progress and create a day’s plan.

Iteration Review:

• In this phase, the agile team validates the completed user stories in the iteration and gets feedback from customers, stakeholders, and business owners.

Iteration Retrospective:

• Teams agree to make the changes in the processes, practices, and work policies for potential improvements.
  

2. Program Level

It is work on ART (Agile Release Train) that comprises multiple agile teams (5-12 members in each) in roles that include:

1. Business Owners

2. Release Train Engineers (RTE)

3. System Architect/Engineer

4. Product Manager

When they work together in increments of 8-12 weeks, it is called Program Increment (PI).

PI Planning:

This 2-day event is where the members involved in ART gather to accept PI goals as a team.

They predict the:

• Team dependencies

• Risks

• Backlogs to be featured on high priority to be mitigated/resolved/owned
  

System Demo:

Shortly after each PI iteration is complete:

• The work done by all teams is integrated into the bridging environment and shown to business owners & stakeholders.

• The demonstration must be fully integrated

• This event does not change the team iteration estimates but reviews them

Scrums Of Scrum, ART & PO Sync:

• Team representatives are available regularly during PI to discuss progress against PI goals and other issues.

• It is like Scrum or Scrum (SoS) events in large ARTs where Scrum Masters, RTE, and team members will discuss work progress, obstacles, and dependencies within the team.

• And PO sync events are also there where the Product Owner, Product Manager, and end-users discuss priorities, progress, and scope alterations. For small ART meetings, the above said meetings combine into a single meeting by aligning all participants, called ART Sync.
  

Inspect And Adapt Workshop:

It happens at the PI end-stage and consists of three parts, as listed below:

• PI Demo Version:
  

  • It shows the present status of the solution and highlights the work done at PI

• Quantitative & Qualitative Measurement:

  • RTE provides ART statistics to the ART members during this

• Problem-solving Workshop:

  • In this, the teams provide a brief overview of the PI for 1-2hrs. The emphasis is on identifying the root causes of problems and addressing the root cause to avoid them in future program phases
    

Program Principles:

All the Scrum principles still apply here, although some of the terminology needs to change:

1. A team of teams – to maintain agility at the program level, a team of teams is developed. This is known as the Agile Release Train (ART), and it normally consists of 5-12 agile teams (or roughly 50-125 people) working together to develop the same or closely related features towards a common vision.

2. Time-boxing, iteration, and cadence – program work is also completed within time-boxes, but they must cover a longer period.

1. This is called a Program Increment (PI), and it consists of five full iterations (sprints) — 10 weeks by default.

2. Just like agile teams, the ART has a set of ceremonies that happen on a pre-determined cadence throughout the PI.

3. Features – program work is still maintained and prioritized in the program backlog.

4. But, instead of stories, you’re concerned with features.

5. Each feature will be decomposed into multiple user stories as work is assigned to various teams.

6. Ideally, no feature will be left unfinished at the close of a PI.

7. Like stories, Features are also sized using story points that are normalized across the teams on the train so that a story point represents approximately the same amount of capacity consumed for each team.

Program Roles:

Understandably, accomplishing all this will require different titles with different scopes of responsibility, but the roles they fill are familiar:

1. Product Manager (PM) – The Product Manager is responsible for choosing and prioritizing which features the ART will work on during each PI. They fill the role of Content Authority, as the Product Owner (PO) does at the team level, and one PM can support several POs. The key difference is that the Product Owner needs to be there for the team on a day-to-day basis while staying aware of larger business initiatives. The Product Manager focuses exclusively on the business goals.

2. Release Train Engineer (RTE) – The RTE serves the same role as each team’s Scrum Master, making sure agile processes are being followed consistently, and that the team of teams is functioning efficiently. They also help remove impediments that the teams cannot remove themselves. They fill the role of Execution Authority at the program level.

3. System Architect – There’s value in maintaining Technical Authority at this level as well, to establish technical guard rails and drive the establishment of an architecture runway with which the teams can apply emergent design concepts to evolve their design incrementally within the guard rails. The System Architect fills this role.

4. Business Owner – This is the only new role at the program level with no direct equivalent on a team. This is a stakeholder (or small group of stakeholders) with ultimate responsibility for the business outcomes from each ART. As such, they have an active role in many of the ceremonies and serve as primary liaison between the PM and executives.

Program Ceremonies:

The ceremonies used at the program level are similarly altered but accomplish the same purposes.

1. PI Planning

This ceremony scales up the concept of sprint planning. PI planning is a 2-day meeting held near the end of the last iteration of each PI, known as the IP iteration (for Innovation and Planning). There, the ART gets together to discuss the features being pulled from the backlog for the upcoming PI and create plans, at the user story level, how to implement those features. Stories at this point are not considered “sprint ready” but are defined enough to plan at this higher level of detail. The outcome of the PI planning session is a set of objectives that summarize what each team as well as the ART collectively will accomplish within the PI as well as a plan to get there, captured on the Program Board. As such, they are analogous to the concept of a sprint goal.

2. Scrum of Scrums

This ceremony scales up the concept of the daily scrum. While a daily standup with all the team members present would be impractical at this level, a meeting is held once or twice a week, allowing representatives from each team (usually the Scrum Master) to answer the same basic operational questions, focusing on the cross-team dependencies and impediments. In this way, all the teams stay in sync.

3. PO Sync

This ceremony scales up the concept of backlog refinement. While some parts of this meeting may be focused on clarifying the current PI scope, it’s main purpose is to focus on the future PIs in terms of features and roadmap to prepare for the next and subsequent PIs.

4. Inspect and Adapt Workshop

This ceremony scales up the concept of both the sprint review and the sprint retrospective. It contains three parts, the PI System Demo, Quantitative Measurement, and the Problem Solving Workshop. The first two parts correspond to the sprint review and the third corresponds to the retrospective. This meeting is held within the IP iteration just prior to the PI planning session for the next PI. During the PI System demo, the ART demonstrates the features that were completed within the PI to the key stakeholders and receive feedback from the same. The success measures for the PI are reviewed in the second part, and the ART does a deep root cause analysis on one or more problems that affected many teams on the ART within the PI and therefore helps the ART operate more effectively moving forward.