For the past four years, we've done scrum the same way. Standing up at 9am sharp.
Our scrum is straightforward. What were you working on yesterday? What are you working on today? Are there any changes to plans or intersecting efforts that should be discussed?
When we were small, this worked great. As we grew, we needed to tighten up our scrum updates to keep scrum an efficient use of everyone's time. Then our web and mobile teams started participating in a combined scrum so we had to make our updates even more concise. Around this time we also made a decision to save any tangents or questions for after scrum to make sure we weren't wasting a large portion of the team's time while two engineers went into the weeds on something.
At fifteen engineers, we were still under 10 minutes, but one engineer keenly asked recently:
Everyone just gives a brief, high-level update of what they're working on, but we all know what projects everyone is on. Isn't the point to surface those issues so we can go into the weeds? How am I supposed to remember my questions I want to follow-up on while I'm supposed to be paying attention to everyone else's updates? At this point, what is the value add of scrum?
These questions made it obvious that our scrum was no longer serving its intended purpose. It was hard to believe that a process we did every day for so long had been broken and we didn't know about it.
So we ran a little experiment. We created a new Slack room for scrum. Every day, before or at 9am, everyone posted their scrum update. The new guidelines were to not worry about brevity or being too deep in the weeds. Scrum updates are now opt-in in terms of who reads what so you won't waste another engineers' time with specificity. Say what needs to be said to inform teammates with what they need to know about your efforts for your project.
We ran the experiment for a week and voted anonymously during our next sprint retrospective whether we wanted to continue doing scrum in Slack. The vote was unanimously in favor of Slack scrum. The purpose of scrum was restored and the team was in full support of the process change.
In addition to fixing scrum, we also discovered that our new Slack-based scrum yielded new value for the team.
Evergreen
When someone misses stand-up scrum or someone is on vacation, there's no way for them to know what everyone said during scrum. With Slack and its evergreen nature, you can now go on vacation for a month and be able to catch up on what the team has been up to in a matter of minutes.
Having this visible history of scrum also results in increased accountability. When you get ready to post your scrum update, yesterday's update is still in view. It can act as a helpful prioritization tool to see what you said you would accomplish the previous day when you're getting ready to prioritize your efforts for your upcoming day.
Working Asynchronously
Stand-up scrum is synchronous in nature — only one scrum update or conversation is occurring at any one point in time. While some companies like GitHub intentionally gear their processes to be asynchronous, we sort of fell into it serendipitously with our new scrum format.
Having an asynchronous scrum has multiple advantages. For one, we no longer have a forced interruption every morning. If someone wants to come in early and get a head start, they can post their scrum update and check back to see the rest of the team's update once they come up for a breather.
If someone posts a scrum update that you want to follow up on, you don't have to worry about de-railing stand-up scrum with a question. You can spin up a separate Slack thread and dive into the details without stopping scrum or wasting anyone else's time.
To play devil's advocate, there are some downsides to asynchronous Slack scrum. For one, if you're not on a project with someone, it's possible to go days without face-to-face interaction with them. Over time I could see this being a morale issue. Stand-up scrum can also be a nice kickstart energy-wise to the day so this is something we'll be keeping a close eye on as well.
Revisiting our agile processes is something we do regularly through sprint retrospective. Typically the catalyst for process change is an inefficiency surfaced by the team, which was the case for scrum, but we'll be taking a new angle on this in the future. How can Slack and other technologies that have become engrained into the way we work help evolve our processes to be more efficient and yield more value?
