I thought I knew everything about Scrum theory. But the one thing I didn’t know was that the framework is sufficiently resilient that not even a pandemic can stop it in its tracks.

Let me tell you why. But first, some background.

I am a technical project manager and Scrum master on the data engineering team for Major League Baseball. On a daily basis I eat, drink, and sleep all things Agile methodology, particularly Scrum.

My team works on solving complex problems in baseball stats and analytics. We build data pipelines, databases, data analyzing tools, and visualization tools to answer every question possible about traditional baseball stats (who leads the league in home runs?) and statcast stats (what batter has the highest exit velocity against The Yankees on two strike counts?).

Needless to say, some of the engineering challenges we face are not easy. And with difficult problems to solve, there is a heavy premium placed on excellent communication – it’s one of the key things we look for in hiring talent.

It’s one thing to build an intricate application that calculates home run distance based on on the launch angle and exit velocity of the ball, it’s another to write it all down and explain it to our key stakeholders.

Insert the COVID-19 pandemic into the fold

The season gets temporarily cancelled, our roadmaps get shuffled, and we are all forced to work from home indefinitely.

As the Scrum master for the team, I am all of a sudden thinking about how this will affect our communication, throughput, and quality of work.

Previously, we were all co-located in a small San Francisco office where everyone came to work each day. It was great – imagine one big room with an open floor plan where people just write code, bounce ideas off of each other, and watch baseball games.

But now, we are all communicating over Slack and Zoom, and I’m left wondering if things are going to slip through the cracks.

What did I do? I freaked out and started adding more meetings. This would solve our communication shortage, right? Just throw more meetings on everyone’s calendars!

So that’s what I did.

1. Happy Hour

I added a daily “happy hour” that was optional to attend. The goal was to provide a social outlet where people could talk about work or non-work related items in a casual, albeit still virtual, setting.

That one lasted about a week before people stopped going – but more to come on that later. First I want to go over the rest of the failed meeting attempts.

2. Happy Hour Part Two

The second was yet another Zoom “happy hour” with a slightly larger audience that included some folks from our New York office as well. That lasted even less than a week.

3. Leadership Overhead

The third bright idea: a “leadership” call between myself and the three dev leads where we went over in-flight projects and upcoming roadmap items.

I thought our roadmap would be ever fluid during the pandemic (which it was), so why not talk about it every week?

4. Additional Stakeholder Meetings

And finally, I set up additional touch point meetings with key stakeholders to make sure we were meeting their expectations and getting their feedback on our delivered code fixes and enhancements.

I thought I was taking a proactive approach to solving a problem that no Scrum team has ever gone through: going from a co-located work environment to full remote work while maintaining full productivity levels, strong communication, and high quality of work.

Little did I know, Scrum had this all covered and I freaked out over nothing.

Here’s why.

Scrum provides a framework for how teams can go about building products through iterative cycles of constant feedback and improvement. This framework calls for a variety of different meetings (or as my manager prefers, ceremonies), that facilitate these development principles.

And through these meetings, I came to realize that all of the problems I was trying to solve for, were in fact, already solved by Scrum.

Revisiting my list of additional meetings – let’s walk through why each became obsolete

1 and 2. The Happy Hour Meetings.

It is a best practice in Scrum to hold daily standups. Each developer on the Scrum team goes over what they did yesterday, their plan for today, and if they have any blockers or issues they want to flag.

Early into the working from home life, this daily meeting became a nice touch point to say hi to colleagues and have a bit of social time together. This often took the form of baseball trivia since most of us are big fans of the game.

And while the rules of Scrum say that daily standups should be no longer than 15 minutes, I figured this was well worth going over that. You see, while many Scrum masters are very rigid and treat Scrum as a "science", I am a bit more fluid and treat it more as an "art form".

3. The Leadership Meetings

The leadership meeting was to have a consistent meeting on the books to go over small and large roadmap items. It was to convene and prioritize items based on news about when the baseball season might return.

Again, I thought I was doing my team a service by adding this additional touch point. And again, I was wrong.

It’s another best practice in Scrum to hold a backlog refinement meeting at least once per development sprint. This meeting is used to review the upcoming bugs and features in the backlog and to prioritize them for future development cycles (sprints).

My dev team and I had been consistently holding these refinement meetings before the pandemic, and sure enough, this was the perfect solution for the problem I was trying to solve – it was there all along.

I quickly realized that we were just repeating ourselves in the leadership meeting. It was pointless to have both.

4. The Stakeholder Meetings

Since we were all working remotely, I figured we should communicate more with stakeholders to make sure we were all crystal clear about what they should expect from my dev team. By now, I’m sure you’ve guessed that Scrum also accounts for this in their guidelines.

The Scrum playbook calls for a demo at the end of every sprint where the dev team gives demos to stakeholders and asks for feedback.

We have been doing this remotely now, and it has had the same effect as always – it shows what we’ve been working on and it creates a forum for quick feedback from the people who have an interest in our product enhancements.

What I Learned

Hitting the fast-forward button to today, all of those aforementioned meetings have been cancelled indefinitely and my Scrum team is continuing to deliver consistent results to our stakeholders.

My bias toward taking action with additional meetings, while well-intentioned, only added repetition and clutter. Next time I guess I’ll think twice before trying to reinvent the agile methodology wheel.

There are two important lessons I learned while transitioning to working on a fully remote team during the pandemic that I hope are now obvious to you.

Firstly, it’s that the Scrum framework is resilient and already set up to work in almost any team environment. Its built-in touch points and meeting cadences are the perfect solution that were and still are staring me in the face.

My bias was towards action. But before actioning yet another team meeting, my bias should have been towards the question "why"? This brings me to my second takeaway.

I learned that before adding an additional meeting, you should ask yourself “what is this meeting trying to accomplish? What’s the goal? Is this not already being achieved by some other meeting or other form of communication?”

Surely, this litmus test will catch a lot of repetitive meetings and save a lot of people time on their calendars. Your team will be happier and more effective as a result.