Back to top

Dispersed Planning - Part 2 - Facilitation

Author(s) 

Dispersed PI Planning - practicalities of facilitation

The second in a short series of articles on Facilitating Dispersed Planning Events with an emphasis on what organisations need to have considered and prepared prior to conducting a dispersed planning event rather than explicit instruction on how to do it.

Other articles in the series are:


2.1 Different Activities, Different Facilitation

A PI planning event is made up of many different activities happening in the predefined sequence that is the agenda. Each of the activities involves differing forms of communication and collaboration between different groups; from the straight up broadcast sessions of a vision briefing to the team and x-team collaborations of the team breakout sessions. Whilst the activities might serve a different purpose and utilise different inputs and provide different outputs; there is often commonality in how they are facilitated. The diagram below takes the standard agenda for a PI planning event and highlights the underlying style of activity that is occurring in that part of the agenda.

Figure 3: Classification of activities in PI Planning

Figure 3: Classification of activities in PI Planning
(click to enlarge)

The advantage of reducing the agenda to a smaller set of more abstract facilitation mechanics is that as a facilitator it becomes easier to see the overlap and determine which tools in the facilitator’s toolkit are most appropriate for the situation at hand. The rest of this article will cover the different facilitation tools that are needed for a PI Planning event and discuss the different ways that they can be implemented with a focus on the technologically simplest solutions where possible.

2.2 Broadcasting Prepared Content

Existing, prepared content needs to be broadcast to the wider group. Typically, this is prepared in advance of the event itself.

In PI Planning this would be the Day 1 briefing presentations from The Business, Product Management and The System Architects.

Checklist:
  • Can everyone see and hear the content?
  • Can the detail be questioned to clarify assumptions?

All the usual advice for running broadcast, online presentations applies: Test the technology, test it again, distribute the material in advance and have a back-up plan for when the technology fails.

The obvious improvements that people lean towards are to pre-record the presentations in advance so that attendees can watch them in their own time, at their own convenience. Pre-recording means less reliance on the technology having to work in the here-and-now. The risk is spread across time, which gives more time and opportunities to fix the situation if things go wrong. Also, with pre-recording individuals are not being asked to watch or present at inconvenient time slots such as the middle of the night.

But, pre-recording also has its disadvantages. If the pre-recording is done too soon then the information might become out of date. Pre-recording can break interactivity if there isn’t a mechanism to clarify assumptions; this can be more work for the presenter because they may have to clarify the same assumption repeatedly as individuals request clarification individually rather than everyone hearing the clarification once as part of an all-hands presentation. Finally, do the individuals have the discipline to watch the presentation at their convenience, rather than it being part of an organised agenda? Its importance may need to be explicitly prioritised over existing delivery pressures by the leadership.

2.3 Manipulating A Shared Artefact

Several teams, or individuals, all need to access and manipulate the same shared artefact. In PI Planning the two key activities that require this style of facilitation are “Selecting A Feature from the Program Backlog” and “Creating the Program Board”.

Checklist:
  • Can everyone access and manipulate the artefacts?
  • Are updates visible in near real-time?

The most important ability is for everyone to be able to access and manipulate the artefact; however, that doesn’t need to be direct access, indirect access through a person managing the artefact is always an option. In the event of two people or teams trying to access the artefact at the same time what are the rules of arbitrating who goes first. Having the ability to see the updates in near real-time1 is an important aspect of sharing the artefact back to the other teams.

Selecting A Feature

The program backlog is the key input to PI Planning and contains a prioritised set of work that the business would like the engineering staff to try and deliver over the course of the next PI. We, at IJI, always teach and coach trains to utilise the “Pull Mechanic” in PI Planning, teams select features from the Program Backlog in the Breakouts of the PI Planning event. This drives virtuous behaviour within the Agile Release Train in that teams can pick and choose features to balance load and demand. If features the feature distribution to the teams is pre-ordained there is more likely to be pressure to conform to make the features fit and the features are more likely to be sliced for filling a teams backlog rather than the preferred slicing along lines of business need.

