Remote PI Planning, One Year Later: Lessons Learned & Improvements Made
This is post 2 of 2 in the series “Remote PI Planning”
- Remote PI Planning: Tips, Tricks, and Tools
- Remote PI Planning, One Year Later: Lessons Learned & Improvements Made
Just about a year ago, my colleagues and I wrote a blog post about our experiences using the Scaled Agile Framework (SAFe) and Remote Program Increment (PI) Planning for a new Gorilla Logic customer. The project consisted of eight teams developing a single e-commerce platform in three time zones with a limited travel budget. In the months prior, we worked with another contracting firm to determine the best way to organize our teams. We chose SAFe, confident that we could indeed implement the framework in our client’s relatively complex environment even without their budget allowing all 120 of us to be physically together for planning each quarter.
In our last blog post, we outlined the tools we used and the tips and tricks discovered during that first remote PI Planning session. In this post, we will share the improvements we’ve made to our setup, pre-planning, and planning which has allowed us to prove just how successful remote PI Planning can be.
One very important note: Always, always, always try to plan together in a big room because it is worth the effort. But if you cannot (and even if you can) please read on!
One year later…How are we doing?
We are officially in the middle of our fifth consecutive quarter using the Scaled Agile Framework and more pointedly, remote PI Planning. We completed PI number five at the end of June and have consistently improved our predictability by focusing on six main areas:
• Lead with value: it all starts with great product management and even better communication
• Improved logistics: feel like you are in this together even when you are physically apart.
• Pre-planning: plan, plan, and re-plan.
• Getting the right people in the right place: make sure you spend your travel dollars wisely.
• Keep people engaged: share the load.
• Tools: plan with physical boards, track and communicate with virtual boards, and co-locate where you can.
In the sections that follow, we will outline each of these areas of focus and provide valuable lessons learned. We will recommend strategies to help improve your efforts whether you plan remotely or together in a single location.
Lead with value: It all starts with great product management and even better communication
We cannot say enough about our amazing product management team. The passion, dedication, and leadership never ceases to impress us. That said, it didn’t start out all rainbows and unicorns—there was a lot of learning along the way including prioritization tactics and tools to set the team up for success.
Weighted Shortest Job First (WSJF): Prioritization does matter!
SAFe provides great tools and practices, and we use as many as possible. With that in mind, it is clear that implementing SAFe is a lengthy process that requires time to get right. After a couple of PIs we decided to implement WSJF to prioritize the Program Backlog, and it was definitely a game-changer. Simply stated, “WSJF is a prioritization model used to sequence jobs to produce maximum economic benefit.”
Before WSJF, the Product Managers (PDMs) and the Product Owners (POs) struggled to define the real priorities. The product team simply lacked a good intake and prioritization process. This struggle resulted in a lack of clear priorities which made organizing the backlog before the PI Planning difficult. Even more difficult was re-prioritizing the features in the middle of the PI Planning when an unexpected change occurred.
WSJF provides a mathematical and objective way of prioritizing, without running into influence-based subjective dynamics—which are not ideal. Scoring features using WSJF allows us to re-prioritize in real-time during the PI Planning and deliver the maximum value possible to the business. With this approach, we have removed some of the last-minute changes by ensuring everyone is engaged on what is most important. If changes occur, we can easily adapt to those changes.
When a feature does need to be brought in mid-quarter, it’s easy to determine which of the remaining features should be moved out, based on WSJF, to accommodate for the new higher-rated feature. This can also be a slippery slope, as the PDM still needs to spend the proper amount of time fleshing out the feature before bringing it into the quarter. It is up to the PDM and PO to determine if the new feature is worth the disruption.
WSJF is also helpful in determining small enhancements. Prior to implementing this change, we had a separate small enhancement list that was shared across the entire train. It became very confusing which story should be worked on without the WSJF score in place. With one single list to contain all features large and small, we ensure the highest business value is delivered regardless of the job size.
Product kick-off meetings
Sharing relevant knowledge is a powerful practice, even more so if that knowledge is shared with highly accountable and committed teams. In our early experiences running PI Planning, the PDMs and the POs were the ones who knew all of the details about the features, their value, and the intentions behind them. With that, they tried to create all the required stories to complete each feature and while they did it well, they lacked some technical knowledge and details, which required team analysis and collaboration. In the end, new stories and modifications to the current ones were needed, causing our features to be larger than originally communicated to our business stakeholders. That rework also produced a decrease in efficiency and predictability in the long run.
We solved this issue with product kickoffs, which are meetings run by the PDM (owner of the feature) with the entire Scrum Team present. In this meeting, the feature is explained in detail and the problem to solve and desired outcome are discussed. These conversations also serve to answer questions from the team, identify any dependencies ahead of time, and provide the information required for team members to split the feature into stories. These meetings can happen during the final few sprints of the current PI or during the innovation sprint, before the PI Planning itself.
Overall, this practice has allowed the team to take ownership and collaborate more effectively with the PO. It also allowed the Scrum Master to create a better plan because everyone understood and bought into the goals.
Point all possible stories before planning
Starting PI Planning with break-out sessions writing stories, creating acceptance criteria for each story, and discussing complexity was too much work to complete in two days. We soon realized this predicament, so we looked for solutions. Could the fact that we knew the features and related stories allow us to use the regular Scrum Refinement session to rate all the possible stories before the PI Planning? Well, we could and we did, and it was awesome!
Starting the PI Planning with almost all of the stories pointed allowed teams to look for dependencies, determine work sequence, discover new scenarios, and discuss the plan. Discussion and collaboration lead to better plans, commitment, and trust. Completing these efforts prior to PI Planning is not done to shorten the planning process but instead, to make the time the teams spend together more efficient and productive.
Identify visible dependencies
This exercise requires having all of the teams present at kickoff meetings and stories pointed prior to the PI Planning. Dependencies are determined based on the order in which stories should be executed and the coordination required between teams to arrange and plan in a logical sequence. This determination avoids blockers as much as possible. Architects and teams are then able to discuss and negotiate priorities and bring pre-identified dependencies and proposed solutions to the PI Planning.
Draft the objectives
PI objectives are the teams’ responsibility. Starting from scratch can be slow and confusing at the beginning. A simple draft of the objectives makes this task easier—especially when you have different opinions and distributed teams. After the feature kickoff meetings and once the teams have pointed all the possible stories, team members should understand the main objectives of the PI and the intended business value they plan to deliver. Team leads can subsequently begin drafting PI Objectives in collaboration with the dev team. This high-level picture enables deeper and more effective discussions of the objectives during PI Planning, thus improving the quality and the final outcome.
Improved Logistics: Feel like you are in this together even when you are physically apart
During our first remote PI Planning, team members residing in each geographic area—Denver, London, San Jose (Costa Rica), and Portland—collocated in their respective centralized space. Each space had its problems, but none more challenging than San Jose. The following describes their situation and the learning that came from it.
The Costa Rican teams collocated in a large conference room adjacent to their San Jose office. On paper, this seemed like a great idea…bring everybody together in a big room, get them feeling like they are in the event together, simulate the big room planning event. However, things didn’t turn out exactly as we had hoped. The presentations that were live streamed from Denver fell a little flat, the hotel’s WiFi was not up to the challenge, and people engaged with their laptops rather than the speakers on screen.
We didn’t want to experience the same problems again so the teams took the challenging environment to heart and came up with several ideas to avoid the prior quarter’s issues. For the next planning event, the San Jose group distributed teams inside Gorilla Logic’s actual office space so that each team had a room reserved for the duration of the PI Planning. Each room contained a large TV, conferencing gear, a mac mini (wired to the network—not wireless), estimation cards, whiteboards, post-its, and markers.
During remote PI Planning number two, everything worked perfectly in the rooms on day one. However, when we started the Zoom on day two we experienced some AV issues. We scrambled and fixed the issue after a few minutes but we learned our lesson—check that everything continues to work every day, and do this early enough to make necessary adjustments.
Based on lessons learned from PI planning number two, we test AV days before the PI Planning to ensure the sound is clear and the video is running smoothly. We also run the same checks each morning prior to the start of the day’s planning sessions.
While we do recommend co-locating where you can, because of the layout of our office space for the teams in the same geographical location, we decided to book rooms close to each other in order to enhance the sense of being together.
Pre-planning: Plan, plan, and re-plan
Coming unprepared to PI Planning is never a good idea—even worse if it’s a remote one—but running the PI Planning with virtually all the plan already complete destroys the purpose and the value of this key ceremony. So, how much pre-planning is enough?
The answer to that is “it depends.” Every project is different, and the complexity and size of each one is a key factor to determine the right amount of pre-planning. That’s why we are not going to provide you with an exact recipe, instead, we will share our findings and the details that have worked for us.
“In preparing for battle I have always found that plans are useless, but planning is indispensable.” – Dwight D. Eisenhower
Defining roles and responsibilities prior to PI Planning
Each team is different—that is clear—and the distributed nature of our project adds an extra level of complexity to collaboration among teams. Our experience executing PI Planning showed us that this may be a problem, as some teams brought draft objectives to the planning, others brought a few estimated stories or identified a couple of dependencies, but there was no clarity about the items required to start the planning. If everyone is responsible, then no one is truly responsible, which results in duplicate jobs, missing items, and overall confusion about the tasks that need to be done.
There are several tasks that should be completed prior to the PI Planning, some are teams’ responsibilities, others are train’s responsibilities and require cross-team collaboration. Identifying tasks, roles, and responsibilities is helpful and provides visibility during planning. It also lets people know what is expected of them so that they can collaborate and complete the job on time. The idea is not to place blame when something goes wrong, but to standardize processes and track progress throughout. Here are a few items we strive to complete prior to day one:
• For new members of the train, we give an introduction to the SAFe framework, focusing mostly on PI Planning, so they all know what to expect and why we are doing it.
• We also set up our board using Miro (formerly known as RealtimeBoard). In this board, we recreated the same setup as you would in a physical space.
• In the room’s whiteboard, we drew the sprints of the PI, velocity of the team, and other important information. It’s faster to plan using the physical tools and then update Miro as you make progress.
Engaging presentations and shared facilitation
PI Planning is a long and intense event—two full days to create the program board, draft sprints, write PI objectives, identify dependencies, and create the general plan for the next PI. Keeping people focused and engaged is challenging, as we discovered after running several remote PI Planning sessions. We use the SAFe PI Planning agenda, which worked very well during our first few PI Planning events. Once we had a couple sessions under our belts, we decreased the time spent discussing business context, architecture vision, and development practices and increased the time in product/solution vision and team breakouts. The key to keeping people engaged is to ensure the information shared with them is critical to their work. Anyone will lose interest in a presentation that is not relevant to them. We are Agile—we inspect and adapt and continue to refine both the input to and the output from our planning events.
Another area we improved upon was the facilitation dynamic. Remote planning cannot provide all the same benefits as meeting in person. To resolve some of disengagement of being remote, we spread the ceremonies’ facilitation among the Release Train Engineer and Scrum Masters. The retrospective, program risks, ROAM activity, and confidence vote are now run by different people. Each team has the opportunity to be the center of attention, making them feel more involved and accountable for the whole ceremony.
Getting the right people in the right place: Make sure you spend your travel dollars wisely
Once the breakout sessions start, many meaningful conversations happen. The teams start to identify dependencies to be sorted out with other teams, they identify risks, they sort through complex details, and occasionally reprioritize features due to unexpected changes. To that end, having the Product Manager attend the breakout sessions where their features are discussed has proven incredibly valuable.
Having the Product Managers attend breakout sessions in person where the team (or the majority of the team) is located has proven to be a beneficial way to spend our travel dollars. Why? It produces several effects—it boosts the teams’ morale to have a business representative working with them; it provides transparency to the Product Manager on what is being discussed, defined, and agreed upon by the team during planning; it reduces the need for replanning and the impacts those changes may cause; and it provides an easy way for the team to clear up any confusion they may have during the process.
At this point in or journey, PI Planning is more like a quality, open conversation between a group of friends who are working together on a set of goals, rather than a formatted session in which the business (separated from the team) has requested a set of features to be delivered and the team has to accommodate to those without question.
Tools of the trade
As our PI Planning expertise increases so too does our knowledge and understanding of the virtual and physical tools that work for us. What follows is a list several products we continue to use or have altered our use of during the last year.
Virtual boards
In our first remote PI Planning session we utilized a product called Realtime Board. We built out virtual Scrum boards for each team, a full program board to map dependencies, a ROAM board for Risks, as well as shared pages to document our retrospectives. Shortly before our second remote PI Planning event, Realtime Board introduced templates for PI Planning which we now use and make tweaks where needed.
*Realtime Board is now Miro and contains dozens of more templates for Agile teams.
Something our Scrum teams do that big room planning teaches is to use physical boards for planning and virtual boards once a plan is in place. Teams found that this added step is crucial when visualizing the work to be done over the course of three months. Once the plan is in place, the Scrum Masters and Product Owners for each team transfer the stories into Jira and onto the Miro board to share across the remote teams.
Zoom
We’ve continued to use Zoom for all our conferencing needs. We use a single conference ID for all the main sessions, but have determined that Zoom Breakouts are not a great tool for us. Instead, each team utilizes its own Zoom ID for the team breakout sessions and Product Managers, architects, and other dependent team members join those sessions on an as-needed basis.
Post planning tracking
Once planning is over, teams need to track risks and dependencies on a regular basis. Since the Miro PI Planning board is a snapshot in time, the train transfers some assets into Jira for continuous tracking and updates. Weekly, the Scrum of Scrums reviews the PI dependencies using a Jira board with tasks assigned to external dependent teams. Every few weeks the Scrum of Scrums reviews risks and mitigation plans. Team members assigned to tasks (or in charge of tracking tasks) update the boards accordingly.
Feature Kanban board
During the weekly PO / PDM sync meeting, the Product Owners and Product Managers meet as a group to review the status of each feature using a Jira Feature Kanban board. The POs keep the statuses up to date and discuss concerns on a regular basis so the Product Managers can communicate to stakeholders.
Wrap up
As this blog post shows, we are on a journey during which we adjust and refine continuously. We hope this encourages you to try remote PI Planning. While it might look daunting in the beginning, with enough preparation and willingness to inspect and adapt, you too can run a successful PI Planning no matter where you are.
Special thanks to the other contributors to this post: Juan Pablo Blanco, Andres Sibaja Galan, and Miguel Marchena Martinez
