Raiding your product
Scrum and Games Vol. 3
This Article is part III of a series where I talk about how we can learn to Scrum better from video games. You don’t have to read the other two though, this article can be understood in a vacuum. It’s okay!
I admit, I was a hardcore WoW player myself. I probably logged somewhere up to 10.000 hours played in it, with thousands more standing around afk in various cities, chatting with my guild mates. But while in retrospective I probably should have spent half of that time writing another novel or three, I honestly believe that my time leading a raid (a group of 10+ players trying to defeat dragons and other “bosses) in World of Warcraft has made me a better Scrum Master. It has also taught me the value of goals.
When you get down to the bottom of it, a raid in World of Warcraft is a complex problem. In and of itself the fight is scripted, controlled and learnable. As with any other game, if you had a group of deep-learning AI play, you could kill the boss 100% of the time. The problem (read: what makes it fun and exciting) is the human component.
With 10 to 25 players, a raid is like performing a ballet with each dancer solving an infinite rubric’s cube. If someone steps out of line or if people don’t solve their cubes fast enough(1), you have to start over. Keeping with the metaphor, it follows that the main goal of any raid group is to dance perfectly first and foremost, and then also have each dancer rubric’s cube solved as quickly as possible.
This is their sprint goal.
Just like a sprint, every raid is timeboxed. People have real lives, families to get back to, pets to feed and work to sleep for. As such, most raids are a timeboxed event between two to four hours. Sometimes longer or shorter, depending on how well equipped and practiced you are , and how many bosses there are in a particular raid dungeon. And just like in Scrum, a good raid obsesses with numbers.
It isn’t just the game you are in contest with. The best guilds compete for the first completion, fastest clear time, etc. But in addition to the complexity of the raid itself, there are at least 16 hard factors (slots for better equipment) with over hundreds of possible items for each slot available at any given time, all interacting with each other. And this is leaving out the multiplicative effect of specializations and talents. What could be a good enchantment for a frost mage might be terrible for a fire mage, for example.
In order to penetrate this complexity, players funnel the data they generate in a raid encounter through a myriad of tools, trying to squeeze out minuscule dps(2) increases. Just like a semicolon in a line of code can break a website for days, often fractions of a percentile of dps can make the difference between success and failure. But the self improvement does not stop there.
As I mentioned, through successful completion of a raid day you get loot, which allows for easier completion of said raid, which results in more loot, which allows you to take on harder difficulties, which result in better loot, which… you get the point. More importantly, players master the fights over time, learn how to deal with emerging patterns, and improve their muscle memory in performing their spell rotation. You also learn how your fellow players think, and to rely on them in dangerous situations. (3)
Bust just like in a Scrum Team, players with strong personalities playing together will create problems. As a guild lead, raid lead or officer, you often have to mediate. I cannot count the amount of times I had to soothe players who didn’t get the best piece of loot a boss had to offer, but my favorite moments were those when people passed on gear to give it to those who needed it the most to help the team succeed.
But success in raids is not just dependent on performance in the raids themselves. They all have the same goal in completing the raid dungeon, but each player needs to do individual activities in smaller groups to reach that goal. There is the aforementioned stat analysis which players usually perform on their own, or with help from their guildmates. Maybe they even reach out to other guilds with well-known players for advice, or ask for tips on forums and message boards. They run dungeons either in small clusters of guilmembers or find strangers to play with.
The goal is clear.
They want to defeat that raid.
They want this:
And to do so, they self-organize.
If you want to, point out these things to your colleagues who struggle with Scrum, but play WoW. Remind them that they are already relying on empiricism, and that they have overcome social problems in the past. Remind them what happens when you have a goal everyone subscribes to, and what they can achieve when they stop waiting for stuff and start doing things!
Raid your Product!
And this is it, folks. Part three of three. I hope you enjoyed reading these articles, and that they can help you see the world through a lens of fun and excitement. Go ahead and take what you will from them and apply them to real life, inject some dopamine into your Scrum! ;D
Gamify your Scrum, be playful with it.
And please — as always — come back and tell us what you learned.
Do you want to write for Serious Scrum or seriously discuss Scrum?
(1) A lot of bosses have so-called “enrage mechanics” that kick in if you don’t kill the boss fast enough. Various mechanics exist, from simply increasing damage to mind-controlling the strongest players to kill their allies, but the core design goal is to ensure that all players put out enough damage per second (dps) for the boss to die in a reasonable amount of time, instead of just spending hours in a boring fight.
(2) I am aware there is more to raiding than just DPS, but discussing healing and tanking goes beyond the scope of this article.
