Remote PI Planning Has Been Revised to Reflect Lessons Learned & Improvements Made
I created a blog post on my experiences with the Scaled Agile Framework (SAFe) and Remote Program Increment Planning (RPIP) for a customer approximately a year ago, and it has since been deleted. In this project, eight teams worked together to construct a unified e-commerce platform across three time zones while working within a strict budget. During the months prior, we collaborated with another contracting company to find the most effective approach to organize our teams for the project. When I wrote my previous blog article, I described the tools we utilized as well as the tips and tactics we learned when conducting our first Remote PI Planning session. We have been able to demonstrate how good Remote PI Planning can be in this post because of the modifications I have made to our setup, pre-planning, and planning, which I will share with you in this post.
Recommended Reading: Discovering what happens in PI Planning
One very key point to remember is to strive always, always, always to plan in a large group setting since it is well worth the effort. Otherwise (and even if you can), please continue reading!
How are things going for us?
We are officially amid our fifth straight quarter of using the Scaled Agile Framework, and more specifically, Remote PI Planning, to accomplish our objectives. The end of June marked the completion of PI number five, during which we continued to increase our predictability by concentrating on six important areas:
- Establish a culture of value by starting with excellent product management and even greater communication.
- Improved logistics: you’ll feel like you’re all in this together even if you’re not physically together anymore.
- Pre-planning: plan, a second plan, and a third plan.
- Get the appropriate personnel in the right place at the right time: Spend your travel money carefully to ensure success.
- Keep people involved by distributing the workload.
- Tools: use actual boards to plan, virtual boards to track and communicate, and co-locate whenever possible to save money.
In the sections that follow, we’ll go over each of these areas of emphasis in further detail and share some of the key lessons we’ve learned along the way. It makes no difference whether you plan remotely or in a single location; we will make recommendations to assist you better in your efforts.
Lead with value: Great product management and even greater communication are the foundations of a successful business.
We can’t say enough good things about our outstanding product management group. We are continually impressed by the passion, dedication, and leadership displayed by the team. It wasn’t all rainbows and unicorns from the beginning; there was a lot of learning along the way, including prioritization strategies and tools to put the team up for long-term success.
Prioritization is important when using the Weighted Shortest Job First (WSJF) method.
SAFe provides excellent tools and processes, and we take advantage of as many of them as we can. With all in mind, it is evident that deploying SAFe is a time-consuming process that must be completed correctly the first time. After a couple of PIs, we decided to deploy WSJF to prioritize the Program Backlog, which proved to be a game-changer in terms of productivity. Simply said, “WSJF is a prioritization approach that is used to schedule jobs in order to provide the greatest amount of economic gain.”
Prior to WSJF, Product Managers (PDMs) and Product Owners (POs) struggled to articulate the true priorities of their respective products. Product managers lacked a systematic approach to gathering and prioritizing customer feedback. As a result of this conflict, there was a lack of clearly defined priorities, which made sorting the backlog prior to the PI Planning challenge. The task of re-prioritizing the features in the middle of the PI Planning process was made even more difficult by an unforeseen change in the situation.
The WSJF presents a mathematical and objective method of prioritizing that avoids the use of subjective dynamics based on influence, which is not appropriate in many situations. The use of WSJF scoring tools allows us to re-prioritize in real-time during the PI Planning process, allowing us to give the most value to the business as feasible. By taking this strategy, we have avoided certain last-minute modifications by ensuring that everyone is focused on the most crucial issues. If changes arise, we will be able to easily adapt to such changes as they occur.
Whenever a new feature is required to be introduced in the middle of a quarter, it is quite simple to determine which of the existing features should be taken out to make room for the new, higher-rated function. This can also be a dangerous path to take because the PDM must still devote the necessary time to fleshing out the feature before introducing it into the quarter. It is up to the PDM and PO to assess whether the additional function is worth the inconvenience.
The WSJF is also useful in determining minor enhancements that can be made. In preparation for executing this change, we created a separate, short enhancement list that was shared with everyone on the train. It became extremely difficult to determine which article should be worked on in the absence of a WSJF score. We ensure that the best possible business value is supplied regardless of the size of the task by using a single list that contains all features, large and small.
Product kick-off meetings are held on a regular basis.
Providing relevant knowledge to others is a powerful activity, and it is made much more effective when that knowledge is provided to highly accountable and committed groups. In our early experiences with PI Planning, the PDMs and POs were the only ones who were fully aware of all the features, their importance, and the intents behind each one of them. The team attempted to write all the essential stories to finish each feature, and while they did a good job, they lacked some technical knowledge and details, necessitating team analysis and collaboration to complete the task. In the end, new stories and updates to existing ones were required, resulting in our features being far larger than what was initially stated to our business stakeholders. That rework resulted in a reduction in efficiency and predictability over the long term.
With product kick-offs, which are meetings led by the PDM (owner of the feature) and attended by the full Scrum Team, we were able to resolve this issue quickly. During this meeting, the feature is thoroughly defined, and the problem to be solved as well as the intended outcome are discussed. These discussions also help to provide answers to inquiries from the team, identify any dependencies ahead of time, and provide the knowledge necessary for team members to divide the feature into individual stories. These discussions can take place during the final few sprints of the current PI or during the innovation sprint, just prior to the PI Planning meeting, depending on the circumstances.
The team has been able to take more responsibility and collaborate more effectively with the PO because of this practice in general. It also enabled the Scrum Master to develop a more effective strategy because everyone was aware of and supportive of the objectives.
Prior to Remote PI planning, make a list of all conceivable storylines.
To finish the task in two days, we began PI Planning with break-out sessions where we wrote stories, created acceptance criteria for each narrative, and talked about complexity. We quickly understood that we were in a predicament, and we set out to find solutions. The fact that we were aware of all the features and related stories might allow us to use our usual Scrum Refinement session to grade all of the possible stories before moving on to PI Planning. We had the ability to do so, and we did, and it was fantastic!
Teams were able to explore for dependencies, decide work sequence, uncover new situations, and discuss the plan because they began the PI Planning with virtually all the stories pointed. Discussion and collaboration result in more effective planning, greater dedication, and greater trust. Complete these tasks before PI Planning is not done to shorten the planning process, but rather to increase the efficiency and productivity of the time the teams spend together throughout the planning process.
Determine whether or if there are any observable dependencies.
This exercise necessitates that all the teams be present at the launch meetings and that all of the tales be pointed out prior to the PI Planning session. Based on the order in which stories should be implemented and the collaboration required amongst teams to arrange and plan in a logical sequence, dependencies are identified and prioritized. This decision is made with the goal of avoiding roadblocks as much as feasible. Architectural teams are then able to discuss and negotiate priorities, as well as bring pre-identified dependencies and offer solutions to the PI Planning stage of the design process.
Create a list of objectives.
The teams oversee achieving the PI objectives. Starting from the ground up might be time-consuming and confusing in the beginning. This work is made easier by creating a simple draught of the objectives—especially when you have a variety of perspectives and teams that are dispersed. Team members should be aware of the primary objectives of the PI as well as the planned business value that they expect to produce following the feature launch meetings and after the teams have identified all the possible stories to pursue. As a result, team leaders can begin working with the development team to develop PI Objectives for the project. As a result of this high-level picture, more in-depth and more successful discussions of the objectives can take place during PI Planning, resulting in improved quality and results.
Improved logistics: You’ll feel like you’re all in this together even if you’re not physically there in the same place.
During our first Remote PI Planning session, team members from each geographic location—Denver, London, San Jose (Costa Rica), and Portland—met in a centralized location in their respective cities. Each location has its own set of issues, but none were more difficult to overcome than San Jose. The following recounts their circumstances as well as the lessons they learned because of it.
In a spacious conference room adjacent to their San Jose headquarters, the Costa Rican teams came together to collaborate. On paper, this appeared to be a fantastic idea…bring everyone together in a large room, give them the impression that they are all attending the event together, and imitate the large room planning gathering. Things, on the other hand, did not turn out quite as we had intended. While the lectures that were live streamed from Denver were good, the hotel’s Wi-Fi was not adequate to the task, and people were more interested in their laptops than in the speakers on the screen.
To avoid experiencing the same challenges in the future, the teams took the challenging environment to heart and came up with many suggestions to avoid experiencing the same problems in the previous quarter. For the following planning event, the San Jose group divided teams into actual office space, ensuring that each team had a dedicated area reserved for the duration of the PI Planning event. Each room was equipped with a huge TV, conferencing equipment, a mac mini (which was connected to the network through a wired connection rather than wireless), estimation cards, whiteboards, post-its, and markers.
During remote PI Planning round two, everything in the rooms functioned wonderfully on day one, even though it was a remote location. However, as we started the Zoom session on day two, we had some audio-visual difficulties. Even though we scrambled and resolved the problem in a matter of minutes, we learned a valuable lesson: check that everything continues to function daily and do so early enough to make any necessary adjustments.
Based on the lessons gained from PI Planning number two, we test the audio-visual equipment a few days before the PI Planning to ensure that the sound is clear, and the video is operating without interruption. Similarly, we perform the same checks each morning at the beginning of the day’s planning meetings.
Preparation: Plan, a second plan, and a third plan.
The concept of arriving unprepared to Remote PI Planning—and even worse if the meeting is held remotely—is never a good one but conducting PI Planning with practically all the plan already completed undermines the purpose and value of this important ritual. So, how much forethought should you put in?
“It depends,” is the response to that question. Every project is unique, and the complexity and magnitude of each one is important factors to consider when determining the appropriate amount of pre-planning. We will not supply you with a specific recipe; instead, we will share our results and the specifics that have worked for us in this regard. Prior to PI Planning, it is necessary to define roles and responsibilities.
Each team is unique, there is no doubt about it, and the fact that our project is distributed adds an additional layer of complexity to the collaboration among teams. Our experience implementing PI Planning revealed that this could be a problem, as some teams brought draught objectives to the planning session, while others brought a few estimated stories or identified a couple of dependencies, but there was no clarity about the items required to kick off the planning session with confidence. Unless everyone is held accountable, no one is genuinely accountable, resulting in duplicated chores, missing materials, and a general sense of misunderstanding regarding the tasks that need to be completed.
Preparation for the Remote PI Planning process includes several duties.
Some of these tasks are the responsibility of the teams, while others are the responsibility of the train and necessitate cross-team coordination. Task, role, and responsibility identification is beneficial since it offers visibility during the planning process. Moreover, it informs employees about what is expected of them, allowing them to collaborate effectively and complete the project on time. The goal is not to assign blame when anything goes wrong, but rather to standardize processes and track progress across the whole process life cycle. Here are a few things we try to get done before the first day of school:
- For new members of the train, we provide an overview of the SAFe framework, with a particular emphasis on PI Planning, so that they all understand what to expect and why we are doing what we are doing. In addition, we used Miro to set up our board (formerly known as Realtime Board).
- We replicated the identical layout that you would find in a physical area on this board. We sketched the sprints of the PI, the velocity of the team, and other crucial information on the whiteboard in the room. It is more efficient to plan with physical tools first, and then update Miro as you proceed through the process.
Presentations that are interactive, as well as shared facilitating
PI Planning is a time-consuming and intense event that takes two full days to complete, including the creation of the programme board, the creation of sprints, the writing of PI objectives, the identification of dependencies, and the creation of a general plan for the next PI.
We observed this after conducting multiple remote PI Planning sessions that it is difficult to keep individuals focused and involved in the process. For our PI Planning events, we follow the SAFe PI Planning agenda, which proved to be highly successful during our first few meetings. After several sessions, we were able to reduce the amount of time we spent talking business context, architecture vision, and development methods while increasing the amount of time we spent discussing product/solution vision and team breakouts.
Keeping individuals interested requires making certain that the information delivered to them is important to their job functions. Anyone will lose interest in a presentation if it is not relevant to their own situation or interests. Our planning events are agile in that we inspect and adjust the input as well as the outcome, and we continually refine both the input and the output.
The facilitation dynamic was another place where we made improvements. Remote planning will not be able to deliver all the benefits of a face-to-face meeting. We distributed the ceremonies’ facilitation among the Release Train Engineers and Scrum Masters to alleviate some of the disengagement that comes with being remote. Each of the following tasks is now handled by a different person: a retrospective, programme risks, ROAM activity, and a confidence vote. Each team can be the focus of attention, which encourages them to feel more involved and accountable for the entire ceremony and reception.
Make sure the appropriate people are in the right place at the right time: Make sure you are making the most of your travel dollars. A great deal of significant conversation occurs once the breakout sessions get underway. The teams begin to identify dependencies that must be resolved with the help of other teams, identify risks, sort through difficult details, and they periodically reprioritize features because of unforeseen developments. It has proven to be quite beneficial for the Product Manager to participate in the breakout sessions where their features are addressed.
We have found that sending Product Managers to attend breakout sessions in person in locations where the team (or most of the team) is situated is a cost-effective method to spend our travel funds. Why? Multiple benefits result from having a business representative on the planning team, including increasing the morale of the team by having a business representative present; providing transparency to the Product Manager on what is being discussed, defined, and agreed upon by the team during planning; reducing the need for replanning and the consequences of those changes; and providing an easy way for the team to clear up any confusion they may have during the process.
It is more like a quality, open conversation between a group of friends who are working together on a set of goals at this point in our journey, rather than a formatted session in which the business (who is separate from the team) has requested a set of features to be delivered and the team is required to comply with those without question.
Instruments of the trade
As our knowledge and comprehension of Remote PI Planning grow, so does our knowledge and understanding of the virtual and physical instruments that we use to accomplish our goals. The following is a list of products that we have continued to use or that we have changed our usage of over the last 12 months.
Virtual bulletin boards
We used a programme called Realtime Board for our first remote PI Planning session, and it was a great success. As part of our retrospective process, we created virtual Scrum boards for each team, a full programme board to map dependencies, a ROAM board for risks, as well as shared pages to log our meetings. Realtime Board introduced templates for PI Planning just a few weeks before our second remote PI Planning session, which we are presently using and tweaking as needed.
Physical boards are used for planning on our Scrum teams, and virtual boards are used once a plan has been established, something that big room planning helps us to do. Teams discovered that including this additional phase is critical when picturing the work that needs to be completed over the duration of three months. As soon as the plan is in place, the Scrum Masters and Product Owners for each team transfer the stories into Jira and onto the Miro board, where they can be shared with the other remote teams.
Zoom
We’ve continued to rely on Zoom for all our teleconference requirements. However, we have found that Zoom Breakouts are not a good tool for us and so utilize a single conference ID for all the main sessions. Product Managers, architects, and other dependent team members are invited to join team breakout sessions on an as-needed basis. Instead, each team has its own Zoom ID for the team breakout sessions, and each team uses that ID to connect with other teams.
Following the planning process, tracking is done.
After the planning process is complete, teams must keep track of risks and dependencies on a regular basis. The train moves some assets into Jira, which allows for ongoing tracking and updates, as opposed to the Miro PI Planning board, which is a snapshot in time. The Scrum of Scrums evaluates the PI dependencies on a weekly basis, using a Jira board with tasks assigned to external dependant teams to keep track of them. The Scrum of Scrums meets every few weeks to discuss risks and mitigation strategies. Team members assigned to tasks (or in charge of tracking tasks) make appropriate updates to the task boards as needed. Kanban board with special features
At the weekly PO/PDM sync meeting, the Product Owners and Product Managers come together to assess the status of each feature on a Jira Kanban board, which is maintained by the Product Development Manager. The POs keep track of project statuses and express concerns on a regular basis, allowing the Product Managers to engage effectively with stakeholders.
Bring everything to a close
As this blog demonstrates, we are on a path in which we are constantly adjusting and refining our approach. We hope this has given you the confidence to try Remote PI Planning. While it may appear difficult at first, with sufficient planning and a willingness to inspect and adjust, you, too, can run a successful PI Planning no matter where you are.