The lowest technology solution is human driven. A person is responsible for maintaining the backlog, which can even still be a physical artefact of Post-Its on a wall. Teams that want to select a feature can contact them by phone or messaging application to request a feature and the person can in turn distribute photo’s or status updates back out to the Agile Release Train. Whilst this method may sound simplistic it does have benefits; the arbitration is done by a person, if two teams try to select the same feature then they can help broker negotiation between the two teams. The person can also relay any prioritisation advice coming from the management of the Agile Release Train and provide steering towards certain features. It’s an embodiment of the Agile Value “Individuals and Interactions over Processes and Tools.”. The person managing the backlog within the PI Planning event shouldn’t be the Product Manager because, whilst they are ultimately responsible for the backlog’s existence, they will need to participate in negotiations and discussion throughout the PI Planning Event. Since managing the backlog with the PI Planning event is a facilitation activity it usually falls to the Release Train Engineer or an assistant to the Release Train Engineer. This pattern is often used in Distributed planning events where remote teams need someone “in-room” to act as their eyes and hands.

A more technologically driven solution would be to use some form of shared document that each of the teams can access, update, and allow them to self-serve their selection of features. A simple Wiki page with a list of features that teams can put a mark against to say that they’ve grabbed them is sufficient. The wiki pages often have a simplistic arbitration mechanism if two teams are trying to manipulate them at the same time. The disadvantages are that the technology lacks the human element; it can’t provide steering and advice, it can’t tell you to talk to another team. Often existing technology can be utilised; many backlog management tools have a field to allow the backlog item to be ascribed to a team. If the features are left unallocated in the backlog management tooling in advance of PI Planning then, as teams grab features in the PI Planning event, they can assign the Feature to themselves. If a feature has been assigned, then it’s been taken. The disadvantages here are that it can be harder to get a simplistic overview of the state of the backlog from the tooling.

Building Program Board

The Program Board is one the main outputs from a PI Planning event; it provides a high level view of when value is expected to be realised, in terms of feature deliveries, and the collaborations and interactions between the teams needed to realise that value.

The lowest technology solution is, again, human drive. A person, possibly the same one managing access to the Program Backlog, manages the Program Board. They are contacted to put items onto the board and to link them together where collaborations occur. The state of the board can then be broadcast out to the Agile Release Train on a regular basis. Boards can be both physical where Post-Its and string are utilised and photo’s distributed, they can also be electronic such as a PowerPoint slide that is distributed.

A higher tech solution that allows the teams to self-serve, as they would at an In-Room planning event, are online infinite whiteboards such as Mural or Miro. These boards being completely free format rely on the discipline of the teams to ensure that the rules of building a Program Board are followed; namely, teams may only place entries into their own row. If a team needs to collaborate with another team then the work must be negotiated into the other team’s plans first and then they will place a ticket onto the Program Board that can be linked to to show the collaboration. The free format has the advantage that it allows the nuances of a physical board to be represented; tickets to the left of an iteration tend to be an indication that they will be delivered early in the iteration tickets to the right indicate later in the iteration. Up and down in the row and rotational angle can all mean something important to the team and/or train and be used to convey information.

Most modern backlog management tools profess having Program Board features but be careful as this is often a report generated from their internal data stores rather than a planning tool in it’s own right. Teams can mistakenly get caught up trying to get the data correct so that the Program Board displays as expected when instead they should be conversing, collaborating, and creating a plan. Data entry is not a spectator sport and is ideally done after the event.

2.4 Team & X-Team Collaborations

Individuals within a team need to be able to collaborate with each other as a team and teams within a train need to be able to collaborate with each other as a train. In PI Planning these collaboration activities happen within the two Team Breakout sessions.

Checklist:
  • Is intra team collaboration possible?
  • Is inter team collaboration possible?
  • How and where are team level artefacts stored?
  • How and where are train level artefacts stored?

PI Planning is an all hands activity where the individuals in a team collaborate to build a plan from the ground up that will get their team through the PI; therefore each team is going to needs its own space in which to collaborate in. Teams need both a shared communication space and a shared recording space.

Intra-Team Collaboration

The communication space provides the mechanism for intra-team collaboration and often inter-team collaboration. Everyone in the team needs to be able to speak to and, ideally, see everyone else. In the dispersed environment technologies such as Zoom, MS Teams or Google Hangouts (to name but a few) are providing the communication bridges that maintain interactions between teams even when dispersed.

