Dispersed PI Planning Part 1 - Preparation

The first 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:

• Part 1 - Preparation
• Part 2 - Practicalities of Facilitation
• Part 3 - Retrospection

1.1 Abstract

With more and more people working from home, many organisations that have adopted SAFe® are having to adapt their processes in order to accommodate completely dispersed teams. Distributed teams and activities have always been a necessity; organisations were often unable to bring everyone together for the all-hands activities due to mundane issue like money and visas. In this short series of blogs, SAFe® Fellow Brian Tucker, will draw upon 8 years of experience of helping to facilitate dispersed PI Planning events in many differing organisations. There is no definitive “Right Way” to run a PI Planning event, let alone a distributed or dispersed PI Planning event, every organisation is different and every situation is different; what this blog hopes to do is explore some of the reasoning that should underpin the adoption of distributed working practices. Subsequent blogs will look at some of the experiments that have worked and highlight some of the issues that facilitators will need to bear in mind when preparing for their own distributed PI Planning Events.

1.2 This Isn’t Going To Be Easy

The more distributed in time and space the people are
the longer things will take

The more distributed in time and space the people are
the shorter the session length they can bear

Ian Spence, SAFe® Fellow

The juxtaposition of these two observations means that the total time from start to finish that the activities take is going to increase significantly from the standard 2day all hands present agenda familiar to most.

The longer things will take. Having worked with organisations where entire agile teams are distributed across 4 time zones, with a total time differential of 8hrs between the two most extreme time zones, it’s obvious that the team can only collaborate for a few hours a day. In this particular instance there was 4hrs of overlap that corresponded to European morning, Indian afternoon and East Asian evening. With only 4hrs of collaboration available per day the standard 16hr agenda of a PI planning event gets spread out across 4 half days. The teams have the remaining half day when they’re not collaborating on the PI Planning event to pursue other activities within the IP sprint, typically the innovation activities.

The shorter the session length they can bear. Sitting on a conference call listening to disembodied voices talking is hard, it requires significant concentration and it’s very easy for the mind to wander. Most people need a 5-minute break every hour, a 15-minute break every 2 hours and 4 hours is often the maximum. Even if an organisation is not distributed across time zones if the participants are dispersed it might still need to adopt an agenda of 5 half days in order to ensure that the time participating is quality, focused time¹.

1.3 You’re going to need more tech!

But possibly not as much as you might think.

If a team has become dispersed, then it’s obviously going to need some technology to hold it together now that it’s in disparate locations. Many organisations already have video and audio conferencing software in place and there are online options quickly available for those that haven’t; a small team (personal experience having worked on a team spread between London, Cambridge and Edinburgh) can still functionally communicate through the absolute basics of a phone line and email. It’s not the technology that’s important; it’s the discipline to make that phone call when the technology, even the best technology, still presents a greater barrier to communication than talking across a desk.

A team also needs the ability to share artefacts and results. Many organisations already have source code repositories (or design, document repositories for non-software teams) that accumulate the results that the team is producing. A team often needs a space to share other documents relating to design and progress; again, this doesn’t need to be high-tech, a shared directory, a wiki or an online file sharing service are enough to share common documents.

Many organisations focus on technology for the sharing of artefacts at the expense of the technology needed to encourage communication, interaction and elaboration. The obsession with tools to make the sharing of artefacts easier often drives the interactivity away because of the fixation on keeping the tooling correct and individuals becoming subordinate to data entry rather than having collaborative discussions. Make sure that everyone knows how to use the provided technology. Ideally run training in advance and dress rehearsals to ensure it behaves as expected. All these services need to be made accessible to the dispersed teams either through VPN or login through a public facing interface, or appropriate corporate policies and advice if using external online services. Ensure any external participants, e.g. Agile Consultants or 3rd Party Suppliers, also have access to all the relevant information. The PI Planning event is busy enough in its own right and running it dispersed is going to make it harder; don’t add to that by trying to tech. support new tools in the event. When using external tooling make sure you understand where your data is being stored and what it will be used for; check the fine print on the license terms before inadvertently releasing corporate confidential information into the outside world. That doesn’t necessarily mean no external tooling; just be careful what you record there, we’ve seen planning events where the stored data used codewords or even just the Id of the item in the internal backlog management tooling. “Id #3159” means nothing to external eyes but everyone internal knows that “Id #3159” means “super-secret feature”. If someone external knows that “Id #3159” means “super-secret feature” then you’ve got a more fundamental information security issue than the use of external tooling.

1.4 Who needs to collaborate?

If you’ve ever attended an IJI training on SAFe® you’ll probably have seen the trainer visualise the PI Planning agenda as the letter W. This visualisation is powerful because as well has illustrating the progress through time of the agenda, it also highlights what level the agenda activities are targeted at.

Figure 1: W representation of PI Planning agenda (click to enlarge)

Day 1 starts with the Executive Briefing, which is highlighting the organisation’s long-term goals, by its nature this is Portfolio level concern. The focus moves on to the Product and Architecture presentations which deal with what this Train needs to do in this timebox; plus, a little bit of a look ahead in case that influences this timebox, therefore Program level concerns.
With the briefings complete the teams move into the breakouts; the focus here is building Team level plans, although teams will inevitably need to interact and influence other team plans.
At the end of Day 1 everyone comes back together as a Train, the Program Level, to perform the Draft Plan Review and Management Review. This is the mid-point of the W.

Day 2 starts with Planning Adjustments being communicated back, a Program level concern. Before dropping back down to Team level for the 2nd Team Breakout session.
Halfway through Day 2 the train comes back together for Final Plan Review, Risks, Commitment and Retrospective, all of which are Program Level concerns.
After the event, the commitment can be communicated up to senior managers and across to other release trains which being across trains makes it a Portfolio level activity.

Activities at the Program and Portfolio level where information is shared across teams need to be done at the times where everyone in the Program can be present. The most important part of the agenda is to know when the key synchronisation activities of Draft Plan Review and Final Plan Review are going to occur. These synchronisation activities need a defined time at which they will occur, and teams need to be ready for these points in time, but they can self-organise to meet that deadline as they set fit. If activities finish earlier than expected, typically the day 1 presentations, then later activities can be pulled forwards and started early.

Figure 2: An example agenda - PI split across 4 half days.

1.5 Different Activities, Different Facilitation

In this article we’ve looked at some of the challenges that face organisations that must deal with Distributed or Dispersed activities. In the second article we’ll look at practicalities of facilitating specific activities within a SAFe® PI Planning event.

^#1 The Covid-19 pandemic of 2020 caused large numbers of schools to shut their doors; working half days can alleviate some of the childcare pressures this is causing.

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

How to Prepare for PI Planning Series PI Planning - Just Say No To Waterfall Thinking

States of Epics The EPIC lifecycle