Contact

Dispersed PI Planning Part 3 - Retrospection

Dispersed PI Planning - Inspect & Adapt

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:


3.1 The End Before the Beginning

For many teams already in flow, and executing Program Increments, whilst the focus is undoubtedly on the PI Planning Event the reality is that they will have to survive an Inspect & Adapt event first. The Inspect & Adapt event is a big all-hands event that is as tricky to facilitate in distributed and dispersed scenarios as the PI Planning Event. In particular, the Problem Solving Workshop portion of the Inspect & Adapt requires groups of individuals to collaborate together to solve problems; groups that aren’t the normal teams so the individuals involved might not be as familiar with working with the other participants as they are when they are a members of their normal agile team.

Figure 3: Classification of activities in Inspect & Adapt

Figure 3: Classification of activities in Inspect & Adapt
(click to enlarge)

This article will look at each of the three parts of the Inspect & Adapt ceremony in turn and the challenges associated with facilitating those sections in dispersed environments.

3.2 System Demo

The system demo is an instance of a Broadcast Session sharing Generated Content, as discussed in Part 2 of the series.

The facilitation style leans towards Generated rather than Prepared content because the demo should show as close to a live system as sensibly possible, not a PowerPoint showing what the team had wanted to build but hadn’t managed. The Demo is an embodiment of “Agile manifesto Principle #7 : Working Software is the primary measure of progress”; it should be demonstrating working software. Of course, there are always exceptions; I’ve seen examples where organisations have resorted to showing the outputs of batch processes because the run time of the batch was too long to be run live, I’ve even resorted to showing a video of a test when the test involved large physical equipment that was located several kilometres from the office where the Inspect & Adapt ceremony was being held, but each of these exceptional demos was always the output of the working software having been run.

The challenge when running the System Demo dispersed is that it is very easy for teams to drop into Presentation because it is easier to share a PowerPoint over the video conference tools than it is to run a demo of a live system. Just because it is easier doesn’t mean we should be doing it. A compound issue is that we all know how exciting it is to watch PowerPoint slides on a video conferencing link! One way to keep the demonstration focused is to use the Aggregated Program Objectives as a guide. This keeps the focus on the high-level value delivered rather than descending into technical minutiae.

3.3 Metrics

The Metrics section can be challenging. If the act of scoring the Objectives is done in the I&A event then some form of Whole Train Collaboration facilitation will be needed whilst the Objectives are scored. It is challenging enough to keep everyone engaged in-room whilst the other teams are being scored, the dispersed nature and video conferencing raise that challenge by another factor. Consider spreading the scoring activity out through the whole PI by scoring the objectives as they’re completed, or in the Iteration System Demos. This is discussed in more detail in Part 4 of our blog series on Objectives.

The remainder of the Metrics section of the agenda is an instance of a Broadcast Session sharing Prepared Content as discussed in Part 2 of the series. Typically the central roles of RTE, PM and/or System Architect present the other metrics that the Agile Release Train should be tracking and using to drive improvements; improvements to both the engineered system being delivered and the development system delivering the engineered system.

3.4 Problem Solving Workshop

The Problem Solving Workshop section of the Inspect & Adapt is run as an Open Space event; new teams, known as affinity groups, are formed around the problems that they want to solve. This poses a slightly different set of challenges for the facilitators compared with the PI Planning where the teams are known about in advance and typically stable.

Open Space Collaboration

The I&A has a different dynamic from PI planning. In PI planning teams are “static” they are the teams they’ve always had (teams can change during PI planning but it’s an exception rather than a rule) however those teams need communication channels between the teams in order to collaborate (walking across the room for a co-located event, electronic stand-ins for distributed and dispersed events). In an I&A the teams are “dynamic” they are formed in the event and because it’s an Open Space event they can change during the activities; however there is typically no collaboration across the teams during the activities themselves.

Checklist:
  • Does each open-space area have its own collaboration space?
  • Can every participant get to every collaboration space?
  • Where are the outputs recorded?

The event needs a collaboration space for every problem being solved and everyone needs to know how to get into every session in case they want to join it. Each session still needs a named facilitator (a mix of SMs and Agile Coaches) who were made the host of each session. Teams then formed dynamically by people logging out of the main session and joining one of the other Zoom sessions.

