By Kodi Terry, Imagine Communications
Sr. Director, Global Technical PMO
Certified SAFe® 4 Agilist, Certified SAFe® 4 Practitioner, Certified SAFe® 4 Scrum Master, Certified SAFe® 4 Product Owner/Product Manager
As a full-time employee of Imagine Communications for a little over two years now, my experience in the company’s SAFe® journey has been full of surprises ― the latest of them, of course, COVID-19. As we just successfully executed our first fully remote PI Planning session, I hope that sharing our experience can help you flatten your learning curve, reduce your anxiety, and give you a head start on making your own SAFe journey a success.
Editor’s Note: Imagine Communications is a valued TecVeris client.
We began our Global SAFe transformation at Imagine about a year and a half ago, at which time I was moved from my position in engineering management to my current role as Sr. Director of the Global Technical PMO, and perhaps more importantly (depending who you ask) Release Train Engineer (RTE).
In 2018, we engaged with TecVeris, a member of the Scaled Agile Partner Network, and underwent an assessment of predictability, delivery, and overall employee satisfaction. Before our full assessment was even complete, our CEO Tom Cotney was convinced SAFe was the way to go and was all-in. With vision and constant leadership from our SVP of Engineering, Dave Hogan, and VP of Product Ronnie Bell, and full investment from our C-suite and Board of Directors, our transformation began. First in the U.S., then to the U.K., then back to the U.S. to wrap up — all employees for the first Agile Release Train (ART) were fully trained and offered company-paid SAFe certifications (I’ve gained four of them myself so far). So with certifications in hand, it was time for our team to hit the ground running with PI-1.
Now, before I go too far, let’s get it out of the way that “we are different.” I know, I know ― everyone, everywhere, in every business is “different.” And yet, when it comes to SAFe, it’s what makes us all the same (so really, we aren’t different at all, but stick with me here … I’ll give you a jaw dropper in just a bit). We utilize the SAFe framework as just that ― a framework ― one that guides us AND offers us the flexibility to inspect and adapt that framework to the specifics of our business. Luckily, none of us must agree on what is perfect; we are simply aiming for progress, predictability, and positivity.
On this ART currently, we are 1 company, 6 products, 17 teams, multiple locations, 2 planning sessions (U.K. and U.S.), 1 ART. Go ahead and judge, I already know ― we are breaking the rules. Or as I see it, we are simply adapting the framework. It actually works well (for us) this way, and we are always improving. So, we have one three-week IP iteration: Week 1 we do PI planning in the U.S., week 2 we do planning in the U.K. (or vice versa), and then we sync everything up with the normal ceremonies and some tools to give everyone as much visibility as possible.
After a couple of PI Planning sessions, we learned a few things:
So, I’ll fast-forward to our 5th PI. U.K. planning week is up first ― flights and hotels are booked (and sometimes that is harder than PI Planning, am I right?!), and BAM! Travel is shutdown to the U.K. The writing is on the wall (and in a few emails) that our second week planned in the U.S. is also about to be compromised. Our ACE group meets (we dropped the “L”; no one questions an ACE meeting, but they think twice about attending a Lace meeting ― we didn’t want any confusion), and concerns seem to be generally akin. We think it’s time to plan for this thing being all remote. We’ve trained our dev teams to pivot without mercy, and now it’s our turn.
Below is a detailed description of how we executed on the plan, including tips and tricks we learned along the way. It is my sincere message to you that you plan and plan and then plan a little more. Then test the plan you are planning. Communicate the plan far and wide, ask for and assess the feedback, and then plan some more. Recommunicate the plan, and then invoke the most patience you can muster and execute this PI Planning like you know exactly what you are doing ― even though you are just hoping you planned enough! No matter how much you plan, communicate, or test, something will go wrong ― and some process won’t be followed. Be ready to have locations to point people to, convey the message that you’ve “given them everything they need to get the answers themselves,” and then answer them anyway. Be ready for someone to not like what you’ve done and not appreciate the time you put into planning. Shoot, we even built in a couple things for people to complain about, just so I would know it was coming. So we even planned for complaints!
Ok, let’s get to it …
Step 1: Figure out the agenda
Get out the PI Planning deck and start formulating the agenda. Now keep in mind, we will have people in both the U.S. and U.K. potentially needing to join multiple sessions, so listing all timings in as many time zones as we can fit on the page becomes our first hurdle.
It quickly becomes obvious that we need to figure out our overlap times first, and our number ONE priority is to ensure that our teams have as much planning time as possible. With that in mind, we go to work.
Step 2: Use the agenda to figure out your tools
Based on your plan, what do you need to have ready? For example, I knew that I needed a way to capture, collaborate, and communicate. Use your agenda as a self Q&A to assess your tooling needs. (And check out the grid under “Resources” at the end for an at-a-glance layout for all use cases.)
(I&A Tip: We asked for estimated timings in advance, but we now know that questions push us a bit longer. Add 30 minutes and publicize that workstreams can only exceed their estimations by X minutes. Some people are very passionate about their products ― give them time, but not too much. And keep it the same for everyone. You don’t want to be accused of playing favorites!)
Facilitating problem solving is admittedly a bit tricky, and you really have to Gemba to be involved (more on Gemba further down).
I’m certain at this point that you are dying to see this board, so here is the finished product after all our planning. Don’t forget, we covered this earlier, mouths closed ― no jaw dropping allowed. So, check it out: we’ve adapted. Our board goes 90 degrees different than what you expect, and let me just add, this has worked brilliantly (as my U.K. friends would say). In person, we had walls that were way longer than they were high, so to make it fit…voilà. And then we made it digital.
And for what it’s worth, we went digital before digital was “cool” (we are a tech innovation company after all). In person, we like to have both versions. And while remotely your stock in adhesive paper products will decrease, the silver lining is the money you save in supplies.
Template to use for your dependency contact
My Team:
To:
My Epic#:
My Story#:
Need Complete By? 5.x
What is your dependency:
*Accepted JIRA Dependency URL:
Risks are a tough one to deal with remotely, but our tool of choice is Jira, and we happen to use the cloud version. We did have one realization…Jira is enough for this, no need to duplicate also over to Miro. We have a Risk issue type and board in Jira and directed people as follows.
In terms of what should qualify as a risk, please consider:
A Risk is an event or condition that, if it occurs, may impact the program objectives and is considered serious and time sensitive.
Before raising a risk, teams should work to resolve the risk within their team or workstream. If a risk cannot be mitigated within a team, it may need to be raised to the program level to promote awareness and to assist with risk mitigation.
For all risks in a status other than resolved, an update every iteration is required.
All Risks should be input into Jira ONLY.
Template for Jira Risk Description
From:
Suggested Owner:
Risk Summary:
Mitigation Plan:
So, we all know that at the end of Day 1, we have objective draft reviews, and then Day 2, time to lock in that commitment. Not only do you need to create objectives, but you also need to present them, revise them, and share them both inside and outside of presentations. So, here is our plan for objectives ….
Jira has a Program-level Jira issue type of “PI objective” with a very simple workflow of adopted or closed (which I hope is self-explanatory). We also then created Confluence pages for each product line/team and preset the page using Jira JQL searches for a table of Objectives that auto-populate. Also, on that page is a section for “major dependencies,” where teams can input their cross-platform dependencies. Below that we have a JQL that searches our Risk Board (see Realization of Risks) that lists the risks for that group, and then below that, a full list of Epics listed for that product for the PI at hand.
Why is all of that needed? Well, it’s really more about what it prevents than what it provides. By pulling up one Confluence location ordered however I want it to be, as the RTE, I can do all the presenting for every person/group with their own inputs. This way, you minimize the time problem of changing presenters, and most importantly, prevent the “can you see my screen” question from becoming a drinking game (even though we are close to the end of the day at this point, and “sorry, I was talking on mute” might have already started the drinking game).
Jira JQL Search Example:
issuetype = “PI Objective” AND project = __________ AND fixVersion = ________ ORDER BY Business Value ASC **Feel free to modify the query to search by only team and/or workstream.
All Objectives will be shown on their corresponding sheet under Objectives and displayed in team meetings by the RTE, but presented by the team representative.
**Objectives will populate in Confluence automatically; however, major dependencies should be entered manually.
How do you get out where the work is happening when you can’t get out anywhere? It’s ok, technology to the rescue. Set up a central location: Teams, Slack, Confluence, Google Sheet, SharePoint ― you pick your poison and create a place for centralized communication (and then put it in multiple places so that even the most technologically challenged will find what they need no matter where they go). I used Teams Wiki, pointing to a Confluence page (that pointed back to the Wiki), which both contained sections for all Miro boards, links for every team breakout Zoom (and of course the main Zoom meeting), dependency contact information, scrum master information, and note App Links (see below).
What this provides is a central location to give to your leadership team. Remember the power of Gemba ― encourage them to drop in and see how things are going without being asked. Being present is difficult in this situation, and the temptation to multitask is something you will have to fight. The entire team benefits from those Gemba walks, so really push to make it similar to how things would be in person as you drop by. Be cognizant of conversations in progress and don’t screw up momentum with casual pleasantries like “How’s it going in here?” Listen, and find a suitable time to let your presence be known ― even if it’s just saying “Keep up the good work” on your way out. Gemba doesn’t mean “interrupt” after all.
Alternatively, encourage teams to reach out, send a message or jump over to the Main Zoom anytime. If leadership isn’t with a team, we are on the Main Zoom available for anyone who might need something. There is no question about where to find anyone, and everyone is a quick message away.
Zoom
Oh, you know there is a love hate relationship with this one. Sometimes it’s praise, often its complaints. Sometimes you have control over it, and other times someone just had to nitpick something ― you know how it is. (And if you only ever get praise, I was going to say send me a message, but I’d never believe it anyway. And I’d suggest you need to push your boundaries a little more, ha!). The good, the bad, the annoying ― we still want to know.
I handled this simply by setting up a NoteApp board, a great virtual sticky board (literally) that I placed as a “website” in my PI Planning Teams Channel where anyone can go in and leave a sticky with their feedback. Put down your name, or don’t. Add a “+” if you want to up vote someone else’s sentiment (you know, a dot vote), or don’t. But either way, get your feedback, inspect it with care, and do what you can to improve for next time. There is always one little tweak that can be made, right?
This was an easy one for us: Set up a separate Zoom. If you don’t, inevitably you will have people lingering around, and no one wants to evict people from a Zoom. Just fire up a new one. Be prepared to share the risk board, use video to know who needs to talk, and be ready to invite others you may need to help with a problem. Cake walk ― if the problems aren’t too big.
We then come to the Finish Line of PI Planning (some would argue that is happy hour, but that is AFTER the vote, so that is the “Grand Prize”). This is a little tricky in the moment, but knowledge is power ― and so is planning.
Again, we use Zoom (I use one main Zoom meeting, and then have the teams set up their own breakout rooms), and I use the “Poll” feature of Zoom. Now this next part is important: Remember that patience thing. Pre-set your Poll with two questions ― one of them a fun question, and the second one your Confidence Vote. You’ll need that first question for all of those people that failed to listen or join those meetings where you communicated the plan, but still need to learn how to use the Poll.
Everything you need to know about Zoom Polling can be found here https://support.zoom.us/hc/en-us/articles/213756303-Polling-for-Meetings. I only used a meeting, NOT a webinar, and it worked great. Launch the Poll, watch for percentage of attendees to complete, End the Poll, Share the Poll results ― you got this!
*Pro Tip: Co-hosts cannot vote, so if you want a co-host to vote, be sure that you revoke privileges before you launch your poll. And if you screw up, or more likely need to vote again, just “Re-Launch Polling” ― easy peasy. If you need visuals ...
Now for those folks that have low confidence levels (no judgment ― remember we are all actually the same, and we all have a few low-confidence ones), we request that they raise their hands and explain their stance. We listen and ask questions and see if there is anything we can do to raise their vote, or if the majority is within the range of acceptance, well, you know what time it is…management review! (I know you thought I was going to say happy hour, but that is Day 2. Stay with me here!)
Step 3: Communicate your plans, ask for feedback, and finalize your plan.
Walking into PI Planning fully remote and expecting everyone to know what is about to happen and how is unrealistic. And as stewards of scrum leadership, we of course know better. I handled this by hosting two identical Town Hall meetings, offered at different times for folks to join live. And I shared the recording AFTER both meetings ended (remember your goal is active participation, not passive). is active participation, not passive).
The Town Hall meetings were 30 minutes each and walked through the plan at 25,000 feet ― just enough of an overview that people felt like they knew what was going on and where to find what they needed if they were just totally confused. I spent 20 mins or so spelling things out and left 10 minutes open for comments and questions. Invoke that patience ― you’ll breeze by something while someone is multitasking, and you’ll have to repeat. Remember that repetition equals muscle memory; it’s one less thing you’ll have to handle when you are in execution mode.
In conclusion, it takes a considerable amount of work to get things ready to rock, but I hope this commentary helps you get it all in line. I learned from first-hand experience that it’s a lot, and now you know that too. But if you execute with a well-devised plan, no one else needs to know.
Like any good RTE, I held out until the end to virtually but literally, raise a glass. Don’t forget about that virtual happy hour ― you deserve it. Have a laugh and enjoy the fruits of your labor…. just remember to stop the recording!
By Kodi Terry, Imagine Communications
Sr. Director, Global Technical PMO
Certified SAFe® 4 Agilist, Certified SAFe® 4 Practitioner, Certified SAFe® 4 Scrum Master, Certified SAFe® 4 Product Owner/Product Manager
As a full-time employee of Imagine Communications for a little over two years now, my experience in the company’s SAFe® journey has been full of surprises ― the latest of them, of course, COVID-19. As we just successfully executed our first fully remote PI Planning session, I hope that sharing our experience can help you flatten your learning curve, reduce your anxiety, and give you a head start on making your own SAFe journey a success.
Editor’s Note: Imagine Communications is a valued TecVeris client.
We began our Global SAFe transformation at Imagine about a year and a half ago, at which time I was moved from my position in engineering management to my current role as Sr. Director of the Global Technical PMO, and perhaps more importantly (depending who you ask) Release Train Engineer (RTE).
In 2018, we engaged with TecVeris, a member of the Scaled Agile Partner Network, and underwent an assessment of predictability, delivery, and overall employee satisfaction. Before our full assessment was even complete, our CEO Tom Cotney was convinced SAFe was the way to go and was all-in. With vision and constant leadership from our SVP of Engineering, Dave Hogan, and VP of Product Ronnie Bell, and full investment from our C-suite and Board of Directors, our transformation began. First in the U.S., then to the U.K., then back to the U.S. to wrap up — all employees for the first Agile Release Train (ART) were fully trained and offered company-paid SAFe certifications (I’ve gained four of them myself so far). So with certifications in hand, it was time for our team to hit the ground running with PI-1.
Now, before I go too far, let’s get it out of the way that “we are different.” I know, I know ― everyone, everywhere, in every business is “different.” And yet, when it comes to SAFe, it’s what makes us all the same (so really, we aren’t different at all, but stick with me here … I’ll give you a jaw dropper in just a bit). We utilize the SAFe framework as just that ― a framework ― one that guides us AND offers us the flexibility to inspect and adapt that framework to the specifics of our business. Luckily, none of us must agree on what is perfect; we are simply aiming for progress, predictability, and positivity.
On this ART currently, we are 1 company, 6 products, 17 teams, multiple locations, 2 planning sessions (U.K. and U.S.), 1 ART. Go ahead and judge, I already know ― we are breaking the rules. Or as I see it, we are simply adapting the framework. It actually works well (for us) this way, and we are always improving. So, we have one three-week IP iteration: Week 1 we do PI planning in the U.S., week 2 we do planning in the U.K. (or vice versa), and then we sync everything up with the normal ceremonies and some tools to give everyone as much visibility as possible.
After a couple of PI Planning sessions, we learned a few things:
So, I’ll fast-forward to our 5th PI. U.K. planning week is up first ― flights and hotels are booked (and sometimes that is harder than PI Planning, am I right?!), and BAM! Travel is shutdown to the U.K. The writing is on the wall (and in a few emails) that our second week planned in the U.S. is also about to be compromised. Our ACE group meets (we dropped the “L”; no one questions an ACE meeting, but they think twice about attending a Lace meeting ― we didn’t want any confusion), and concerns seem to be generally akin. We think it’s time to plan for this thing being all remote. We’ve trained our dev teams to pivot without mercy, and now it’s our turn.
Below is a detailed description of how we executed on the plan, including tips and tricks we learned along the way. It is my sincere message to you that you plan and plan and then plan a little more. Then test the plan you are planning. Communicate the plan far and wide, ask for and assess the feedback, and then plan some more. Recommunicate the plan, and then invoke the most patience you can muster and execute this PI Planning like you know exactly what you are doing ― even though you are just hoping you planned enough! No matter how much you plan, communicate, or test, something will go wrong ― and some process won’t be followed. Be ready to have locations to point people to, convey the message that you’ve “given them everything they need to get the answers themselves,” and then answer them anyway. Be ready for someone to not like what you’ve done and not appreciate the time you put into planning. Shoot, we even built in a couple things for people to complain about, just so I would know it was coming. So we even planned for complaints!
Ok, let’s get to it …
Step 1: Figure out the agenda
Get out the PI Planning deck and start formulating the agenda. Now keep in mind, we will have people in both the U.S. and U.K. potentially needing to join multiple sessions, so listing all timings in as many time zones as we can fit on the page becomes our first hurdle.
It quickly becomes obvious that we need to figure out our overlap times first, and our number ONE priority is to ensure that our teams have as much planning time as possible. With that in mind, we go to work.
Step 2: Use the agenda to figure out your tools
Based on your plan, what do you need to have ready? For example, I knew that I needed a way to capture, collaborate, and communicate. Use your agenda as a self Q&A to assess your tooling needs. (And check out the grid under “Resources” at the end for an at-a-glance layout for all use cases.)
(I&A Tip: We asked for estimated timings in advance, but we now know that questions push us a bit longer. Add 30 minutes and publicize that workstreams can only exceed their estimations by X minutes. Some people are very passionate about their products ― give them time, but not too much. And keep it the same for everyone. You don’t want to be accused of playing favorites!)
Facilitating problem solving is admittedly a bit tricky, and you really have to Gemba to be involved (more on Gemba further down).
I’m certain at this point that you are dying to see this board, so here is the finished product after all our planning. Don’t forget, we covered this earlier, mouths closed ― no jaw dropping allowed. So, check it out: we’ve adapted. Our board goes 90 degrees different than what you expect, and let me just add, this has worked brilliantly (as my U.K. friends would say). In person, we had walls that were way longer than they were high, so to make it fit…voilà. And then we made it digital.
And for what it’s worth, we went digital before digital was “cool” (we are a tech innovation company after all). In person, we like to have both versions. And while remotely your stock in adhesive paper products will decrease, the silver lining is the money you save in supplies.
Template to use for your dependency contact
My Team:
To:
My Epic#:
My Story#:
Need Complete By? 5.x
What is your dependency:
*Accepted JIRA Dependency URL:
Risks are a tough one to deal with remotely, but our tool of choice is Jira, and we happen to use the cloud version. We did have one realization…Jira is enough for this, no need to duplicate also over to Miro. We have a Risk issue type and board in Jira and directed people as follows.
In terms of what should qualify as a risk, please consider:
A Risk is an event or condition that, if it occurs, may impact the program objectives and is considered serious and time sensitive.
Before raising a risk, teams should work to resolve the risk within their team or workstream. If a risk cannot be mitigated within a team, it may need to be raised to the program level to promote awareness and to assist with risk mitigation.
For all risks in a status other than resolved, an update every iteration is required.
All Risks should be input into Jira ONLY.
Template for Jira Risk Description
From:
Suggested Owner:
Risk Summary:
Mitigation Plan:
So, we all know that at the end of Day 1, we have objective draft reviews, and then Day 2, time to lock in that commitment. Not only do you need to create objectives, but you also need to present them, revise them, and share them both inside and outside of presentations. So, here is our plan for objectives ….
Jira has a Program-level Jira issue type of “PI objective” with a very simple workflow of adopted or closed (which I hope is self-explanatory). We also then created Confluence pages for each product line/team and preset the page using Jira JQL searches for a table of Objectives that auto-populate. Also, on that page is a section for “major dependencies,” where teams can input their cross-platform dependencies. Below that we have a JQL that searches our Risk Board (see Realization of Risks) that lists the risks for that group, and then below that, a full list of Epics listed for that product for the PI at hand.
Why is all of that needed? Well, it’s really more about what it prevents than what it provides. By pulling up one Confluence location ordered however I want it to be, as the RTE, I can do all the presenting for every person/group with their own inputs. This way, you minimize the time problem of changing presenters, and most importantly, prevent the “can you see my screen” question from becoming a drinking game (even though we are close to the end of the day at this point, and “sorry, I was talking on mute” might have already started the drinking game).
Jira JQL Search Example:
issuetype = “PI Objective” AND project = __________ AND fixVersion = ________ ORDER BY Business Value ASC **Feel free to modify the query to search by only team and/or workstream.
All Objectives will be shown on their corresponding sheet under Objectives and displayed in team meetings by the RTE, but presented by the team representative.
**Objectives will populate in Confluence automatically; however, major dependencies should be entered manually.
How do you get out where the work is happening when you can’t get out anywhere? It’s ok, technology to the rescue. Set up a central location: Teams, Slack, Confluence, Google Sheet, SharePoint ― you pick your poison and create a place for centralized communication (and then put it in multiple places so that even the most technologically challenged will find what they need no matter where they go). I used Teams Wiki, pointing to a Confluence page (that pointed back to the Wiki), which both contained sections for all Miro boards, links for every team breakout Zoom (and of course the main Zoom meeting), dependency contact information, scrum master information, and note App Links (see below).
What this provides is a central location to give to your leadership team. Remember the power of Gemba ― encourage them to drop in and see how things are going without being asked. Being present is difficult in this situation, and the temptation to multitask is something you will have to fight. The entire team benefits from those Gemba walks, so really push to make it similar to how things would be in person as you drop by. Be cognizant of conversations in progress and don’t screw up momentum with casual pleasantries like “How’s it going in here?” Listen, and find a suitable time to let your presence be known ― even if it’s just saying “Keep up the good work” on your way out. Gemba doesn’t mean “interrupt” after all.
Alternatively, encourage teams to reach out, send a message or jump over to the Main Zoom anytime. If leadership isn’t with a team, we are on the Main Zoom available for anyone who might need something. There is no question about where to find anyone, and everyone is a quick message away.
Zoom
Oh, you know there is a love hate relationship with this one. Sometimes it’s praise, often its complaints. Sometimes you have control over it, and other times someone just had to nitpick something ― you know how it is. (And if you only ever get praise, I was going to say send me a message, but I’d never believe it anyway. And I’d suggest you need to push your boundaries a little more, ha!). The good, the bad, the annoying ― we still want to know.
I handled this simply by setting up a NoteApp board, a great virtual sticky board (literally) that I placed as a “website” in my PI Planning Teams Channel where anyone can go in and leave a sticky with their feedback. Put down your name, or don’t. Add a “+” if you want to up vote someone else’s sentiment (you know, a dot vote), or don’t. But either way, get your feedback, inspect it with care, and do what you can to improve for next time. There is always one little tweak that can be made, right?
This was an easy one for us: Set up a separate Zoom. If you don’t, inevitably you will have people lingering around, and no one wants to evict people from a Zoom. Just fire up a new one. Be prepared to share the risk board, use video to know who needs to talk, and be ready to invite others you may need to help with a problem. Cake walk ― if the problems aren’t too big.
We then come to the Finish Line of PI Planning (some would argue that is happy hour, but that is AFTER the vote, so that is the “Grand Prize”). This is a little tricky in the moment, but knowledge is power ― and so is planning.
Again, we use Zoom (I use one main Zoom meeting, and then have the teams set up their own breakout rooms), and I use the “Poll” feature of Zoom. Now this next part is important: Remember that patience thing. Pre-set your Poll with two questions ― one of them a fun question, and the second one your Confidence Vote. You’ll need that first question for all of those people that failed to listen or join those meetings where you communicated the plan, but still need to learn how to use the Poll.
Everything you need to know about Zoom Polling can be found here https://support.zoom.us/hc/en-us/articles/213756303-Polling-for-Meetings. I only used a meeting, NOT a webinar, and it worked great. Launch the Poll, watch for percentage of attendees to complete, End the Poll, Share the Poll results ― you got this!
*Pro Tip: Co-hosts cannot vote, so if you want a co-host to vote, be sure that you revoke privileges before you launch your poll. And if you screw up, or more likely need to vote again, just “Re-Launch Polling” ― easy peasy. If you need visuals ...
Now for those folks that have low confidence levels (no judgment ― remember we are all actually the same, and we all have a few low-confidence ones), we request that they raise their hands and explain their stance. We listen and ask questions and see if there is anything we can do to raise their vote, or if the majority is within the range of acceptance, well, you know what time it is…management review! (I know you thought I was going to say happy hour, but that is Day 2. Stay with me here!)
Step 3: Communicate your plans, ask for feedback, and finalize your plan.
Walking into PI Planning fully remote and expecting everyone to know what is about to happen and how is unrealistic. And as stewards of scrum leadership, we of course know better. I handled this by hosting two identical Town Hall meetings, offered at different times for folks to join live. And I shared the recording AFTER both meetings ended (remember your goal is active participation, not passive). is active participation, not passive).
The Town Hall meetings were 30 minutes each and walked through the plan at 25,000 feet ― just enough of an overview that people felt like they knew what was going on and where to find what they needed if they were just totally confused. I spent 20 mins or so spelling things out and left 10 minutes open for comments and questions. Invoke that patience ― you’ll breeze by something while someone is multitasking, and you’ll have to repeat. Remember that repetition equals muscle memory; it’s one less thing you’ll have to handle when you are in execution mode.
In conclusion, it takes a considerable amount of work to get things ready to rock, but I hope this commentary helps you get it all in line. I learned from first-hand experience that it’s a lot, and now you know that too. But if you execute with a well-devised plan, no one else needs to know.
Like any good RTE, I held out until the end to virtually but literally, raise a glass. Don’t forget about that virtual happy hour ― you deserve it. Have a laugh and enjoy the fruits of your labor…. just remember to stop the recording!
By Kodi Terry, Imagine Communications
Sr. Director, Global Technical PMO
Certified SAFe® 4 Agilist, Certified SAFe® 4 Practitioner, Certified SAFe® 4 Scrum Master, Certified SAFe® 4 Product Owner/Product Manager
As a full-time employee of Imagine Communications for a little over two years now, my experience in the company’s SAFe® journey has been full of surprises ― the latest of them, of course, COVID-19. As we just successfully executed our first fully remote PI Planning session, I hope that sharing our experience can help you flatten your learning curve, reduce your anxiety, and give you a head start on making your own SAFe journey a success.
Editor’s Note: Imagine Communications is a valued TecVeris client.
We began our Global SAFe transformation at Imagine about a year and a half ago, at which time I was moved from my position in engineering management to my current role as Sr. Director of the Global Technical PMO, and perhaps more importantly (depending who you ask) Release Train Engineer (RTE).
In 2018, we engaged with TecVeris, a member of the Scaled Agile Partner Network, and underwent an assessment of predictability, delivery, and overall employee satisfaction. Before our full assessment was even complete, our CEO Tom Cotney was convinced SAFe was the way to go and was all-in. With vision and constant leadership from our SVP of Engineering, Dave Hogan, and VP of Product Ronnie Bell, and full investment from our C-suite and Board of Directors, our transformation began. First in the U.S., then to the U.K., then back to the U.S. to wrap up — all employees for the first Agile Release Train (ART) were fully trained and offered company-paid SAFe certifications (I’ve gained four of them myself so far). So with certifications in hand, it was time for our team to hit the ground running with PI-1.
Now, before I go too far, let’s get it out of the way that “we are different.” I know, I know ― everyone, everywhere, in every business is “different.” And yet, when it comes to SAFe, it’s what makes us all the same (so really, we aren’t different at all, but stick with me here … I’ll give you a jaw dropper in just a bit). We utilize the SAFe framework as just that ― a framework ― one that guides us AND offers us the flexibility to inspect and adapt that framework to the specifics of our business. Luckily, none of us must agree on what is perfect; we are simply aiming for progress, predictability, and positivity.
On this ART currently, we are 1 company, 6 products, 17 teams, multiple locations, 2 planning sessions (U.K. and U.S.), 1 ART. Go ahead and judge, I already know ― we are breaking the rules. Or as I see it, we are simply adapting the framework. It actually works well (for us) this way, and we are always improving. So, we have one three-week IP iteration: Week 1 we do PI planning in the U.S., week 2 we do planning in the U.K. (or vice versa), and then we sync everything up with the normal ceremonies and some tools to give everyone as much visibility as possible.
After a couple of PI Planning sessions, we learned a few things:
So, I’ll fast-forward to our 5th PI. U.K. planning week is up first ― flights and hotels are booked (and sometimes that is harder than PI Planning, am I right?!), and BAM! Travel is shutdown to the U.K. The writing is on the wall (and in a few emails) that our second week planned in the U.S. is also about to be compromised. Our ACE group meets (we dropped the “L”; no one questions an ACE meeting, but they think twice about attending a Lace meeting ― we didn’t want any confusion), and concerns seem to be generally akin. We think it’s time to plan for this thing being all remote. We’ve trained our dev teams to pivot without mercy, and now it’s our turn.
Below is a detailed description of how we executed on the plan, including tips and tricks we learned along the way. It is my sincere message to you that you plan and plan and then plan a little more. Then test the plan you are planning. Communicate the plan far and wide, ask for and assess the feedback, and then plan some more. Recommunicate the plan, and then invoke the most patience you can muster and execute this PI Planning like you know exactly what you are doing ― even though you are just hoping you planned enough! No matter how much you plan, communicate, or test, something will go wrong ― and some process won’t be followed. Be ready to have locations to point people to, convey the message that you’ve “given them everything they need to get the answers themselves,” and then answer them anyway. Be ready for someone to not like what you’ve done and not appreciate the time you put into planning. Shoot, we even built in a couple things for people to complain about, just so I would know it was coming. So we even planned for complaints!
Ok, let’s get to it …
Step 1: Figure out the agenda
Get out the PI Planning deck and start formulating the agenda. Now keep in mind, we will have people in both the U.S. and U.K. potentially needing to join multiple sessions, so listing all timings in as many time zones as we can fit on the page becomes our first hurdle.
It quickly becomes obvious that we need to figure out our overlap times first, and our number ONE priority is to ensure that our teams have as much planning time as possible. With that in mind, we go to work.
Step 2: Use the agenda to figure out your tools
Based on your plan, what do you need to have ready? For example, I knew that I needed a way to capture, collaborate, and communicate. Use your agenda as a self Q&A to assess your tooling needs. (And check out the grid under “Resources” at the end for an at-a-glance layout for all use cases.)
(I&A Tip: We asked for estimated timings in advance, but we now know that questions push us a bit longer. Add 30 minutes and publicize that workstreams can only exceed their estimations by X minutes. Some people are very passionate about their products ― give them time, but not too much. And keep it the same for everyone. You don’t want to be accused of playing favorites!)
Facilitating problem solving is admittedly a bit tricky, and you really have to Gemba to be involved (more on Gemba further down).
I’m certain at this point that you are dying to see this board, so here is the finished product after all our planning. Don’t forget, we covered this earlier, mouths closed ― no jaw dropping allowed. So, check it out: we’ve adapted. Our board goes 90 degrees different than what you expect, and let me just add, this has worked brilliantly (as my U.K. friends would say). In person, we had walls that were way longer than they were high, so to make it fit…voilà. And then we made it digital.
And for what it’s worth, we went digital before digital was “cool” (we are a tech innovation company after all). In person, we like to have both versions. And while remotely your stock in adhesive paper products will decrease, the silver lining is the money you save in supplies.
Template to use for your dependency contact
My Team:
To:
My Epic#:
My Story#:
Need Complete By? 5.x
What is your dependency:
*Accepted JIRA Dependency URL:
Risks are a tough one to deal with remotely, but our tool of choice is Jira, and we happen to use the cloud version. We did have one realization…Jira is enough for this, no need to duplicate also over to Miro. We have a Risk issue type and board in Jira and directed people as follows.
In terms of what should qualify as a risk, please consider:
A Risk is an event or condition that, if it occurs, may impact the program objectives and is considered serious and time sensitive.
Before raising a risk, teams should work to resolve the risk within their team or workstream. If a risk cannot be mitigated within a team, it may need to be raised to the program level to promote awareness and to assist with risk mitigation.
For all risks in a status other than resolved, an update every iteration is required.
All Risks should be input into Jira ONLY.
Template for Jira Risk Description
From:
Suggested Owner:
Risk Summary:
Mitigation Plan:
So, we all know that at the end of Day 1, we have objective draft reviews, and then Day 2, time to lock in that commitment. Not only do you need to create objectives, but you also need to present them, revise them, and share them both inside and outside of presentations. So, here is our plan for objectives ….
Jira has a Program-level Jira issue type of “PI objective” with a very simple workflow of adopted or closed (which I hope is self-explanatory). We also then created Confluence pages for each product line/team and preset the page using Jira JQL searches for a table of Objectives that auto-populate. Also, on that page is a section for “major dependencies,” where teams can input their cross-platform dependencies. Below that we have a JQL that searches our Risk Board (see Realization of Risks) that lists the risks for that group, and then below that, a full list of Epics listed for that product for the PI at hand.
Why is all of that needed? Well, it’s really more about what it prevents than what it provides. By pulling up one Confluence location ordered however I want it to be, as the RTE, I can do all the presenting for every person/group with their own inputs. This way, you minimize the time problem of changing presenters, and most importantly, prevent the “can you see my screen” question from becoming a drinking game (even though we are close to the end of the day at this point, and “sorry, I was talking on mute” might have already started the drinking game).
Jira JQL Search Example:
issuetype = “PI Objective” AND project = __________ AND fixVersion = ________ ORDER BY Business Value ASC **Feel free to modify the query to search by only team and/or workstream.
All Objectives will be shown on their corresponding sheet under Objectives and displayed in team meetings by the RTE, but presented by the team representative.
**Objectives will populate in Confluence automatically; however, major dependencies should be entered manually.
How do you get out where the work is happening when you can’t get out anywhere? It’s ok, technology to the rescue. Set up a central location: Teams, Slack, Confluence, Google Sheet, SharePoint ― you pick your poison and create a place for centralized communication (and then put it in multiple places so that even the most technologically challenged will find what they need no matter where they go). I used Teams Wiki, pointing to a Confluence page (that pointed back to the Wiki), which both contained sections for all Miro boards, links for every team breakout Zoom (and of course the main Zoom meeting), dependency contact information, scrum master information, and note App Links (see below).
What this provides is a central location to give to your leadership team. Remember the power of Gemba ― encourage them to drop in and see how things are going without being asked. Being present is difficult in this situation, and the temptation to multitask is something you will have to fight. The entire team benefits from those Gemba walks, so really push to make it similar to how things would be in person as you drop by. Be cognizant of conversations in progress and don’t screw up momentum with casual pleasantries like “How’s it going in here?” Listen, and find a suitable time to let your presence be known ― even if it’s just saying “Keep up the good work” on your way out. Gemba doesn’t mean “interrupt” after all.
Alternatively, encourage teams to reach out, send a message or jump over to the Main Zoom anytime. If leadership isn’t with a team, we are on the Main Zoom available for anyone who might need something. There is no question about where to find anyone, and everyone is a quick message away.
Zoom
Oh, you know there is a love hate relationship with this one. Sometimes it’s praise, often its complaints. Sometimes you have control over it, and other times someone just had to nitpick something ― you know how it is. (And if you only ever get praise, I was going to say send me a message, but I’d never believe it anyway. And I’d suggest you need to push your boundaries a little more, ha!). The good, the bad, the annoying ― we still want to know.
I handled this simply by setting up a NoteApp board, a great virtual sticky board (literally) that I placed as a “website” in my PI Planning Teams Channel where anyone can go in and leave a sticky with their feedback. Put down your name, or don’t. Add a “+” if you want to up vote someone else’s sentiment (you know, a dot vote), or don’t. But either way, get your feedback, inspect it with care, and do what you can to improve for next time. There is always one little tweak that can be made, right?
This was an easy one for us: Set up a separate Zoom. If you don’t, inevitably you will have people lingering around, and no one wants to evict people from a Zoom. Just fire up a new one. Be prepared to share the risk board, use video to know who needs to talk, and be ready to invite others you may need to help with a problem. Cake walk ― if the problems aren’t too big.
We then come to the Finish Line of PI Planning (some would argue that is happy hour, but that is AFTER the vote, so that is the “Grand Prize”). This is a little tricky in the moment, but knowledge is power ― and so is planning.
Again, we use Zoom (I use one main Zoom meeting, and then have the teams set up their own breakout rooms), and I use the “Poll” feature of Zoom. Now this next part is important: Remember that patience thing. Pre-set your Poll with two questions ― one of them a fun question, and the second one your Confidence Vote. You’ll need that first question for all of those people that failed to listen or join those meetings where you communicated the plan, but still need to learn how to use the Poll.
Everything you need to know about Zoom Polling can be found here https://support.zoom.us/hc/en-us/articles/213756303-Polling-for-Meetings. I only used a meeting, NOT a webinar, and it worked great. Launch the Poll, watch for percentage of attendees to complete, End the Poll, Share the Poll results ― you got this!
*Pro Tip: Co-hosts cannot vote, so if you want a co-host to vote, be sure that you revoke privileges before you launch your poll. And if you screw up, or more likely need to vote again, just “Re-Launch Polling” ― easy peasy. If you need visuals ...
Now for those folks that have low confidence levels (no judgment ― remember we are all actually the same, and we all have a few low-confidence ones), we request that they raise their hands and explain their stance. We listen and ask questions and see if there is anything we can do to raise their vote, or if the majority is within the range of acceptance, well, you know what time it is…management review! (I know you thought I was going to say happy hour, but that is Day 2. Stay with me here!)
Step 3: Communicate your plans, ask for feedback, and finalize your plan.
Walking into PI Planning fully remote and expecting everyone to know what is about to happen and how is unrealistic. And as stewards of scrum leadership, we of course know better. I handled this by hosting two identical Town Hall meetings, offered at different times for folks to join live. And I shared the recording AFTER both meetings ended (remember your goal is active participation, not passive). is active participation, not passive).
The Town Hall meetings were 30 minutes each and walked through the plan at 25,000 feet ― just enough of an overview that people felt like they knew what was going on and where to find what they needed if they were just totally confused. I spent 20 mins or so spelling things out and left 10 minutes open for comments and questions. Invoke that patience ― you’ll breeze by something while someone is multitasking, and you’ll have to repeat. Remember that repetition equals muscle memory; it’s one less thing you’ll have to handle when you are in execution mode.
In conclusion, it takes a considerable amount of work to get things ready to rock, but I hope this commentary helps you get it all in line. I learned from first-hand experience that it’s a lot, and now you know that too. But if you execute with a well-devised plan, no one else needs to know.
Like any good RTE, I held out until the end to virtually but literally, raise a glass. Don’t forget about that virtual happy hour ― you deserve it. Have a laugh and enjoy the fruits of your labor…. just remember to stop the recording!
By Kodi Terry, Imagine Communications
Sr. Director, Global Technical PMO
Certified SAFe® 4 Agilist, Certified SAFe® 4 Practitioner, Certified SAFe® 4 Scrum Master, Certified SAFe® 4 Product Owner/Product Manager
As a full-time employee of Imagine Communications for a little over two years now, my experience in the company’s SAFe® journey has been full of surprises ― the latest of them, of course, COVID-19. As we just successfully executed our first fully remote PI Planning session, I hope that sharing our experience can help you flatten your learning curve, reduce your anxiety, and give you a head start on making your own SAFe journey a success.
Editor’s Note: Imagine Communications is a valued TecVeris client.
We began our Global SAFe transformation at Imagine about a year and a half ago, at which time I was moved from my position in engineering management to my current role as Sr. Director of the Global Technical PMO, and perhaps more importantly (depending who you ask) Release Train Engineer (RTE).
In 2018, we engaged with TecVeris, a member of the Scaled Agile Partner Network, and underwent an assessment of predictability, delivery, and overall employee satisfaction. Before our full assessment was even complete, our CEO Tom Cotney was convinced SAFe was the way to go and was all-in. With vision and constant leadership from our SVP of Engineering, Dave Hogan, and VP of Product Ronnie Bell, and full investment from our C-suite and Board of Directors, our transformation began. First in the U.S., then to the U.K., then back to the U.S. to wrap up — all employees for the first Agile Release Train (ART) were fully trained and offered company-paid SAFe certifications (I’ve gained four of them myself so far). So with certifications in hand, it was time for our team to hit the ground running with PI-1.
Now, before I go too far, let’s get it out of the way that “we are different.” I know, I know ― everyone, everywhere, in every business is “different.” And yet, when it comes to SAFe, it’s what makes us all the same (so really, we aren’t different at all, but stick with me here … I’ll give you a jaw dropper in just a bit). We utilize the SAFe framework as just that ― a framework ― one that guides us AND offers us the flexibility to inspect and adapt that framework to the specifics of our business. Luckily, none of us must agree on what is perfect; we are simply aiming for progress, predictability, and positivity.
On this ART currently, we are 1 company, 6 products, 17 teams, multiple locations, 2 planning sessions (U.K. and U.S.), 1 ART. Go ahead and judge, I already know ― we are breaking the rules. Or as I see it, we are simply adapting the framework. It actually works well (for us) this way, and we are always improving. So, we have one three-week IP iteration: Week 1 we do PI planning in the U.S., week 2 we do planning in the U.K. (or vice versa), and then we sync everything up with the normal ceremonies and some tools to give everyone as much visibility as possible.
After a couple of PI Planning sessions, we learned a few things:
So, I’ll fast-forward to our 5th PI. U.K. planning week is up first ― flights and hotels are booked (and sometimes that is harder than PI Planning, am I right?!), and BAM! Travel is shutdown to the U.K. The writing is on the wall (and in a few emails) that our second week planned in the U.S. is also about to be compromised. Our ACE group meets (we dropped the “L”; no one questions an ACE meeting, but they think twice about attending a Lace meeting ― we didn’t want any confusion), and concerns seem to be generally akin. We think it’s time to plan for this thing being all remote. We’ve trained our dev teams to pivot without mercy, and now it’s our turn.
Below is a detailed description of how we executed on the plan, including tips and tricks we learned along the way. It is my sincere message to you that you plan and plan and then plan a little more. Then test the plan you are planning. Communicate the plan far and wide, ask for and assess the feedback, and then plan some more. Recommunicate the plan, and then invoke the most patience you can muster and execute this PI Planning like you know exactly what you are doing ― even though you are just hoping you planned enough! No matter how much you plan, communicate, or test, something will go wrong ― and some process won’t be followed. Be ready to have locations to point people to, convey the message that you’ve “given them everything they need to get the answers themselves,” and then answer them anyway. Be ready for someone to not like what you’ve done and not appreciate the time you put into planning. Shoot, we even built in a couple things for people to complain about, just so I would know it was coming. So we even planned for complaints!
Ok, let’s get to it …
Step 1: Figure out the agenda
Get out the PI Planning deck and start formulating the agenda. Now keep in mind, we will have people in both the U.S. and U.K. potentially needing to join multiple sessions, so listing all timings in as many time zones as we can fit on the page becomes our first hurdle.
It quickly becomes obvious that we need to figure out our overlap times first, and our number ONE priority is to ensure that our teams have as much planning time as possible. With that in mind, we go to work.
Step 2: Use the agenda to figure out your tools
Based on your plan, what do you need to have ready? For example, I knew that I needed a way to capture, collaborate, and communicate. Use your agenda as a self Q&A to assess your tooling needs. (And check out the grid under “Resources” at the end for an at-a-glance layout for all use cases.)
(I&A Tip: We asked for estimated timings in advance, but we now know that questions push us a bit longer. Add 30 minutes and publicize that workstreams can only exceed their estimations by X minutes. Some people are very passionate about their products ― give them time, but not too much. And keep it the same for everyone. You don’t want to be accused of playing favorites!)
Facilitating problem solving is admittedly a bit tricky, and you really have to Gemba to be involved (more on Gemba further down).
I’m certain at this point that you are dying to see this board, so here is the finished product after all our planning. Don’t forget, we covered this earlier, mouths closed ― no jaw dropping allowed. So, check it out: we’ve adapted. Our board goes 90 degrees different than what you expect, and let me just add, this has worked brilliantly (as my U.K. friends would say). In person, we had walls that were way longer than they were high, so to make it fit…voilà. And then we made it digital.
And for what it’s worth, we went digital before digital was “cool” (we are a tech innovation company after all). In person, we like to have both versions. And while remotely your stock in adhesive paper products will decrease, the silver lining is the money you save in supplies.
Template to use for your dependency contact
My Team:
To:
My Epic#:
My Story#:
Need Complete By? 5.x
What is your dependency:
*Accepted JIRA Dependency URL:
Risks are a tough one to deal with remotely, but our tool of choice is Jira, and we happen to use the cloud version. We did have one realization…Jira is enough for this, no need to duplicate also over to Miro. We have a Risk issue type and board in Jira and directed people as follows.
In terms of what should qualify as a risk, please consider:
A Risk is an event or condition that, if it occurs, may impact the program objectives and is considered serious and time sensitive.
Before raising a risk, teams should work to resolve the risk within their team or workstream. If a risk cannot be mitigated within a team, it may need to be raised to the program level to promote awareness and to assist with risk mitigation.
For all risks in a status other than resolved, an update every iteration is required.
All Risks should be input into Jira ONLY.
Template for Jira Risk Description
From:
Suggested Owner:
Risk Summary:
Mitigation Plan:
So, we all know that at the end of Day 1, we have objective draft reviews, and then Day 2, time to lock in that commitment. Not only do you need to create objectives, but you also need to present them, revise them, and share them both inside and outside of presentations. So, here is our plan for objectives ….
Jira has a Program-level Jira issue type of “PI objective” with a very simple workflow of adopted or closed (which I hope is self-explanatory). We also then created Confluence pages for each product line/team and preset the page using Jira JQL searches for a table of Objectives that auto-populate. Also, on that page is a section for “major dependencies,” where teams can input their cross-platform dependencies. Below that we have a JQL that searches our Risk Board (see Realization of Risks) that lists the risks for that group, and then below that, a full list of Epics listed for that product for the PI at hand.
Why is all of that needed? Well, it’s really more about what it prevents than what it provides. By pulling up one Confluence location ordered however I want it to be, as the RTE, I can do all the presenting for every person/group with their own inputs. This way, you minimize the time problem of changing presenters, and most importantly, prevent the “can you see my screen” question from becoming a drinking game (even though we are close to the end of the day at this point, and “sorry, I was talking on mute” might have already started the drinking game).
Jira JQL Search Example:
issuetype = “PI Objective” AND project = __________ AND fixVersion = ________ ORDER BY Business Value ASC **Feel free to modify the query to search by only team and/or workstream.
All Objectives will be shown on their corresponding sheet under Objectives and displayed in team meetings by the RTE, but presented by the team representative.
**Objectives will populate in Confluence automatically; however, major dependencies should be entered manually.
How do you get out where the work is happening when you can’t get out anywhere? It’s ok, technology to the rescue. Set up a central location: Teams, Slack, Confluence, Google Sheet, SharePoint ― you pick your poison and create a place for centralized communication (and then put it in multiple places so that even the most technologically challenged will find what they need no matter where they go). I used Teams Wiki, pointing to a Confluence page (that pointed back to the Wiki), which both contained sections for all Miro boards, links for every team breakout Zoom (and of course the main Zoom meeting), dependency contact information, scrum master information, and note App Links (see below).
What this provides is a central location to give to your leadership team. Remember the power of Gemba ― encourage them to drop in and see how things are going without being asked. Being present is difficult in this situation, and the temptation to multitask is something you will have to fight. The entire team benefits from those Gemba walks, so really push to make it similar to how things would be in person as you drop by. Be cognizant of conversations in progress and don’t screw up momentum with casual pleasantries like “How’s it going in here?” Listen, and find a suitable time to let your presence be known ― even if it’s just saying “Keep up the good work” on your way out. Gemba doesn’t mean “interrupt” after all.
Alternatively, encourage teams to reach out, send a message or jump over to the Main Zoom anytime. If leadership isn’t with a team, we are on the Main Zoom available for anyone who might need something. There is no question about where to find anyone, and everyone is a quick message away.
Zoom
Oh, you know there is a love hate relationship with this one. Sometimes it’s praise, often its complaints. Sometimes you have control over it, and other times someone just had to nitpick something ― you know how it is. (And if you only ever get praise, I was going to say send me a message, but I’d never believe it anyway. And I’d suggest you need to push your boundaries a little more, ha!). The good, the bad, the annoying ― we still want to know.
I handled this simply by setting up a NoteApp board, a great virtual sticky board (literally) that I placed as a “website” in my PI Planning Teams Channel where anyone can go in and leave a sticky with their feedback. Put down your name, or don’t. Add a “+” if you want to up vote someone else’s sentiment (you know, a dot vote), or don’t. But either way, get your feedback, inspect it with care, and do what you can to improve for next time. There is always one little tweak that can be made, right?
This was an easy one for us: Set up a separate Zoom. If you don’t, inevitably you will have people lingering around, and no one wants to evict people from a Zoom. Just fire up a new one. Be prepared to share the risk board, use video to know who needs to talk, and be ready to invite others you may need to help with a problem. Cake walk ― if the problems aren’t too big.
We then come to the Finish Line of PI Planning (some would argue that is happy hour, but that is AFTER the vote, so that is the “Grand Prize”). This is a little tricky in the moment, but knowledge is power ― and so is planning.
Again, we use Zoom (I use one main Zoom meeting, and then have the teams set up their own breakout rooms), and I use the “Poll” feature of Zoom. Now this next part is important: Remember that patience thing. Pre-set your Poll with two questions ― one of them a fun question, and the second one your Confidence Vote. You’ll need that first question for all of those people that failed to listen or join those meetings where you communicated the plan, but still need to learn how to use the Poll.
Everything you need to know about Zoom Polling can be found here https://support.zoom.us/hc/en-us/articles/213756303-Polling-for-Meetings. I only used a meeting, NOT a webinar, and it worked great. Launch the Poll, watch for percentage of attendees to complete, End the Poll, Share the Poll results ― you got this!
*Pro Tip: Co-hosts cannot vote, so if you want a co-host to vote, be sure that you revoke privileges before you launch your poll. And if you screw up, or more likely need to vote again, just “Re-Launch Polling” ― easy peasy. If you need visuals ...
Now for those folks that have low confidence levels (no judgment ― remember we are all actually the same, and we all have a few low-confidence ones), we request that they raise their hands and explain their stance. We listen and ask questions and see if there is anything we can do to raise their vote, or if the majority is within the range of acceptance, well, you know what time it is…management review! (I know you thought I was going to say happy hour, but that is Day 2. Stay with me here!)
Step 3: Communicate your plans, ask for feedback, and finalize your plan.
Walking into PI Planning fully remote and expecting everyone to know what is about to happen and how is unrealistic. And as stewards of scrum leadership, we of course know better. I handled this by hosting two identical Town Hall meetings, offered at different times for folks to join live. And I shared the recording AFTER both meetings ended (remember your goal is active participation, not passive). is active participation, not passive).
The Town Hall meetings were 30 minutes each and walked through the plan at 25,000 feet ― just enough of an overview that people felt like they knew what was going on and where to find what they needed if they were just totally confused. I spent 20 mins or so spelling things out and left 10 minutes open for comments and questions. Invoke that patience ― you’ll breeze by something while someone is multitasking, and you’ll have to repeat. Remember that repetition equals muscle memory; it’s one less thing you’ll have to handle when you are in execution mode.
In conclusion, it takes a considerable amount of work to get things ready to rock, but I hope this commentary helps you get it all in line. I learned from first-hand experience that it’s a lot, and now you know that too. But if you execute with a well-devised plan, no one else needs to know.
Like any good RTE, I held out until the end to virtually but literally, raise a glass. Don’t forget about that virtual happy hour ― you deserve it. Have a laugh and enjoy the fruits of your labor…. just remember to stop the recording!
.png)
