The new Normal - Dispersed PI Planning Event (PIPe) is the new Distributed PIPe

The new Normal - Dispersed PI Planning Event (PIPe) is the new Distributed PIPe

What is the difference? 
In addition to have Teams sitting in the Office cross Continents (distributed) now everybody is sitting alone at home (dispersed). In the last Two Month we learn a lot.
 
What learnings can you share with us?
1. It actually works better than expected. The effort of transforming a co-located PIPe (always better) into a distributed PIPe is worth it! It’s not necessarily because people will only want to do distributed planning afterwards, but rather because the change of perspective usually improves the way we use our methods and tools, even for new approaches. There is a lot to learn and, as the saying goes, „good things take time“, so …
2. Prepare, prepare, prepare to have enough time to deal with the surprises that will definitely crop up. Thinking through the PIPe process enables you to choose an agile approach in many places. For example, if you have the right tools, things can actually be easier in the distributed world than in the physical world. There are currently clear functional preferences for the tools (Zoom, Miro, Jira, Slack), but there are also other options (Teams, Concept Board, TFS, Excel). It’s faster and provides better quality for the users, and you can easily have more than 100 people involved. It can easily take several person days to prepare for this, so it is very important to have a lead time of several weeks.
3. Make it as similar as possible to the previous experience. Use this principle: Think from the user’s perspective and consider how you can make his or her work easier.
4. Minimize tool distractions. Always set tools up from the user's perspective. That means, as is often the case, less is more. Less variety in the operation and involve the users early on or know exactly what Scrum Masters, Product Owners and teams need to be able to focus on their jobs.
5. Practice and learn how to use it. For example, start 4-8 weeks in advance and then iteratively, incrementally build it out end-to-end.
6. Use the PDCA Cycle to create what‘s needed: 
a.          Iteration 1:
I.           Place the prioritized Feature Backlog on a Planning Board 
II.          Design the Program Board
III.         Define the Team Boards
IV.         The ROAMing Board – this can be a photo
V.          The Voting Board and, last but not least
VI.         The Retro Board, which has proved to be very successful 
Review meeting with users -> Collect feedback then continue … 
 
b.          Iteration 2:
I.           Display Feature Backlog team color assignment => Each team has its own color
Feature Backlog indicator for the Business Owner, showing what‘s currently in the planning stage.
II.          Program Board Team names (repeat color in the columns)
Program Board inbox queue for dependencies (Scrum Masters manage this and sort it by the priority of features).
Designate owners for general tasks (e.g. Scrum Master or Product Owner, or Business Owners).
III.         Prepare Team Boards in the way that the teams are used to, as a template for all Post-its or user story cards,
Prepare Fibonacci series 
IV.          …
Review meeting with users -> Collect feedback and so on......... See KEGON’s Remote PIPes training for further tips. 
 
c.           Iteration 3:....
 
7. Don’t perfect it. As the saying goes: A fool with a tool is still a fool! So after 2-4 iterations switch into training mode.
Definitely do a Dry Run. Learn from the Dry Run – it’s not uncommon to have problems with security and settings. Allow enough time for the Dry Run, and a few days to fix any issues. The fact that the tools may be allowed to be used does not necessarily mean that they can actually be used.
8. Use video: If technically possible (Zoom), work with the video camera on.
9. Have a technical admin with you, who is able to get everything up and running again in case of any problems. This reduces anxiety.
Give Operations a heads-up that problems may arise as a result of this unusual load and usage behavior.
10. Follow the Agile Manifesto – hahaha, what was that again….?
- Individuals and interactions - over processes and tools
- Working software                     over comprehensive documentation
- Customer collaboration           over contract negotiation
- Responding to change             over following a plan
 
Remember - the right side is allowed as long as it promotes the left!! And then, have fun and enjoy this constructive approach to running a distributed PI Planning Experience (PIPe).