In planning events, the program board is intended to be an information radiator for the timing, dependencies, and risks in the program. It shows complexity around dependencies, risks to meeting milestones, teams who have too much on their plate, and dependencies that have not been accepted and committed to yet. If you are interested in learning how to license the Program Board Builder, please contact Mike Shalloway.
Many coaches and consultants steer groups toward creating a physical board during the event because of the visibility and the collaboration it creates. When done for the first time, there can definitely be a “fun” factor or novelty associated with it and can even be seen as a team-building event. However, groups quickly discover that creating and maintaining a physical board during the event is a significant burden that slows down and detracts from the essential aspects of the event.
Challenge #1: Creating a physical program board slows down and detracts from the essence of the planning event.
However, a physical board only functions as an information radiator when people are able to update it and see it. When space, location, and/or budget constraints forces people to plan in separate locations, it can significantly impact their ability to create, update, and view the holistic planning board in real-time, often requiring additional people just to help out with these activities.
Challenge #2: Physical boards are hard to build and use when attendees are not collocated in the planning space.
Furthermore, it’s common for groups to discover that they need to combine or split swim lanes on the board (e.g. splitting into smaller teams or identifying distinct shared services groups). Additionally, they may discover that they need to add columns before or after the plan, or even split columns due to teams with unmatched planning cycles (e.g. teams with 2-week sprints vs. teams with 3-week sprints). Changes such as these can be extremely difficult to make during an event, if not entirely impossible.
Challenge #3: Structural changes to physical boards can be prohibitively difficult during the planning event.
And finally, after planning is done, the program board should continue functioning as an information radiator by representing the latest known information on timing, dependencies, and risks to the program. With a physical board, however, moving it and keeping it updated after initial creating is extremely cumbersome, if not entirely time-prohibitive.
Challenge #4: Physical program boards are hard to move and maintain after the planning event.
The Net Objectives Program Board Builder is a tool that removes all of these challenges, and the constraints imposed by these challenges, allowing groups to focus on creating, updating, and responding to the plan quickly and efficiently, both during and after the planning event.
This page describes both why and how to use the Program Board Builder to help run effective planning events. The Program Board Builder has the overall purpose of improving the program increment planning event. It does this by both building the program board with little effort as well as by enabling things not possible without the tool.
These benefits are described in more detail after explaining how the tool works. This overview is completed to give a sense of the value of the tool.
The tool effectively turns the program board from being merely an output to being a tool that improves the quality of the event itself. Consider this, what is the cost of a program board where it is not easy to see the dependencies as a whole?
The Program Board Builder is as simple to use as entering information into a spreadsheet. In fact, that’s all you do (a Jira and VSTS integration module is in the works). The board operates on a CSV file that is generated from a shared document such as an Excel Sheet or a google sheet. Click here to see how it actually run it.
We’ll run through using the board in the following example. Figure 2 shows the board after a single entry. In this case MBI “M6” (rightmost column) is dependent upon story “S17” (“Mockingbirds 3rd sprint). The red borders indicate that the dependency has been noted but not committed to.
The bold border indicates that we do not have a commitment from the team building the dependency for the date. For example, the Finches team may have just told the Sparrows team that they need S1 by the third sprint, but until Finches agrees to complete it in a specific sprint, it should remain uncommitted, allowing us to easily track this for resolution and to highlight plan risks. However, in the event that Sparrows are not able to commit to completing it by sprint three, negotiation should ensue to resolve priority conflicts as necessary. Once negotiations have been completed, this should be entered into the input sheet and the red borders are removed – indicating a commitment to the dependency as shown:
Completing the board
Continue this process, entering stories and dependencies and making agreements, until you create the finished board such as shown in Figure 4.
A challenge with the program board is that it captures so much information. While an overall sense of how interconnected PBIs are, there are usually so many strings present that it is difficult for any team to see what they need to to manage their dependencies and what depends on them.
A team wants to see their own PBIs and any PBI they are dependent upon and what those dependent PBIs are dependent upon. A team also wants to see what is depending upon them and any teams they may to work with to meet that dependency. For example, if you were on the “Crows” team, you want to see the following PBIs:
When run with the “Crows” filter on, the display will look like that shown in Figure 5.
Using the tool in a planning event can be done one of two ways. If you want to emulate the planning board being built at the front of the room simply have a computer there that people come up to and enter onto the sheet instead of putting things on the board. This computer can display the board with a projector after each entry. However, with shared files, it’s usually preferable for each team to have its own computer in addition to the “room” machine displaying the board. In this case, a person from one team would go to the other team, have a discussion and then update the PBIs involved on one of the teams’ machines. The “room” computer would then just update the display based on this new information.
In any organization big enough to use SAFe there will almost certainly be some teams that will represent bottlenecks to development. A key tenet of Lean is to defer commitment until you have sufficient information to make a good decision. The challenge in planning events is that teams often make commitments to other teams when they have only received some of the requests they are going to get. While it is possible to change a manual board, the expense of doing so often precludes it from happening.
It is suggested that the tool be used to discover all dependencies and put them into the tool without commitment on the first day. Then, once most (more dependencies will certainly be found) depdencies are known teams can make promises with the big picture in mind.
Some of the benefits of the Program Board Builder are simply speeding up building the board. This allows for teams to focus on their work and improve collaboration. But when automation is available, other benefits arise that would be too costly if done manually.
The Program Board Builder facilitates activities program increment planning events require. Here are some of the important activities it facilitates.
Note that these last two are not discussed in SAFe documentation but can easily be done without the tool. If a team is dependent upon another team and that team has not agreed to the date, the stickies for those PBIs should not go on the board. But sometimes they do anyway. In this case, mark both stickies as “tentative” when putting them on the board. Marking release dates by individual teams (when they occur) can be done by easily have a special stickie that indicates when the release will occur.
The Program Board Builder creates and manages new information and opportunities. Here are some of the new capabilities.
It is usually desirable to have participants in the same room; however, this is often not possible. Very often, Planning Events require participants from remote locations. Giving these people situational awareness of the board goes a long way to making them feel like they are involved.
As shown in Figure 6, the Program Board Builder allows remote workers to interact with the Planning Board in real time. While is it possible to not even have representatives of the team at the event, it is highly recommended that someone from the team is physically in the room during the planning event. This at least partially offsets the loss of collaboration from the event now being partially remote.