Collaboration spaces were discussed in Team & X-Team Collaborations in Part 2 of the series. However, there are some facilitation challenges with Open Space groups; the groups are newly assembled, they’re still at the “Forming” stage in Tuckman’s stages of team development and the shyer members may not be willing to speak and provide input. Getting everyone to talk is a challenge; often conversations are dominated by just a few voices and the visual clues to see whether the rest of the group agrees aren’t as readily accessible in the dispersed environments as they are in person. Facilitators need to be aware of this and gently encourage the whole group to participate rather than let one or two dominate.

Because of the technical limitations, bigger teams are more likely to occur. It is not as easy to split a big group into two smaller groups that solve the same problem in parallel as it is in the in-room scenario because setting up new collaboration spaces can be time consuming. With bigger teams, it is more likely that voices won’t be heard and participation isn’t as engaged; this is problematic in the long-run because people that aren’t engaged start to question why they’re there, the event loses its potency and real systemic change fails to be enacted. Sometimes it is worth setting up additional collaboration spaces in advance just in case they are needed and taking the time to ensure that all groups are in the facilitation sweet spot of 5-9 people by breaking down larger groups. Two groups solving the same problem isn’t an issue; they can happily work independently and share thoughts and ideas at the end of each section; essentially this becomes an embodiment of the Set Based approach discussed in SAFe® Principle #3 - Assume Variability; Preserve Options.

Everything takes longer online. Where in-room an hour might be allocated end-to-end for the whole Problem Solving workshop; in a dispersed environment it’s going to take at least half as long again, if not more. Entering data into online tools isn’t as quick as markers and flipcharts. Online events need regular breaks; a 5minute break between root-cause analysis and brainstorming is often necessary and is the natural break between the first half of exploring the problem space and the second half which explores the solution space.

The workshop doesn’t need sophisticated tooling; most activities are facilitated and it’s the facilitator that records the data. Any tooling that allows words to be captured on a screen will work; the online White Boards discussed previously or even just a blank PowerPoint are all good candidates for recording the results of the workshops. More technologically sophisticated would be the use of Mind Mapping software to help conduct the Root Cause Analysis as that software is tailored to generating tree structures.

3.5 Coaching Dispersed Events

Trying to coach a dispersed session is much, much harder.

When everyone is together physically in a big room there is always the ability to “stand above it”, to keep an eye on the proceedings and move to teams if needed; passive observation rather than requiring active requests to alert you. In a dispersed planning event, once everyone disappears into their rooms they are gone, there is no visibility unless they stick their head out (or the electronic equivalent) and shout. Coaches will need to actively tour the breakout rooms to see check that teams are making progress; but online this becomes more intrusive than the passive observation of the physical big room, so treat with care and caution.

The dispersed environment becomes a forcing function for SAFe Principle #9 : Decentralize Decision Making; translated into the facilitation space this becomes Decentralize Coaching. There is a greater need to rely on the in-team coaches, the Scrum Masters. Invest time before the Planning event with the Scrum Masters; make sure that they are comfortable with the processes, the tools, that they understand the channels available to request additional help if necessary.

Passive observation is often available through the tooling. Watching the backlog tooling and online whiteboard tools allows the coaches to see the artifacts being manipulated. These can be leading indicators that prompt the more direct intervention of entering a team’s breakout room. The limitations of observing the artifacts are that you can’t observe the human interactions; those observation need to be done directly by entering a breakout room.

3.6 Conclusion

Over the course of this blog series we’ve explored some of the thinking that should go into choosing Process, Practices and Tooling for running the large events that occur within the Scaled Agile Framework in a dispersed and these articles 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.


More Great Topics for Agile Teams

How many Features do you take to PO Planning? PI Planning Tips

On the Nature of Portfolios; WSJF Estimating Portfolio & WSJF

Program Level WSJF & Feature Slicing Program WSJF & Feature Slicing

All about Managing Dispersed Planning; WSJF Estimating Dispersed Planning Series

States of Epics The EPIC lifecycle



Contact Us