How to Run Agile Ceremonies Online in Public Services
In the past year, I have worked as an Agile Coach with several public service organisations, coaching new Scrum Masters, and teams that are new to agile methodologies. In these contexts, the role of the Scrum Master is particularly important, as teams are still new to self-organising and may not yet fully embrace an agile mindset. Well-run sprint ceremonies can create an environment where teams can embody the principles of the Agile Service Manifesto and experience the benefits of working in an agile way.
To help in my coaching conversations, I’ve written up my approach to different ceremonies, the preparation I do beforehand, and the mindset I adopt during them.
This post is a note to self. For those new to working as a Scrum Master, I hope it makes the learning curve a little less steep.
Sprint Planning
In organisations that are new to agile, Product Owners often need support from Scrum Masters to play their role really well. Before Sprint Planning, I book a regular time slot with the Product Owners to help them order the backlog and articulate a goal for the sprint. This ensures that they come to the meeting with a clear idea of where the team needs to focus its efforts for the upcoming two weeks. Once they are confident in their role, this session becomes redundant.
Before starting the session, I ask a quick check-in question to get everyone’s head in the meeting. At the beginning of a project, I usually ask questions that encourage people to share a little bit about themselves. This helps to build the psychological safety needed for teams to communicate honestly and transparently with one another throughout the project. For 365 days' worth of check-in questions, check out the Basis Twitter feed.
At the beginning of the session, I ask the team to indicate their availability for the upcoming sprint. This helps them to decide on an appropriate amount of work to commit to during the sprint. When doing this online, I ask people to put their leave commitments into the chat and copy and paste the text into the Sprint Goal card created in Trello or Teams Tasks. Ask people one by one at your peril!
I then ask the Product Owner to set out the Sprint Goal and encourage some discussion between them and the team to ensure that everyone understands the goal and why it is a priority. I give people the option to ask questions in the chat or verbally, making it easier for both introverts and extroverts to participate.
Next, we move on to building the Sprint Backlog. The team pulls in tasks from the Product Backlog or writes up the work needed to achieve the Sprint Goal. We do this as individuals and in silence, with everyone adding a card to Trello or Teams Tasks; both work equally well. During this activity, it’s essential to ask people to write in a way that would enable someone who is not present to understand what they mean. This avoids wasting time rewriting cards in the session and losing momentum.
Once the team has built the Sprint Backlog, I ask them to review it and consider whether it feels like an appropriate amount of work to commit to. If I sense some discomfort, I ask them to respond ‘yes, we’re good to go’ or ‘no, that’s too much’ in the chat, asking them to click send all at the same time. This helps to avoid groupthink. If anyone thinks we’ve taken on too much, I ask for suggestions about what we could eliminate while still achieving our Sprint Goal. Through open conversation, we usually figure it out.
Standups
As teams become more comfortable with standups, they can be extremely efficient. Unless someone is obviously having a hard day and needs a pick-me-up, I usually get straight into it once everyone has joined the call.
The nature of the projects I often work on is such that not everyone is full-time in the team. Some days they’ll have accomplished tons, and on others, nothing. Going around each person and asking them what they’ve done, what’s next, and whether or not they are blocked can create a weird vibe in this context. Instead, I ask people in advance of the standup to move the tasks they are working on into “doing” ahead of time.
I start by running down everything in the “doing” column and asking people for a quick update on where they are at. As part of this interaction, I ask them what the next step is going to be and whether or not they are blocked.
After going through this list, I ask the wider group if anyone needs to pull anything into “To Do” from the Sprint Backlog. This allows others who might not have said anything yet to share what they are working on next. I also ask if anyone is blocked on anything that hasn’t been discussed yet. If they are, I’ll pick it up with them outside of the standup as soon as possible, usually within a few hours.
Show and Tells
A show and tell is a key part of the Agile development process, where teams come together to showcase their work to stakeholders, get feedback, and celebrate progress. What’s important to remember is that this is a regular ceremony, usually happening every two weeks. Running a great show and tell takes some preparation, but it shouldn’t be a theatrical production that cannot be sustained over time.
At the beginning of the project, it’s useful to set up a template slide deck that you can reuse every fortnight. Since stakeholders will likely change over the course of the project, having some slides at the beginning of the deck that succinctly explain the purpose of the work, who is involved, and what a show and tell is in practice will save you some time.
If the show and tell happens on Thursday, following our standup on Monday or Tuesday, I’ll schedule a quick discussion on what we think is going to be most useful to share. At this point, I usually share a fresh slide deck, and over the next couple of days, we’ll self-organise to create the presentation. At most, each team member usually spends around 15–30 minutes on their part of the deck.
It’s also useful at the start of a project to ensure everyone understands the purpose of a show and tell; to demonstrate progress. If they’ve built something, they need to show how it works. If they’ve spoken with users, they need to share what they’ve learned from the experience. If they have some work in progress, they should ask for feedback on their next steps.
Showing, and not just telling, takes some practice for teams new to working in the open. Before the first couple of show and tells, I usually schedule a dry run the day before as an opportunity to provide some feedback to help the team improve their practice.
During the session, I typically hold space, welcoming people as they arrive, explaining the purpose of the work and why they are there, before handing over to the team. Questions throughout are fine, but I explain that if there are really detailed discussions to be had, we’ll take these outside the session.
For more tips on running great show and tells, Mark Dalgarno has written an excellent Medium post on the subject.
Retrospectives
At the beginning of every retrospective, I read the retrospective prime directive.
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
— Norm Kerth, Project Retrospectives: A Handbook for Team Review
Over time, this becomes a little bit repetitive, but it’s funny and gets people into the right mindset to focus on their collaboration.
There are many different retrospective formats (a quick Google search will provide you with numerous ideas for different scenarios). My current favourite for projects that are likely to last several months is the Sailboat Retrospective. Unless there is a compelling reason to change the format of the retro (such as a change in the direction of the project or interpersonal challenges on the team) I will use the same format every two weeks. This enables the team to focus on reflecting instead of on listening to an ever-changing set of instructions.
If you are interested in using the Sailboat Retro, I encourage you to ask a new person every fortnight to name the boat. The boat name acts as a kind of barometer for how the team is feeling as a whole (Boaty McBoatface = Good, The Mary Rose = not so good). More often than not, the ‘naming ceremony’ encourages people to adopt a playful mindset. I’ve found that this helps people relax and assume positive intent from their colleagues.
Most retrospectives will identify several things that could improve the team’s collaboration. I usually limit the team to selecting one improvement each sprint. This is somewhat arbitrary, but it serves two useful purposes. Firstly, it establishes the principle of progress over perfection. Secondly, it ensures the team has enough capacity to focus on value-adding work for the user. If there are several serious issues that need to be addressed, I’m happy to abandon this principle. But it’s my starting point nonetheless.
Individuals and interactions over processes and tools
When people are new to running ceremonies the process and tools are important. They give us confidence that we have a structure to follow and if things don’t go as planned, there is something to fall back on. In time, these become less important. Regardless of the process, tools or structures I’m using, I always try to work to the following principles:
Relationships are primary, everything else is derivative — Rick Torseth
Believe that everyone can make a valuable contribution. Create a safe space for them to do so.
Encourage people to participate in a way that feels comfortable for them. Be flexible in accommodating their needs.
Don’t panic when things don’t go perfectly or rush to intervene at the first sign of friction. Instead, normalize challenges and assume positive intent.
Sincerely and publicly celebrate the team’s successes.
Cut people slack when they are having a tough day.
Have fun, play and laugh.
At least for me, following these principles has helped me to build a culture of trust, collaboration, and continuous improvement within teams. I hope they help you do the same.