Easy: Zoom share.

• Pro Tip: Set up a password. No one needs a bored quarantine hacker hijacking their meeting

Again, Zoom. But we made sure that a template went to everyone ahead of time, and expectations were set that each new sharer knew their turn.

• Be sure to change the “Share” setting to “anyone can share when someone else is sharing.” You don’t want the constant back and forth of “can you stop sharing so I can share?” We are on a schedule!

For all demos, whether completely live or prerecorded, we asked for everyone to practice on Zoom ahead of time to ensure all the bits were working.

Set the system demo aside. Do it on a day all on its own if you are worried about time. (See the I&A Tip below)

• This ended up being a great idea, as we had a couple product lines that went longer than anticipated, and we ran over our timebox a bit (See “Problem Solving” for more). We gave our POPM crew a template PowerPoint to fill in with their objectives, business values (BV), actual values (AV), and AV explanations. The idea was to minimize Zoom sharing changes and keep everyone flowing.

(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).

Remote Problem-Solving Prep:

• Get it all set up ahead of time
  • Confluence pages
  • Zoom (main meeting room and links for the breakout rooms)
  • Predetermine who will be in each breakout
  • …whatever else
•  Ask your scrum masters (or similar designees) to determine the topics in advance, with team input. This may be done with discussion or survey.
• Review with the ACE and scrum masters at least a few days ahead to ensure they understand the process and can ask questions in advance.

Remote Problem-Solving Tips & Agenda:

• Bring the full ART together in the main meeting room
• Set expectations
• Share pre-created Confluence pages with everyone. In our case, each page was complete with pre-filled participants, NoteApp links for brainstorming, and sections for Outcomes and Actions. A picture is worth a thousand words, right? (See below)
• Split up into smaller, problem-solving teams using Zoom breakout rooms
• After 60 minutes, come back together in the main Zoom to have the teams present their Kaizen (improvement prioritized for the next PI)

• In an attempt to make things look and feel like they do in person, we purchased a Team-level Miro license for each scrum master.
• We are on a budget (after all, #Covid-19), so there are some limitations to this. Everyone on our ART can comment on any created board, but only scrum masters have edit rights. I created a template for use, but encouraged everyone to make it their own.
• Because we purchased the Team level miro license, we hooked it up to our Jira instance.
  • Seriously the simplest thing ever. Set up the connector, and boom! You are copying, pasting, dragging, and dropping Jira Cards full of all the information you need right onto boards. So, also doing our part for the environment ― man, did we save some paper!
• Some people prefer Trello and we had a mix of use ― they both worked great.
• SHARE the Team Boards.
  • We use Microsoft Teams internally, so we have a whole Teams Channel dedicated to PI Planning. We set up a Wiki page with links to EVERYTHING. Links to Confluence, links to all Miro Boards, links to Zoom breakouts ― link, link, link.
• We also use a great little tool called “NoteApp” to create public boards that everyone can use to post stickies if need be (more on that later).

• We again went with Miro. Their template is perfect enough to get anyone started.

• I told you our ART is huge, and so is our board. But it works and has all the information you could ever need.

• Again, everyone can comment. So instead of putting a sticky on the Big Board, you copy and paste a comment with the URL, and your administrator drops it on the board.

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.

I know you’ll be shocked, but again, we went with Miro on this. I thought it would be helpful to share with you my directions to the ART on the dependency workflow.

I pre-created the dependency board and had a template as well as an example card. I even have a visual for you!

1. Scrum Masters, CTRL +D ― duplicate the template card.
2. Double click to fill out the card (anyone can fill out the template).
3. Place the card in the “For Review” column of the dependency board.
4. Text the dependency contact for the TO: team to let them know it is there.
5. Dependency team then decides if a call is needed and reaches out accordingly.
6. Upon acceptance of a dependency, the accepting party must add the JIRA ID where the dependency is being tracked (story, task, etc.).

Anyone can copy and paste the template to the scrum master ― the SM just needs to paste it to the board.

Template to use for your dependency contact:

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.

Types of risks

• Strategic Risk
• Compliance Risk
• Operational Risk
• Financial Risk
• Reputational Risk

Risk Status

• Resolved – The teams agree that the risk is no longer a concern.
• Owned – Someone on the train takes ownership of the risk since it cannot be resolved during PI planning.
• Accepted – Some risks are just facts or potential problems that must be understood and accepted.
• Mitigated – Teams identify a plan to reduce the impact of the risk.

For all risks in a status other than resolved, an update every iteration is required.

All Risks should be input into Jira ONLY

1. Enter your Risk on the Risk Board in Jira

• Assignee remains blank
• Status remains OPEN

2. use the template below for the description
3. Inform your scrum master for RTE notice of the addition at SoS

Template for Jira Risk Description

SAFe Objective Reminder – https://www.scaledagileframework.com/pi-objectives/

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 summaries have 255-character limit
• Link objectives as “Objective of” to the Epic(s) they represent.
• Review to ensure they are SMART.
• Business Values = Set these on a scale from 1-10, you must have one 10.
  **Leave blank if the value is uncommitted.
• Actual Values = Please feel free to update when Actual Value is known/realized.
• Objectives are set to Adopted for the PI (Deleted if not) or Closed after Actual Value has been determined for the PI.
• Set Fix Version the same as you would an Epic
  

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.

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.

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…managment review! (I know you thought I was going to say happy hour, but that is Day 2. Stay with me here!)

1. Turn OFF enter/exit chimes ― They are annoying and distracting. No chime ever made anyone on time, nor made them stay. Trust me, you’ll thank me later. Turn them OFF.
2. Change the “Share” setting ― Ensure that you change the SHARE setting to “anyone can share when someone else is sharing.” There is nothing more annoying (other than chimes) than repeating over and over “let me stop sharing” or “can you stop sharing.” You have the power to make it stop. Use it wisely.
3. Mute on Entry ― Asking people to mute over and over can quickly turn into another drinking game, and we need people to pay attention. Again, with great power comes great responsibility. Use your hosting privileges wisely.
4. Enable “join before host” ― You never know what might happen. Losing your internet is one thing, but kicking everyone out of the meeting is another.
5. Have co-hosts ― Get others to help you keep people on mute, start and stop recording if you forget, or generally keep things going if need be. Also, remember to revoke their co-host privileges prior to voting or they won’t have the option.