The recording space is somewhere to store the results of the discussions that occur during the planning event. One aspect of that is the “plan” itself, the PI Objectives and nascent backlog items ready for the iterations, but another aspect is free space to support the discussions that occur; space for moments of inspiration and design that would normally occur in-room on scrap paper, flip-charts or whiteboards.

The pace at which the intra-team communications occur means that the technologically simplest option, photographing physical artefacts is rarely able to keep up. A webcam pointed at physical artefacts provide a live image but is the resolution of the webcam sufficient to realise the writing on the physical artefacts.

Online whiteboards provide a more technologically advanced solution; everyone can see the whiteboard at the same time and manipulate it.

Using existing technology might be sufficient; the facilitator sharing a screen of the backlog management tool for everyone to see. Many tools allow multiple people to be viewing and updating them in parallel. The facilitator needs to be wary of falling into the trap of trying to get keep the data in the tool perfect during PI Planning. In the physical world a couple of a words on a Post-It is enough to represent a story, enough to allow estimation, enough to assign it to an iteration to reserve the time and enough to rationalise and negotiate the collaborations that need to occur between teams. Not all tooling is capable of handling incomplete stories where the intent was to return to them later (possibly several weeks late in Backlog Refinement) to complete the story and refine the detail; if the tool complains stick in placeholder data but try to avoid wasting time creating perfect data to keep the tool happy when the time would be better utilised for collaboration. Data entry is not a spectator sport and ideally happens offline whilst the greater team is getting on with more useful value generation rather than watching a facilitator type.

Inter-Team Collaboration

As part of bigger Team-Of-Teams that is the Agile Release Trains, Teams will inevitably need to collaborate with other teams on the Agile Release Train to form the plan.

Everyone on the train needs the ability to access to all the Team breakout spaces so that they can join those teams for collaborative discussions. Typically, each team has their own communication space, links to these can be distributed in advance to the other teams. There is often a secondary, textual, back channel to be able to signal to another team that you want to collaborate or to pose simple questions. Try to ensure the barrier to moving communication spaces is as low as sensibly possible to encourage real face-to-face conversations to happen, if the barrier to movement is too high then the negotiations will start occurring on the back-channel which as a textual channel lacks the depth and richness of communication bandwidth that face-to-face conversation has; it’s quickly overloaded.

There is an increased importance on Scrum-of-scrums events to help cross team collaboration, but teams shouldn’t wait until the Scrum-of-scrums make contact early. Scrum Masters need to be keeping an eye on the communication channel for the indications that another someone wants to interrupt. I would always advocate that the PM and System Architect should attend so that the Scrum Masters can relay any advice back to their teams.

2.5 Broadcast Session Sharing Generated Content

Teams need to be able to broadcast the results of the work that they have done back to the bigger Team-Of-Teams. In PI Planning it is the Draft and Final Plan reviews where teams need to share their content with the rest of the Agile Release Train.

Checklist:
  • Can everyone see and hear the content?
  • Can the details be questioned to clarify assumptions?

For the two Plan Reviews within PI Planning the focus should be on Objectives2; those objectives need to be written up into a sharable form. This could be a low technology solution of photographing hand-written objectives or using simple, ubiquitous technology such as PowerPoint to share electronically. Facilitators need to be aware that it’s very easy to share the team workspace and then teams can get sucked into the presentation of detail rather than the high-level overview that the objectives provide. People will disengage if the presentation isn’t succinct and to-the-point; this results in the plan not being properly validated by the other teams which ultimate leads to the commitment being compromised.

There needs to be a mechanism to handle Questions & Answers. There needs to be a way for questioners to raise a hand and indicate that they have a question to ask. Many conferencing technologies provide the means to raise a hand; conversely any back-channel communications that have been set up could be utilised. Everyone on the Agile Release Train needs to be clear on the method being used and the facilitators need to be monitoring for requests. Perversely a dispersed environment is sometimes easier to manage than a distributed environment; in a dispersed environment everyone is equal they’re all at a disadvantage because they’re remote therefore everyone has to follow the rules, whereas in a distributed environment the participants in the main location are at an advantage over the remote participants and can break the rules and talk amongst themselves.

