A few years ago, before the pandemic, I visited an Agile conference in Kyiv, Ukraine. At the very end of it there was a panel discussion with some of the big names in the European Agile world. Among many questions addressed to the panelists, there was one that I remember well. The question was: ‘What are some of the arguments against using Scrum?’ But it was not the question that scratched the back of my head, but the answer. One of the panelists replied: ‘Why use something that claims to be agile, but is only updated once every 3 years or so’. To be fair, at the time, that answer left me puzzled, as I have never thought about this. Why indeed? All I could compare Scrum Guide update frequency with was SAFe, and the latter was having an update more frequently than Taylor Swift or Ed Sheeran could drop a new album. Hence my natural impression was that Scrum theory itself is not getting refined frequently enough. As it was not urgent, I left the issue parked until the better times for tackling it will come.
Since then I’ve moved on to learn more about Scrum: using it more and more in my work, reading more relevant industry books, expanding the horizon, attending networking events and trainings. Even decided to attempt the path of a Professional Scrum Trainer, which was quite a ride in itself. All of the above allowed me to fill in many gaps, change the perception around certain aspects of Scrum utilization and discover that there are still things for me to discover that I didn't know even existed. I’ve started to get a glimpse of what the answer for the question of slow-paced Scrum Guide updates might be, but still wasn’t 100% sure. At least two things were pretty clear at this point. First - there are thousands of companies and millions of people around the world using Scrum. Changing the Scrum Guide, which is the only thing that Scrum is based on will impact all of them, so you better be extremely careful with what you change. Second - Scrum is actually way more complex than I initially thought. Although there are many patterns, the number of permutations of different challenges and complexities that arise when trying to apply Scrum are almost endless. They also tend to evolve as business strategies and technologies evolve.
Weirdly, I’ve stumbled upon a possible answer while playing video games. I’m a big fan of Real-Time Strategy (RTS) games, and at the time, I was having trouble beating a certain tactic that my opponents were using. Unable to come up with new ideas myself, I started looking for some guidance online. Surely within 15 minutes I was inside the youtube limbo, unable to resist the algorithm. Eventually, I got to the video, describing one of the most iconic events in the history of Starcraft Brood War. The video was about the match between two professional players from South Korea in 2007: ‘Bisu’ and ‘Savior’. And before I proceed with the story I’d need to add a few details (so it all hopefully makes sense to other people too).
Image credit TL.net
As for the game itself, there are 3 possible races for you to play: Terran, Zerg and Protoss. Each one of those has a unique toolkit, strategies and strengths. From its release in 1998 until 2007 the game had just three major balance updates over almost a decade. Does that pattern ring any bells yet?
Image credit Blizzard Entertainment
In 2007, the Protoss vs Zerg matchup, also known as PvZ was heavily Zerg favourite. The statistical evidence suggested that Zerg players were winning ~54% of all the games, with even higher numbers at a professional level, where mistakes and deviations were much less likely to happen. Naturally, ‘Bisu’ (playing as Protoss) was considered a heavy underdog prior to the match. However, he brought in an unexpected and innovative strategy and won the match 3-0. This has earned him the nickname ‘revolutionist’. No need to say that this person has single-handedly turned the PvZ metagame around and Protoss became the favourite in the match-up. So how was ‘Bisu’ able to pull this off? Skill and most importantly - Time!
The satisfaction, when doing pretty much anything, comes from skill. Whether you ask Dan Pink, a chess Grandmaster or a 12-year old playing ‘Mortal Combat’, mastering your craft is the ultimate way to pull off the Woo-Hoo moments that you’ll be telling your friends about. Sadly, it does take a while before things can develop for a game-changer moment like this can happen. And while this moment lasts just briefly, the time investment behind it is usually measured in months or years. Hundreds and thousands of hours of hard-working, tireless grinding, failing and trying again that are left backstage. So it was clear for me now that even within an environment seemingly still and slow-paced (AAA game with 3 major updates in 10 years) amazing and innovative things can and do happen.
Now let’s get back to Scrum. When you think about it as a product that is used by more than 10 000 000 people around the globe (likely the actual estimated number is even higher), you’ve got quite an audience to keep happy. You certainly don’t want to rush in the changes you assume would be good as it poses a risk of failing to understand what impact they make and ultimately disappointing millions of people using your product (playing your game). So, co-creators would need to make cautious and well-informed decisions about making a new update. But how much time would it take to solve this complex riddle? We can try to evaluate.
Let’s take the latest 2020 update as an example. For a team that is already using Scrum, it would take many Sprints to learn how to apply the new things like Product Goal, Artifact Commitments, shift of accountability for the Definition of Done and delivery of the usable Increment to the whole Scrum Team. Speaking for myself, I can tell that it has been over a year and our team has just managed to get basic things going confidently and is still actively optimizing our process to get better results. So let’s say, on average, it’d take from several months to 1+ years for the Scrum Team to make things work and be in a position to accurately observe the impact of the changes and be able to share the learnings with others, and provide feedback to Scrum co-creators.
Those were the teams that have been boiling in the ‘Scrum cauldron’ for quite a while and their perception of change. A fresh point of view, from the outside, can be of the same value. And how much time would it take for a team that just started applying Scrum to achieve the most basic (mechanical) process? And how long till they can make things work well enough to get to the point of a Woo-Hoo moment that will be worth sharing? Likely years. Don’t forget that after all of the above, the feedback must be aggregated, digested and analyzed to allow the co-creators to come up with a better version of Scrum Guide that’s likely to bring a positive impact on the Scrum community. The 2020 Scrum Guide version was revised at least 15 times before it was good enough to share with the world. So yeah, good things take time.
So there you have it. If anyone ever asks me why is the Scrum Guide refined so rarely, I just answer that it’s because back in 2007 Protoss started beating Zerg in Starcraft. Frankly, I am happy with this answer. Are you? Please share your thoughts in the comments below.