Develop on cadence is the heart beat of an Agile Release Train and the PI Planning essential to align teams across the ART. If the event runs with distributed teams, it takes place simultaneously at multiple locations. It’s no secret that doing distributed big room plannings is a challenge both operationally and communicatively.
It’s all about people, respect them and define a Lean-Agile Code of Conduct for all your teams participating in your PI Planning. Let me give you a few examples.
These are just a few examples. Find your own to set an awesome stage for communication.
Before PI Planning define a clear toolset and channels you will be going to use to connect your teams. Don’t start with a PI Planning not knowing which tool you use to build up a channel for the Scrum of Scrums. It will be highly inefficient if you head into such discussions while planning. Clarify who will own the channel and which devices you will use as endpoints. Keep in mind, you will have outcomes which need to get viewed by every team at the same time. Setting up a channel which synchronizes the results of every team may be the most important channel.
In co-located plannings teams use physical boards to visualize their plan for the upcoming PI. At the program level, a huge board is used to visualize dependencies between teams, feature delivery and milestones. Having distributed teams makes it hard to synchronize boards simultaneously at multiple locations. Build up a separate Program Board at every location is a bad idea. How should that work? “Hey! I added dependency A from team A to Iteration 3, please do the same on your board…!” — NO! Instead use a tool and synchronize at least the Program Board, your PI Objectives and the Risk Board in real-time. That will make collaboration much easier.
A few general points for your distributed PI Planning session:
Having a single source of truth for the different aspects of a PI Planning is essential. Especially for the Program Board, the Team Boards, the Risk Board, and the PI Objectives (remember essential 3). Avoid building up and managing a physically synchronized Program Board at each location. To keep physical Program Boards in sync is almost impossible. Already in advance, make sure that every team starts PI Planning based on the same information. If there are general questions you’ll lose valuable time at the beginning of the PI Planning.
What codes would you define to set an awesome stage for the PI Planning?
Let us know. Text us your thoughts at firstname.lastname@example.org or comment below. These are the first five of the ten essentials. The second part will follow shortly.
At one point every Release Train Engineer has his first PI Planning. Some things will go as expected but there will be more than five things that won’t go as planned. Don’t let it demotivate you...
Everybody is talking about the challenges of distributed collaboration in companies. There are conferences, symposia and many blog posts on best practices dedicated to this topic. Often it’s only about the collaboration between three or fewer teams or even just between employees.