2.6 Whole Train Collaboration

Individuals and Teams need to be able to communicate to all the other Individuals and Teams within the Team-Of-Teams. In PI Planning it is the Management Review at the end of Day 1 and the closing ceremonies of ROAMing the Risks and the Confidence Vote that require whole Train Collaboration.

Checklist:
  • Can all participants be seen and heard?
  • Where are the outputs recorded?

Everyone needs to be able to hear everyone else but unlike the previous “Broadcast Session Sharing Generated Content”, which focused on reviewing the shared content, the focus here is on the conversations. Whilst the focus is on the conversations the results of those conversations often need to be recorded for future use. The challenge is in the facilitation of these conversations and the working agreements in place to allow everyone’s voice to be heard.

Management Review

The Management Review requires participants from the central group including Release Train Engineer, Product Manager, System Architect and Stakeholders and I would always advocate one representative from each team be present that can provide insight into team level detail. Whilst this isn’t strictly the “all the other” individuals within the Agile Release train it’s enough people from across the train that the underlying facilitation style still makes sense.

The management has the least structure of the three activities within PI Planning; it is a conversation around What happened? What advice do we need to offer back? Everyone’s voice needs to be heard as every opinion potentially matters; request to speak working agreements will be useful here and the facilitator needs to keep an eye on people wanting to speak. The group also needs access to shared and team generated content to provide input to the discussions if necessary.

Roaming Risks

Each team brings up their Program Level Risks and the Agile Release Train as whole determines how they should be handled. A representative from each team reading out the risks is a facilitated activity therefore easily handled; the conversation that follows is free format and therefore needs facilitation. Request to speak working agreements will be needed; facilitation to encourage individuals and teams to speak up and volunteer to take ownership of appropriate risks.

Confidence Vote

This is the most structured of the three activities within PI Planning; each team is asked in turn “What’s their confidence in their team plan?” then everyone in the bigger team-of-teams is asked “What’s their confidence in the whole plan?”. Everyone’s vote counts so everyone needs a voice; if there are issues then the individuals need to be allowed to speak so that those issues can be addressed and it is at this point where the activity can change to free-format conversation.

2.7 Preparation

Preparation prevents problems.

Within the PI Planning Event itself there is precious little spare time for communication and training outside the absolute necessities of what’s needed to generate a plan that brings the Agile Release Train into alignment and agreement on what can be done and how it could be done. Therefore, any training on revised processes or adjustments to tooling should be communicated in advance. Tooling in particular, you want teams to be focusing on the collaborations and communications required for planning in planning rather than wrestling with a misbehaving tool; provide training on and practice using the tooling in advance. Obviously, the more the tools are used the more familiarity people will have with them, the more natural their use becomes; the DevOps mentality of “if it’s painful do it more until you fix it or it fixes you”, i.e. you learn how to use it.

Simpler tools are simpler to learn; tools that impose process impose constraints to a team’s ability to adapt.

Always have a simpler back-up, if you loose access to a tool what are you going to do? The more people involved in the section of planning event the more important it is to have a back-up that is readily accessible; consider the cost of a 100 people sat around watching someone trouble-shoot misbehaving technology?

Facilitators, particularly the RTE, might find that having a separate PC for running the event is useful. It can continue running the main presentation whilst they on their own machine are free to move around the teams. When not being used to show the slides that are currently being discussed it’s useful for the presentation machine to show the agenda, details of the breakout rooms, etc…

2.8 The End Before the Beginning

In this article we’ve looked at techniques for facilitating the sections of the big all hands event at the center of SAFe®, PI Planning. But, for many organisations that are already running the first all-hands event that they need to facilitate in a dispersed fashion is not going to be PI Planning but the Inspect & Adapt ceremony that happens a few days earlier. The Inspect & Adapt will be the topic of our 3rd and final article in this short series.


#1 Near real-time could be updates every few minutes rather than millisecond response levels
#2 A series of Blog posts on Objectives can be found here (https://www.ivarjacobson.com/publications/blog/writing-good-pi-objectives) with the PI Objectives and the PI Planning Process found here (https://www.ivarjacobson.com/publications/blog/writing-good-pi-objectives-pt3)