Home Scaled Agile Tips for using the SAFe program board

Tips for using the SAFe program board

by Srinivas Saripalli

The Scaled Agile Framework® (SAFe) is a collection of procedures and practises used by large organisations to scale Agile methodologies throughout the enterprise. SAFe is intended to unify multiple cross-functional teams in order to foster greater collaboration, flexibility, and alignment of project strategies and goals.

Recommended Reading: Things You Need to Know Before moving into Agile Transformation with SAFe

Program Increment (PI) planning sessions are critical SAFe events that bring together diverse teams to collaborate on a common goal. Additionally, the SAFe program board is a significant output of the PI planning sessions.

Discover how a SAFe program board works and how to effectively use one.

What is a SAFe program board, and how do I create one?

The SAFe program board is an interactive, visual document that teams can manage and update as the PI’s work progresses. The board, in particular, enables team members to visualise:

SAFe program board
SAFe PI Planning – Program Board
  • What features, dependencies, and milestones is the current PI planned to have?
  • What is being worked on/what work is required Who (which team) is accountable for completing specific tasks
  • When will the work be completed?

Historically, program boards were physical bulletin boards mounted on a wall. To represent features, dependencies, and milestones, teams use a series of color-coded sticky notes. The red string indicates the relationship between dependencies and features and milestones.

A physical board may be advantageous for smaller businesses where it is more convenient to gather everyone in the same room for PI planning. However, digital solutions for creating and managing program boards are available, allowing these boards to be shared and easily accessed by all participating teams, regardless of their physical location.

Digital program boards are more effective for large enterprises or dispersed teams that are unable to gather all team members in one room. Even smaller teams may wish to go digital in order to maintain a more comprehensive record of their PI planning sessions.

  • What type of work is being performed?
  • Who is carrying out the work?
  • When will the project be completed?

The layout of the program board should be simple. Typically, a program board will include the following:

  • Columns: Create columns to represent the PI’s planned iterations. You can add an additional column to the board’s right side to hold items that need to be moved to the next PI.
  • Include a row for each participating team with a label. The top row is for milestones and events and is not labelled with a team name.
  • Sticky notes: Color-coded sticky notes are used to represent events and milestones, features, and dependencies in the columns and rows.
  • String or yarn is used to connect dependencies to features and milestones on a physical board. Lines are drawn on a digital program board to represent the connections.

How to configure your SAFe program’s board

During scheduled PI planning breakout sessions, teams established the SAFe program board. In breakout sessions, teams discuss and define the PI’s features, dependencies, and milestones.

Once your columns and rows are configured, you can begin populating your program board with the work you hope to accomplish during the PI. Here are a few pointers to assist you in assembling your SAFe program board.

1. Begin with the characteristics.

Teams decide which features to include in the PI in light of the business context and a common mission. Each team creates a sticky note to represent a feature on the board. The location of the sticky note indicates which team will work on it and when it will be completed.

2. Identify dependencies

Teams examine the features and determine if there are any dependencies between them. Dependencies are represented on the board by a sticky note with a connector connecting the feature to the dependency.

For instance, Team A may discover that they are unable to develop a feature due in Iteration 1.3 until Team C develops an API. So all Team A needs to do is add a dependency on Iteration 1.2 to Team C’s row, correct?

Wrong.

Team A is unaware of Team C’s workload and therefore has no authority to dictate when their work should be completed. Rather than that, the two teams must collaborate to find a solution that works for everyone. This is why PI planning meetings are frequently held in person (or via video conference)—you want open communication and collaboration between all teams.

After both teams reach an agreement, they create a dependency on the board to ensure that both teams understand and agree on the dependency’s acceptance and resolution date.

3. Establish benchmarks or events

A milestone is a visual representation of progress toward a specific goal, such as delivering a drop to another team or client, preparing specific features for demo at a trade show, or completing the final product release.

Milestones are dependent on a variety of different features that must be completed before the milestone can be met. In the top row of the column for the iteration in which the milestone is expected to be met, sticky notes representing milestones are placed.

Suggestions for simplifying the process

Now that you’ve mastered the fundamentals, meeting with your team to collaborate and create the SAFe program board isn’t always as simple as 1, 2, 3. Consider the following suggestions to streamline the process.

Sort your sticky notes by colour.

Make your sticky notes color-coded so that team members can quickly identify features, dependencies, and milestones. There is no universally accepted standard for assigning colours to specific elements. Numerous businesses use red to indicate dependencies, blue to indicate features, yellow to indicate milestones, and red string (or red curved lines) to indicate connectors.

The colours you choose are irrelevant as long as the entire enterprise uses them. The consistency will prevent teams from wasting time explaining to their teammates what the colours mean.

Not to be forgotten are shared services.

Shared services teams, such as user experience, architecture, and security, provide support to a variety of teams that are not necessarily involved in your PI. Ascertain that shared services teams are aware of the work they must perform, have the capacity to perform the work, and are capable of completing the work within a specified iteration.

Maintain simplicity

You want the program board to be straightforward and easy to read. A disorganised board with multiple connectors crisscrossing and lengthy dependency chains can be difficult to read.

For instance, if a feature has an excessive number of dependencies, you may not be prepared to address it in this PI. Alternatively, if you discover a dependency that is scheduled to be resolved after the feature on which it is dependent is completed, you may encounter an issue.

These types of issues can be escalated to the management review meeting, which takes place at the conclusion of the first day of the PI planning sessions. The management team will discuss the issue and will pose the following questions:

  • How critical is that feature to this PI?
  • Is it possible to move it to the next PI? Will deferring it provide enough time for teams to resolve dependencies?
  • Is it possible to distribute the dependencies to other teams that have the capacity to work on them during this iteration?
  • Is it necessary to eliminate the feature entirely?

The management team will make a determination allowing you to proceed with the project.

Is it better to have an analogue or a digital SAFe program board?

You may be able to complete a PI successfully with an analogue program board, but you will have to jump through a lot of hoops.

Boards made of physical materials, such as a whiteboard in a conference room, are not portable. What happens to the board following the conclusion of the PI planning sessions? You can photograph the board and email it to everyone, but what happens when the board requires updating?

Digital program boards have numerous advantages over analogue program boards, including the following:

  • They are portable and convenient for later use during the PI.
  • They are easily scaleable to accommodate any number of teams involved in the PI.
  • They can be stored and shared centrally, allowing for 24/7 access regardless of where your teams are located.
  • They foster collaboration by allowing teams to manage and update the board virtually through face-to-face meetings.

They can be created through platforms such as ATLASSIAN JIRA.

They enable you to include additional metadata. The JIRA board enables you to connect detailed data from other documents to the board. When data in the source is updated, it is automatically updated in the visual program board.

Creating and managing SAFe program boards requires considerable planning and effort. They provide valuable information that helps teams stay aligned and focused. After taking the time to create the board, ensure that it is not ignored or forgotten by your teams. Consult the board frequently to ensure the success of the PI.

Image Credits:

[1] Program Board: https://www.scaledagileframework.com/pi-planning/

You may also like

Leave a Comment

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More