Not too long ago I posted the first part of this two-part blog. Check out the first part here: 10 essentials for a distributed PI Planning (Part 1)

#6 — Test, test and test again

Working simultaneously at multiple locations means working with digital support. That may be video conferencing, VoIP, chats and synchronized Team and Program Boards. Plan enough time to setup digital channels and test them. When everything works fine, test again! Provide a special team which is responsible for an up and running infrastructure at every location. Those people should be available during the whole PI Planning. A stable and reliable internet connection is essential and yes, maybe expensive. But honestly, a working video conference channel is worth the money having 150 people waiting for a running infrastructure instead.

#7 — Enable Analog Behavior

Remember individuals and interactions over processes and tools. One reason why a PI Planning gains its magic is because people use easy to use tools like sticky notes, pens and walls to put collaboratively created plans on it. Don’t disrupt analog behavior just because you’re doing distributed planning. Instead, choose tools and communication channels that still focus on people and their interaction.

#8 — Use Queues

A lot of energy, focus and enthusiasm may sometimes lead to unwanted disruptions. Especially if your teams plan distributed, you don’t want to be disturbed every 2 minutes with a loud “rrrring-rrrrrring”!”. Therefore I recommend to establish queues for other teams questions and dependencies. Define time-boxed slots where the whole or part of the team is fully focusing on solving dependencies, answering questions and talking with stakeholders. Between these slots let your team focus on planning the PI.

#9 — Define SPOCs

Having a Single Point of Contact in place will keep your team work efficiently. Don’t allow a dedicated line to every person during the team breakout sessions. There should be just one channel from one team to another. Define a person who keeps an eye on a queue, chat or video conferencing tool and takes the hat of a “channel-master”. Not necessarily but in many cases the Scrum Master is responsible to act as a guard for the team.

#10 — Continuously Improve

Scaled Agile points out that the first PI Planning will not be perfect. This also applies to the first distributed PI Planning. That doesn’t matter. Define a setup to execute your first PI Planning (the other 9 essentials may help). Then learn from your teams experiences and create an improvement backlog for the next planning regarding your infrastructure, channels and tools. With more than one hundred people planning there are various expectations to meet. Talk about improvement potential with engineers as well as executives during and after every PI Planning.

We are still interested in your thoughts. What codes would you define to set an awesome stage for the PI Planning?
Let us know. Text us at innovate@piplanning.io or comment below.

‍