Remote Agile (9): A Cheat Sheet for Remote Agile Event Planning
Remote Agile (9): A Cheat Sheet for Remote Agile Event Planning
The ninth article of the Remote Agile series provides a cheat sheet for Remote Agile Event Planning — from the tech prep session to the follow-up.
Join the DZone community and get the full member experience.Join For Free
Remote Agile Event Planning — a Cheat Sheet
Imagine, you are supposed to facilitate a remote user-story mapping with 26 people from all over our organization. Or, think about a remote meta-level Retrospective of a recent release of your organization’s cash cow that went sideways. You may ask yourself: How am I planning for this given that participants likely have different levels of experience, and everyone needs to be included fully in the discussion? My solution to this challenge is going the extra mile regarding the remote agile event planning. The concept I describe below is tested, proven, and modeled after my virtual Professional Scrum training classes.
The Remote Agile Event Planning Phases
In this post, I want to draw your attention to the three phases of your remote agile event planning: The pre- and post-event phase, and the event itself:
T-14 Days: The Pre-Event Planning Phase Kick-off
The pre-event planning phase for one of my Professional Scrum classes starts two weeks in advance of the training, with a comprehensive introduction email to all participants, and points to the essential steps they need to contribute to making the class a worthwhile experience. I believe in overcommunicating everything while being transparent regarding practices, tools, and deliverables.
In this email, I address the following topics:
- I provide an invitation to the upcoming (remote) technical prep session to ensure everyone has his or her device set-up properly.
- I also list the technical requirements that every attendee needs to address to ensure the best possible learning experience: What devices are suitable for participation, the necessity to use a microphone and probably headphones, have a back-up Internet connection, and choose a silent space.
- I remind students to update their browsers to the latest versions, install the Zoom app, and ensure access to Google Apps or the chosen equivalent like Office365. (We cannot deal with firewall, VPN- or general networking issues once the big event starts.)
- I describe the schedule of the upcoming event: starting and end times as well as planned breaks.
- I provide the link to the main Zoom session, in my case requiring a registration.
- Should I require additional information from the participants? I explain my need for this and include a link to a prepared survey.
- As we will use Liberating Structures frequently during the remote agile event, I point to an article series covering Liberating Structures for Scrum.
Attached to this email, I also provide several useful PDFs, for example, the Scrum Guide or the Scrum Guide Reordered, as well as a homework assignment for the upcoming technical prep session. Of course, I am available for all upcoming questions in advance of the tech prep session.
T-7 Days: The Technical Prep Session
Approximately a week before the main remote agile event, I run the technical prep session of about 60 minutes, typically in the late afternoon, so the participants are likely to attend. A few hours before the prep session, I mail a reminder to all invitees.
During the prep session, I keep track of who is attending. We start the session by running an Impromptu Networking among those who joined. This way, we can test whether Zoom and Google Apps are working and build initial rapport among the participants. After the introduction, we explore Mural, as we will use this online whiteboard during the remote agile event to visualize our work. (To do so, we accomplish a few small tasks such as adding your name and avatar to the “who is participating” section of the Mural, or we have a scavenger hunt on the board.)
I also introduce the Google Drive we will use for storing any form of work results. Moreover, we visit all the prepared documents for the main agile event so everyone can familiarize themselves with them. Introducing the documents at this point reduces the chance of surprises during the main event, reducing the level of uncertainty and lessening the cognitive load on the participants.
We also try to fix technical issues we run into or at least take note of what problems need to be fixed during the next week before the main event. However, the tech prep session is not supposed to be merely a support event.
Immediately after the tech prep session, I reach out to those invitees of the main remote agile event that missed it, and I offer an alternative appointment for a second tech prep session.
T-1 Day: The Reminder
A day before the remote agile event, I resend the invitation to all participants, including a listing of essential links for the workshop, for example, to the main Zoom session, the Google Drive including all the files we will be using during the main event, or the Murals we will complete. I also include the best ways of how to reach me by email, Slack, or phone.
Do not anticipate that the attendees pay the same level of attention to preparing themselves for the remote agile event as you do. Repeated communication of the essentials is hence useful and necessary.
T+1 Day: The Event Summary
A day after the remote agile event, I provide all the files created during the session(s) to the participants. These include the chat protocol files, sketches, or PDF exports of the Mural boards. I also download all Google App documents as individual files. In a corporate environment, I would point to the documentation where a summary of the event and its findings are available for further study.
T+7 Day: The Follow-up
Depending on the nature of the remote agile event, it may be useful to meet a week after its end to follow-up on the latest learnings and share experiences. (In the context of a Professional Scrum class, we meet to learn from those who already took the certification, thus helping their classmates prepare for their certification attempts.)
The Planning of the Main Event
Regarding the main remote agile event planning, I prepare myself by creating a script that details the aspects of the event itself: What happens when in which sequence for what purpose? What is the intended outcome of an exercise or discussion, how will we collaborate to get there, and where will we store the results? How long will each step approximately take, and when will we likely have a break?
I create those scripts in Excel. The following screenshot is from the first hour of the Distributed Agile Masterclass:
The script comprises all the information that the moderator requires during the different practices. For example, it contains the exact instructions for all exercises, including the URLs to necessary documents, for easy use in the chat room of the event. This way, the moderator can focus on interacting with the attendees.
The purpose of this script is not to create a comprehensive plan to follow to its letters. It is much more about getting an understanding as a moderator about the paths the remote agile event may take, depending on what will happen, and how to achieve the goal of the event nevertheless. As the saying goes: “Plans are worthless, but planning is everything.” Creating such a script is a considerable yet worthwhile investment. Starting from scratch with designing the workshop itself, it may take several working days to complete.
Over-communicate everything, be transparent, be available for everyone, and repeat the same messages multiple times on different occasions. This approach requires additional work regarding documentation, communication, and preparation. However, this extra work provides the basis for a moderator’s calmness, which in my experience affects the attendees’ experience so positively.
What kind of remote agile event planning are you practicing? Please share it with us in the comments.
Published at DZone with permission of Stefan Wolpers , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.