Bringing everyone on an Agile Release Train (ART) together for PI Planning is a significant effort. While both the Agile manifesto and SAFe highlight the benefits of face-to-face planning, often organizations will need to run these events across multiple locations. The reasons for a distributed PI planning event can be varied – it may be due to financial constraints, very large teams in highly distributed locations, extensive travel time and cost commitments, difficulties with visas, or even as the result of unplanned travel restrictions such as those being experienced currently with the spread of the Coronavirus. Regardless of the reasons, every organization adopting SAFe will benefit from having a plan in place for effectively conducting PI planning with geographically distributed participants.
This advanced topic article brings together guidance from our own experiences and those of our customers, partners and the SPCT community on how to successfully manage a distributed PI planning. It focuses on the following 6 areas and shares tips within each one:
- Planning Locations: Determining the number of different locations needed.
- PI Planning Agenda: Creating a PI planning agenda to accommodate multiple time zones.
- Facilities: Ensuring the appropriate physical space to conduct the planning.
- Working Agreements: Meeting the needs of the event attendees.
- Tooling: Employing technology to support the different planning activities.
- Facilitation: Executing a successful distributed PI planning event.
Determining the number of planning locations is an important first step. Two scenarios are possible. Either the individual teams themselves are collocated but distributed from other teams, or individuals on the teams find themselves dispersed across different locations or even working from home. The latter scenario adds another level of coordination and complexity. Organizations should seek to avoid this pattern and bring members of each team to a single location wherever possible.
In the first scenario, where each team is together but distributed from the other teams, efforts should still be made to consolidate the locations. Even something as simple as moving from two offices in two cities to one office in each city can create material benefits without incurring significant travel costs.The focus should be on bringing the teams that will have strong dependencies with one another together at a common location. However, even bringing together multiple teams who may not have much overlapping work, reduces the number of planning locations, lessens the feeling of isolation, and creates the feeling of shared experience for those taking part.
Some organizations with distributed teams have key roles such as Business Owners, Product Management and System Architecture/Engineering in the ‘home’ location with the teams working remotely. Something that we have seen work well is to reverse the direction of travel and send these individuals to the remote locations so they can be with the teams in person. Of course, the locations they attend can, and should be rotated so that each team feels the benefits of having these stakeholders on hand for immediate resolution of questions.
SAFe Tip: The PI planning toolkit, available from the Scaled Agile community site, includes a team roster. Use this to record the locations of the individuals on all the teams and include this in the handouts on day 1 of PI planning. Additionally, include details of the time differences across each location. This will be a critical reference when planning the technical and logistical support needed for the PI planning event.
PI Planning Agenda
Once the locations to be used for PI planning have been determined, the planning agenda can be created. ‘Respect for People and Culture’, one of the pillars of the SAFe House of Lean, reminds us that we should avoid asking the teams to work late into the night. Regardless of whether they are happy to do this, the quality of the plans will suffer if teams become sleep-deprived!!
Instead, we recommend creating a 2.5-day split agenda (further extended to 3 or more days as required) that accommodates a wide span of participating time zones. An extreme example of such an agenda across two locations, Delhi and Los Angeles, with a 12-hour time difference is shown in Figure 1 below. (The PI planning toolkit contains an editable version of this agenda.)
PI Planning Day 1
As can be seen from the example above, the overlaps between time zones are carefully selected to facilitate live interaction at critical points in the agenda. Starting on the morning of day 1, the briefings should be attended remotely by everyone on the ART. Alignment is the goal of PI planning and if the teams are to work independently for a portion of the event this alignment, and the questions that are raised and answered during the briefings to confirm understanding, are critical.
SAFe Tip: If it is not possible to have all the teams attend the briefings at the same time, an alternative is to record and distribute the briefings ahead of time and then use a smaller portion of overlapping time for questions.
The planning process briefing from the RTE is also important in this situation as they will run through the working agreements and agreed upon methods of communication and collaboration (more on this later).
PI Planning Day 2
Important additions to the regular PI planning agenda are the team synchronization points. These are the overlapping times where the teams can work with key stakeholders and collaborate with the other teams who are on different time zones. The duration of these synchronization points should be made as long as possible given the time zone restrictions.
SAFe Tip: Ahead of these synchronization points the teams should consider who they need to work with. They can use an online ‘booking sheet’ document or a calendar to block out time with the individuals and teams that they need to work with.
The draft plan review should also make use of the available overlapping time. This allows adherence to the presentation structure of ‘PI Objectives, capacity and load, and risks’ and ensures the time box is maintained. The management review and problem-solving meeting may also involve individuals from different locations. With a distributed PI Planning event it can be useful to extend the invitations to this meeting to include at least one person who has been working onsite with each team. This could be the Product Owner or Scrum Master if they are in the same location as the team but could also be another team member. This approach makes sure that no information ‘is lost’ due to the distributed nature of the planning.
PI Planning Day 3
The second team synchronization point includes the Business Owners assigning business value to the PI objectives. Again, the use of an online document with pre-determined time slots, around 10 mins each, for the teams to highlight when they want the Business Owners to contact them works well here.
The conclusion of planning, which includes the presentation of the final plans, confidence vote and the risk roaming should be done with all the teams present. Often the confidence vote for each team is taken ahead of time and the results communicated by the Scrum Master for that team to reduce the complexity of gathering this information in real-time. The combined ART confidence vote however must be done together once all plans have been shared, with everyone visibly providing a first of five in front of their respective webcams. Of course, at the end of day 2, if the planning is running ahead of schedule, the RTE can adjust the agenda to allow the teams to finish earlier than planned. Commonly the PI planning retrospective is managed as an online activity in the days following the event, so the attendees aren’t kept any later than is necessary.
SAFe Tip: Whatever agenda you arrive at, one thing that must be done is circulate it well in advance of the event. Not only do people need to clear their calendars they will also need to make the necessary arrangements outside of work such as childcare and transportation.
The first consideration here are the breakout rooms. With collocated PI planning the emphasis is on having everyone in the same room. This is usually not feasible when phone or video conferencing conversations need to take place, as the background noise can prevent clear communication between teams. Every location will need several breakout rooms setup and ready to go. A good starting point for the number of rooms required is one breakout room per team plus one or two additional rooms for key stakeholders to utilize and a room for the scrum of scrums. All regular meetings should be cleared from these rooms for the duration of the PI Planning event.
SAFe Tip: Each breakout room should have a pre-prepared ‘contact list’ with the details of the other breakout rooms and who they are for. A set of video conferencing links within an online document makes this process even smoother. Consider also having a permanent computer set up in each room. This reduces the potential problems as people connect and disconnect different laptops during the day.
For those locations that are working late into the night, make sure that the appropriate arrangements have been made so that the lights, air conditioning, power and other facilities will remain on after normal working hours. [Ed. You’d be surprised how often this is not the case!!] Similarly, for those starting earlier in the morning, ensure they can access the offices before a normal working day would have started.
Since many of the team members will be working late into the evening, consider organizing transportation to get them home after the event if the public transport they would normally take is not available or if safety could be a concern. During the event itself make sure that food is provided, particularly for the teams working well into the evenings when other options may be limited.
Facilities and tech support are critical during all PI planning events but even more so when the event is relying so heavily on remote communication channels. Ensure the individuals with these skills are dedicated to the event, with no other commitments during the 2.5 days, and that there is no time when they are not reachable. This may require a group of individuals working in shifts. Have an open messaging channel to these individuals so teams can raise any issues and agree upon a process for escalation if there is a serious blocking issue.
Although tooling will be covered later, it is important to emphasize the need to test the chosen technology ahead of the event. Critically, this test must be done with a representative ‘load’ on the system. A successful test of two people using a system is not reflective of what happens when 100+ people are using it concurrently during PI planning. Instead, run the tests in the previous weeks and enlist the help of employees across the organization to create a suitable load. Backup systems should also be available. Every tool that is used has the chance of failing just at the wrong moment – more often than not when the Business Owners are presenting the business context!!
SAFe Tip: For every tool that is being used, there should be an answer to the question, ‘what is the backup if it fails?’ As an example, if our ALM tool goes down we can use the spreadsheet where we exported the previous day’s data. This is especially critical for systems supporting connectivity between locations.
Working agreements serve several purposes. They create a set of norms that determine how the teams want to work together to be most productive. They also allow the facilitators to hold attendees to these pre-agreed guidelines, and the teams to hold themselves and each other accountable. And of course, they are refined iteratively – the feedback from a previous event feeds into an improved set of working agreements for the next event.
Although we would encourage all PI planning events to have a set of working agreements, they are a must when running a distributed PI planning. Often meetings begin with reserved time to formulate these working agreements, but given the scale of this event it is recommended to start with a seeded list (some of the working agreements may require preparation), perhaps then allowing some time for additional items to be added. Figure 2 shows some example working agreements:
The first working agreement in this example is the most critical and often the hardest habit to form. Remember as soon as anyone talks without a microphone, all other participants in other locations will be cut off from the conversation. Other working agreements might include the facilitator repeating each question to ensure the remote sites heard it clearly. Pausing for questions after each presentation and proactively asking the different sites if they have anything they would like to add is highly recommended. Have webcams always turned on so people can see as well as hear each other. And of course, respect the time boxes – given the concessions being made to extend the working day, teams need to have appropriate breaks and start and end at the agreed upon times.
SAFe Tip: Evolve the working agreements iteratively not only from event to event but also within the PI Planning itself. If something is not working or a team requests a new working agreement, add it and communicate it.
Tooling is the cornerstone of distributed PI planning and several different types of tools are required in combination to support the activities that take place. Although the specific choice of tools will vary widely from organization to organization, the different tooling categories are explored below.
1. Information Storage and Distribution
Throughout the course of the event there will be information that the teams need to access. This could range from the briefing slides from the morning of day 1, to photographs of the program board, to the scrum of scrums information radiator. Agree ahead of time where this information will be stored online and include sub-folders for each team as well as a general all hands folder. This will also support teams sharing information with one another. Make sure everyone in the event has the appropriate permissions to read and write to the agreed locations. Consider an internal intranet or portal site with all of the appropriate links teams will need throughout the event for easy access.
2. Instant Messaging and Group Chat
Although face-to-face communication via webcams is good for longer conversations, more regular snippets of information need to be continuously passed between teams and individuals to resolve questions quickly as they arise. An instant messaging tool should be employed and preferably one with a group chat functionality. Ahead of the event, groups for each of the teams should be created within the messaging tool along with some additional groups such as a Scrum Masters group, a Product Owners group, a Facilitators group and others. Being able to drop a question into one of these groups increases the likelihood of a swift response.
SAFe Tip: A good addition to the working agreements is that someone in each of these chat groups takes turns continuously monitoring these information channels.
3. Video Conferencing
Video conferencing will be heavily used during the event. Choose a tool that will meet your requirements for the expected number of concurrent users. As mentioned previously, have a document that everyone can access with pre-prepared links for connecting to the video conference channel for specific breakout rooms. Although normally an electronics-by-exception event, every attendee in the distributed PI planning should have their laptop available if not always on. That way if they receive a notification for a breakout conversation with someone from another team, there is little preparation required.
One additional way of employing video conferencing that we have come across is to ‘point’ the webcam at a source of information, such as a program board, white board, or projection screen. Our experience is that the fidelity of the image is insufficient for this use case. The collaboration tools described below are often better suited in this instance.
Extensively test the video and audio technology in a dress rehearsal with all remote locations well before the event. While individual components may be technically working, other environmental factors may result in a poor participant experience. There is no substitute for real people experiencing the visual, auditory, and ease of use of the total experience to ensure that the technology will support and not detract from the effectiveness of PI Planning. For example, low cost webcams and microphones are often inadequate to create the intended interactive experience.
SAFe Tip: If possible, have two video conference connections setup from the main planning room. One to show the person currently speaking and another showing the event attendees. This ensures that all the teams can see each other.
4. Collaboration Tools
A set of tools have emerged that support cross team collaboration, many from companies who are Scaled Agile Platform partners. These tools often mimic online whiteboards where the user has complete freedom to create their own templates and design a shared collaborative space. We have observed teams and ARTs using these tools to create team planning boards, capturing PI objectives, roaming risks, and documenting the outputs from the scrum of scrums. No team collaboration space should be locked, so other teams can ‘drop in’ in the same way that they would walk past another team’s boards during a co-located event.
In terms of managing the program board we have observed several patterns. If the number of locations is minimal, perhaps 2 or 3, many organizations choose to replicate a physical board across the different locations, kept up to date by the facilitators at each site (more on that shortly). However, we are often seeing collaboration tools also being used to replicate this artifact. Indeed, the popularity of PI Planning has led to the creation of dedicated program board tools that combine the best of both worlds – a touch screen providing the tactile experience of moving sticky notes around with the requisite connectivity that ensures data is shared across all sites. Keep in mind that the same rules apply – a conversation is needed before putting something in another team’s swimlane on the program board.
SAFe Tip: Although not as sophisticated, there is still much to be said for simple online documents. At Scaled Agile we have used an online spreadsheet as a way for teams to present their draft and final plans. We found this improved the visibility for remote employees in preference to squinting at flipcharts over a webcam.
5. Agile Lifecycle Management (ALM) Tools
Regardless of whether the organization is doing distributed PI planning, many employ ALM tools to manage the complexity and scale of their development processes. In addition, these tools are an integral part of their Continuous Delivery Pipeline and connect with other tools in an automated fashion, also providing the required level of traceability.
Many of these tools include some of the collaboration capabilities mentioned previously and are therefore a great addition to a distributed PI planning event. One word of caution: PI planning is focused on developing a high-level plan. When entering data directly into an ALM be mindful of the mandatory fields that you may be required to complete or the different steps to go through in order model different planning scenarios. This additional data entry overhead may distract from the larger intent of the PI planning event. If at all possible, these details should be completed after PI Planning. Finding the right balance is important.
SAFe Tip: While technology brings many benefits, it also adds additional challenges. With everyone face down in their laptops, collaboration can be compromised. Whenever possible have the teams project the information onto a shared screen in their team breakout rooms and take turns to ‘drive’. This simple technique helps to maintain the collaborative nature of planning.
Facilitating the Event
Successful facilitation of a distributed PI planning event takes practice and each event is an opportunity to learn and improve for the next one. However, some common guidelines have emerged that act as a good starting point.
Facilitators at Each Location
The first is to have a named facilitator at each location. In some circumstances each facilitator will be managing large groups of people with multiple presentations taking place from each site. In other situations, it may just be a Scrum Master sitting with the remote team. It could also be a team member if the Scrum Master themselves are remote. The sentiment is clear – the facilitator needs to share the team experience and feel their challenges when an audio line is bad or multiple conversations are making it difficult to understand, for example. When this happens, they can take the appropriate actions to get it resolved.
SAFe Tip: Have a group chat open for the ‘named facilitators’ to quickly escalate the challenges they have identified, or the team have raised with them. This group should be constantly monitoring and communicating with each other.
It is often the case that a ‘home’ location has most of the attendees with a smaller number distributed. If this is the case, requiring the RTE to both facilitate the event as well as monitor requests and issues coming in from the other external facilitators is too much cognitive load for one person. Have 1 or 2 additional people dedicated to assisting the RTE at this main location. While the RTE is supporting the local execution of the event, the others are constantly monitoring the interactions of the remote teams and identifying where they can provide help.
SAFe Tip: One organization we have observed doing distributed PI Planning staffed a support desk at each location. The people at this desk were not part of the ART and so were 100% focused on supporting the teams. Each desk had their own backchannel to their counterparts at each location. When a team at one location for example had difficulty reaching someone at another location, the support team could take that task and work with their counterparts to chase down the right people with the communication request, so the teams could stay as focused as possible on planning the work.
With the additional complexity that a distributed PI planning brings, some prior alignment around these processes pays off. The RTE should work with the Scrum Masters in the lead up to the event to clarify all the aforementioned activities and do a dry-run of the event, considering some of the different scenarios that might arise and the steps that should be taken to resolve them. The Scrum Masters play a critical role during these distributed PI planning events and need to be completely clear on the process, know how to use the tools effectively and have a good understanding of the locations of every team.
SAFe Tip: Scrum Masters should do their best to stay abreast of the different locations of the teams both at the beginning of planning but also as the teams disperse into their breakout rooms. Tracking down the right people at the right time is one of the biggest challenges with this type of distributed planning. Consider including phone numbers and email addresses in the ART and team rosters when possible to help alleviate this difficulty.
Although bringing everyone together delivers great benefits, not only just in terms of the plans that are created, but also in creating and deepening relationships, the reality today is that many organizations have ARTs that include teams distributed around the globe. Many organizations have demonstrated that these same benefits can be achieved with some prior preparation and additional considerations. Indeed, continually adapting and improving our systems of work is an ongoing endeavor that we are all committed to. This article has summarized some of these success patterns that have employed to great effect.
We would like to thank our customers, partners and SPCT community for continuing to share their ideas and experiences on distributed PI planning. As new patterns and recommendations emerge, we will continue to add them to this article. In the meantime, you can continue the discussion on distributed PI planning in the online SAFe community forums.