Fixing Remote Scrum Workshop Fatigue
Frequent Virtual Workshops are Exhausting
The prevalent viewpoint among engineers is that meetings are a waste of time or at best a necessary evil. Before COVID, when my team was physically together we would find ways to make our scrum workshops enjoyable. Whether through donuts or team walks to our local coffee shop, we would use our environment to aid our decision making process.
With these outlets no longer available the prevalent feeling was pronounced. There have been many reports by Harvard Business Review, Forbes and National Geographic about zoom fatigue. On a zoom meeting you feel like you have to be completely focused on the speaker. If your mind drifts off, it’s hard to mentally re-engage, unless your brave enough to make everyone stop and repeat everything you missed. Since we all like to spare ourselves embarrassment it’s much easier to just mentally check-out.
When we were together, coming to workshops without a strict agenda felt fine. If a workshop was taking longer, we’d all break for a snack, coffee, walk, or all three.
Successful In-Person Workshops != Successful Remote Workshops
Now that we were remote, coming to a workshop without a clear agenda felt like we were wasting each other’s time. Remote workshops were taking about 20 minutes to actually start. This was due to deciding who’s leading, who’s presenting, and getting everyone on the same page. This also had the effect that by the time a good pace was achieved the workshop ended or would run long, which led to the aforementioned zoom fatigue.
Another problem with the workshops were that time was spent creating stories. The entire team was watching one person type out the story title and details. When everyone was physically together, writing up stories happened organically during the workshop. You’d have some people at the white-board, one person at the computer projecting his screen onto the TV, while writing the story, and another at the TV checking for it’s accuracy. This led to a dynamic environment full of conversation, where everyone was on the same page because everyone worked on different bits.
Now that we were physically separated and staring at the same computer screen, everything happened synchronously and slowly. We’d first discuss various ideas and then write up the stories. The single person sharing their screen would most likely be driving the conversation, while simultaneously transcribing what was said.
The times I facilitated, I was constantly frustrated with myself and the process. I was either transcribing what I just heard, so I missed what was said next, or the pace of the meeting had to slow down to the speed of my typing. It was a constant battle of either being behind the natural flow of conversation or having everyone match the flow of conversation to my typing speed. Everything felt scattered.
Through research, conversations with Abadi and Eric, and team retros the idea of the “sprint planner” was born.
Workshops are for Deliberation
As you can see there were a handful of problems my team was facing. When building each feature of our application we needed shared understanding of the problem, a thought-out plan for the overall solution and the solution divided into stories with the pertinent acceptance criteria.
We assumed since we did this as a team when we were physically together that we could do the same now that we were physically apart. Our experiences told us otherwise.
When planning for the upcoming sprint the desired outcome is to have a pointed set of stories that achieve the sprint goal(s). That way you start the next sprint with everyone having a shared understanding of what the team plans to accomplish by the sprint’s end.
Work outside the Workshops
The work we were doing could be done outside the workshops by one or two team members.
Each workshop needed to be a checkpoint towards a planned sprint with demo goals and pointed stories that showed how to achieve those goals. Deliberation is the point of the workshops, not busy work. So we set forth with this belief.
The process we came up with assigned responsibility of creating stories to one team member, called the “sprint planner”.
We have 2-week sprint cycles that run Monday through Friday. The workshops are highlighted in yellow.
On the other days, the sprint planner is working outside the workshops to plan to the sprint. The sprint planner can delegate the work to another team member, but the responsibility still lies with the sprint planner to complete the necessary tasks before each workshop. It’s their job to make sure it happens even if accountability is spread among the team.
It Starts with the Sprint Goal(s)
It all starts with the team agreeing to what they plan to demo in four weeks. These are the sprint goals. It’s four weeks because you’re planning what you’re demoing at your next sprint’s review.
If you have a roadmap you can see what’s next or your Product Owner can guide you. Once the team decides on the sprint goals, the first workshop is complete.
Stub out the Stories
Now that the sprint goals are done, the sprint planner creates the story titles. During this process you’re creating the shell of the work to be completed by the team in the next sprint.
The image above shows a backlog of stories the team would review at the next workshop. The sprint planner can add acceptance criteria, but it’s not a requirement. The requirement for the next workshop is to stub out the work that needs to be done.
The team then comes together at the second workshop to review the stories and discuss if anything needs to change. The sprint planner facilitates the meeting, going through each story and how it relates back to a sprint goal. This keeps the meeting flowing forward and removes the pressure for information to be captured perfectly in realtime. Since the story titles are already created, the team’s time is used to ask questions, validate assumptions and discuss possible solutions for each story.
Fill in the Details
Once the team has a high-level shared understanding of all the stories, the sprint planner then writes out the details discussed and the acceptance criteria before the third workshop. In lieu of acceptance criteria, the sprint planner may write questions for the team to answer at the third workshop.
Review, Deliberate, Finalize
The third workshop is probably the most important as the team is reviewing the details of each story. The stories should be written with enough information so that any team member can pick up any one of them and work on it. This is also where misunderstandings and misassumptions can come to light since the team is now discussing the details of each ticket. If changes are needed, the sprint planner can do them before the final workshop.
The last workshop is for the team to review the details one last time and point the stories. Once this is done the upcoming sprint is ready.
Pass the baton
The last act is for the sprint planner to be decided for the next sprint. This can be through volunteering, random drawing, round-robin scheduling or any other method that works for your agile team. I’m a big fan of round-robin scheduling since it sets expectations for everyone on the team. However, the baton should be passed.
It’s easy to lean on team members with natural leading abilities to the detriment of the team as a whole. Changing who’s responsible for planning the sprint and facilitating the meetings gives every member a chance to sharpen those skills. This can happen at the end of the final workshop or anytime during the sprint.
Final thoughts
Depending on which stage your team is in you may need more or less workshops than what I proposed. If your team is in the performing stage, you may move through these various checkpoints faster.
The big change this process brought to my team is that the time we spent together was focused on discussion. We were no longer watching one person juggle active listening and writing. The organized stories were only used to progress the meeting forward. These steps created a good rhythm for meetings, with expectations known beforehand.
Every team is different, and this is not a prescription. These are guidelines we follow as we work towards becoming a highly-productive fully remote agile team.
If you found this post helpful, please sign up for my newsletter at niarcas.com. In it I share more long form essays on managing software teams, human-centered research and design and servant leadership.
If you found this post helpful to your software journey, please subscribe to my newsletter where I talk about my experiences building software for myself, others, and helping aspiring product managers do the same.