What do you need to prepare a Remote Program Increment Planning Meeting?
On the 3rd of March 2020, we supposed to start a new Program Increment with a client I was coaching. A decision was taken on short notice — just one day before the PI planning. Back at the beginning of March 2020, little we knew that two weeks down the line, the entire planet would work remotely, and in less than a month, more than 2.6 billion people would be under lockdown.
In this article, I’m sharing my experience as a Release Train Engineer organizing a Program Increment Planning Meeting in times of COVID-19.
A standard PI Planning Agenda is:
General preparation for a remote (short notice) PI planning meeting
For the communication, you can select any tool the team is familiar with. If you have a company standard, I suggest you follow it. You have a wide choice between Skype, Teams, Zoom, Leaf, Google Hangouts. Tip: make a test with a large number of participants.
Prepare multiple meeting rooms: a main-stage room where everyone meets and one virtual place for every team. Every room will need to be accessible by everyone, and they should all have full rights in the meeting — mainly to share the screen.
Recommendation of technical setup for the participants at the main stage room:
- Everyone has a microphone, headsets and a camera. By default, they are all off. It is essential to have headphones because the laptop speakers will create an eco.
- Do not connect to big room meeting over VPN because it might be prolonged and load the VPN.
- Instruct everyone to be on time and to have water next to them to hydrate themselves.
For each point on the agenda of the Program Increment Planning meeting, you will need different tools or preparation. Therefore I have grouped the sessions based on the setup and preparation they need to have. Note: they aren’t in the order of the list.
Business Context (Day 1) and Planning Adjustments (Day 2)
These sessions will involve the participation of all the participants in the first stage meeting room.
In most of the cases, these are presentations using a tool (e.g., PowerPoint) or a free speech. I recommend using the video of the person who speaks to improve the communication of the message. It will not be possible to share +100 people videos, but at least the person talking should share the camera. The Release Train Engineer should be the one having the presentation and share it. There should be a link available where the participants can access the presentation handout in case the quality of the video is poor.
Product/Solution Vision and Architecture Vision & Development Practices (Day 1)
This session will take place also on the main stage, with everyone participating in it.
I strongly recommend to use the project management tool you use every day as support for these presentations, and here’s how:
- Do you want to show the product roadmap? Use Jira Features board or Big Picture or Team Foundation Server(TFS) Features boar in combination with the presentation tools to highlight the vision and the priorities for the next Program Increment.
- Do you want to show the development practices? Show them directly in the build pipeline, so everyone is clear on the expectations. You can have multiple windows open with various steps that you want to highlight. There is no need to do a full demonstration.
The significant advantage of using a tool is to make the speeches more practical and exciting for the teams. It might not be handy at first, but it saves you so much rework of transforming the vision into action items.
Preparation done before: the feature boards and any other plugins should be part of the day to day work for Program Managers and Product Owners. Before the presentation makes sure they are open, the information is correct, and there is no need for any cleanup or misunderstandings. Opt for a slightly minimalist version of the boards.
Backup solutions: For the cases when there might be technical issues with sharing the screen, I recommend having a print screen of the boards in a presentation and the link to the boards so everyone can follow the meeting support independently.
Tip: I strongly recommend these speeches to be as specific as possible. Present numbers, present clear objectives, trackback the goals to the product backlog, be aligned.
Planning Context(Day 1), Team breakouts (Day 1 and 2)
Now is the time for each team to go to their virtual squad room. PI planning is a lot about cross-team communication, resolving cross-team dependencies, and planning together. Here is where the role of the Release Train Engineer (RTE) is critical to encourage people to move between the rooms.
These rooms are with a small group of people, and I recommend everyone shares their videos and microphones. We want people to communicate together.
When it comes to the tools you work, each team has two options: one person shares the screen and updates, or everyone is using the same instrument and contributes at the same time. Both Jira and TFS allow the possibility of seeing the sprint planning for several sprints ahead and the information. I recommend the team boards to stay in your project management tool. Before the PI planning, the RTE sets up the boards, and the teams get familiar with them.
The Program board contains features and risks. I recommend you use a tool like Miro/ Mural/Kendis that is more visual. The Release Train Engineer prepares the program board several days before and debriefs the team on how to use them. The RTE also hands out instructions on how to use the program board and explains it to the groups.
Backup solutions: If your team is not familiar with Miro/ Mural/Kendis, or the costs are high, you can also use One Note. You can create a table that simulates the Program board. The downside of it is that you are less flexible in linking the dependencies.
For the risk board, I recommend using the project management tool. Both Jira and TFS can have the risks item type configured, and you can display the risk matrix. For me, this was a huge step in managing risk at the program level. Some of the risks need top management intervention, and they are used to look at presentations. Tracking them in a tool, seeing their impact, and their probability facilitates enormous resolution during the PI execution.
Draft Plan Review (Day 1), Final Plan Review (day 2), Program Risks, Confidence vote(day 2)
These are the moments when everyone comes together on the main stage, and the main stage rules get in place (microphones and cameras are off). Instead of the physical board, the teams will use the Program board to highlight the features planned, the dependencies, and the risks.
I do recommend that only one person (the Release Train Engineer) shares the screen and give the control one by one to different presenters from each team. It saves a lot of time and hassle to don’t need to switch the presenters. The RTE will make sure the links are known by all the participants in case there are technical issues, and he/she cannot share the screen.
The output of this meeting are topics that need management problem-solving. For the facilitation of the remote collaboration, each issue that must address in the management problem-solving workshop has as assignee the person who’ll represent this topic.
Management Review & Problem Solving.
You are welcome to use the main stage for this purpose. For this meeting, it is imperative the preparation before. I recommend to the RTE to take a 30 minutes break and to prepare for this meeting done remotely, rather than stepping into it as it usually happens when onsite: the RTE make a simple board of topics. Each participant representing a particular topic prepares the impact and the options of each issue to be discussed. There is only one board of the problems. The participants look for solutions to the challenges in the order of importance. For this purpose, I recommend you use Jira and TFS, and you log the actions.
Planning Retrospective and moving forward
The retrospective board can get built as you go during the PI planning but also at the end. Independent of the retrospective format you select, you can use an interactive tool: Miro/ Mural/Kendis — the tools you are familiar with, or ideazboard or funretro.io.
- clear and simple explanations
- the fewer tools the best
- send out the handouts ahead
- be punctual and keep the time
- test the infrastructure with the key participants. The microphone needs to have a clean sound
- involve the participants
- take breaks
- make it collaborative
- share the camera in the small group workshop