In a great blog post from Coding Epiphany from 2015, cross functional Scrum Teams were compared to RPG parties, mainly focused team makeup, skill specialization versus crossing roles and forming a team as you go.  It’s awesome and nerdy.  I had a similar idea, but instead of that comparison, I wanted to compare a Scrum Team to Team Mechanics from online gaming, mainly MMORPG or maybe some team based shooters.

Online Gaming – Party Structures

So there’s lots of games out there where people get together in a group to complete an objective, most often defeating some bad guy or a group of bad guys, or to grind out loot or experience, or completing missions. For the record, the majority of my online group based activities came in Final Fantasy XI, which I played for many, many years (more than I like to admit to myself sometimes). FFXI, the first cross-platform MMORPG, just dropped Playstation and Xbox support yesterday, so it happened to be on my mind a bit lately. However, I have played some other games, and looked into many others, and with maybe a little bit of tweaking, most of the things I’m going to say should fit in with those games as well, for example your World of Warcrafts, EverQuests, or even team based online shooters with classes like Team Fortress 2 or Evolve (to name two). I won’t profess to be an expert on those, but hopefully the things I’m saying are applicable.

So generally in these sorts of games, there may be many classes, or there may be few, but they can generally be classified in four ways:

Tank – Tanks are the classes that will gather the attention of an opponent, and attempt to take the majority of attacks. They will usually have some way of mitigating that damage, or to avoid taking the hits.  Many times, the Tank will lead the party, as without the Tank, the party may have problems surviving, and the Tank will help the rest of the party determine what to do next. Many Tanks will therefore also be expected to have specific knowledge of the monsters they’ll be facing beyond what others may have, or other knowledge to help lead the party in the right direction.  Tanks are generally not expected to do a great deal of damage, and need to split their attention between what the opponent needs and what the party needs.  Due to their specialization, they may be able to do things on their own depending on the situation, but it’s unlikely.

Damage Dealers – Damage dealers are very often the most varied classes in any game. The job of the damage dealer is to attack the opponent until it’s gone, and there are generally lots of ways to do it. Sometimes, damage dealers can be highly specialized for one scenario; other times, damage dealers may be more generalized, able to apply themselves to more situations at the cost of not being able to be as effective as a specialist in their particular area.  Depending on the game, they may need to effectively coordinate with the other damage dealers to time attacks in a certain order, or to apply particular types of damage at the correct time. They may be able to act alone in certain solo situations, but this is generally not sustainable over long periods.

Support – For the sake of this post, I’m going to lump together healers and “other” support classes.  The job of these classes is to enhance and care for the other members of the party, and allow them to do their jobs. They help the tanks tank, by either making them more effective tanks, or healing damage without drawing as much attention, etc.. They make the damage dealers more effective by enhancing their skills or making the opponent easier to defeat.  They may also have specific information as to the opponent or the mission at hand, although it will generally be approached from a different point of view, and they may be expected to help the team with this information, for example, calling out situations that the damage dealers need to avoid, or helping coordinate timing or damage type switching that others may be too involved to watch.  These classes are generally ineffective when working on their own, requiring a team reflect their work.

Hybrids – Hybrids are the cross-classes, the jobs that can fulfill more than one role, at the expense of being as skilled at either role they’re taking at the time. Most often, the hybrid will be between a damage dealer and another type, such as a tank or support role.  For example, damage-support hybrid may sacrifice damage to allow themselves to provide some support skills to the rest of the team, but may not be able to focus on the larger picture of coordination, and they won’t have the range of skills afforded to a fully fledged support role. A tank-damage hybrid may require more maintenance to be successful, or require a co-tank in the form of another tank. This type of hybrid can be effective when working in conjunction with a main tank, deferring to the main tank as needed, but being available to support the tank for emergencies or unexpected occurrences. The final type of hybrid is the tank-support hybrid, who can keep the focus of the opponent while also enhancing the team. This is the rarest, because that’s a lot of differing focus concentrated in one role, and if something happens to that vital of a role, the party may fail completely.

So that’s a whole lot of digital ink spilled, and I haven’t really gotten into the realm of Agile or Scrum yet. Many of you who have and will never play an MMORPG know way more now about the mechanics then you ever wanted to. However, many of you already working in Scrum may be starting to draw the parallels. Let’s go ahead and spell them out.

The ScruMMORPG Party

Product Owner = The Tank – The product owner is here to be out tank.  They get the attention of the stakeholders, determine the plan and gather detailed knowledge. They then hold the focus with the team on the problem to be solved, the team’s monster to fight in this case. They help lead the team in the right direction, towards the value. They may have some knowledge regarding the technology, though they like don’t have enough to complete the task on their own.  They may be called on to protect the team from other monsters (projects) until the current one can be defeated. They act as the heat shield for the party, protecting the team from outside damage sources.

The Scrum Team = Damage Dealers – The Scrum team is here to attack the project the product owner is holding up for them. The product owner and team will need to communicate to determine how to prioritize which monsters to attack and in which order, though the Scrum team needs to determine best how to tackle each problem. This is the most varied group, with coders, designers, testers and other groups who all work together to apply their knowledge to the solution. Generally speaking, it is useful to have specialist who can also generalize out a bit, coders who can test, designers who can also code, and so on, so the work can be completed most effectively. They need to coordinate with each other through planning and day to day collaboration to ensure the stories they’re taking on are completed in a timely manner. Every once in a while, a member of the Scrum team may need to act on their own for a particular reason, and they may have the skills to do so, but they will find themselves more effective with their team.

Scrum Master = Support – The Scrum Master is here to be the support role for the team.  They are here to enhance the team functionality by providing methods for the team to work together more easily like pair programming and collaboration tools. They make the monsters easier to defeat by helping the team finds ways to attack more effectively and to break down the monster into smaller, easier to handle parts. They remove blockers and problems the team may face to allow the team to focus completely on what their tank has setup for them. Finally, they may help heal the team in times of conflict, working to navigate the conflict and bring it to a resolution. They are wholly ineffectual without a team, and their work is only reflected by the team and it’s improvements.

Hybrids – In business, sometimes we don’t have all the people we need or want to fill out a team. As above, we can use hybrids to help cover some of the roles on the team, as long as we understand the limitations and shortcomings of such a practice. The most common hybrid is the Scrum team member/Scrum Master. A team member will take on the role of the Scrum Master, while still taking responsibility for tasks the team is to complete. This can be successful, although this hybrid team member will be required to often think about what will bring more overall value to the team, doing work themselves or enabling their teammates. Less common hybrids are involve the product owner. The product owner/Scrum Master role is generally looked down upon, to the large amount of differing focus and purpose of these roles. Keeping the roles straight is difficult both for the hybrid and for the team.  Product owner/team member hybrids really only work in a co-tank solution as described above, where the hybrid is available to assist the owner, but the main product owner is in the lead for that role.

So there it is, over 1500 words to compare Scrum Teams and online multiplayer grouping.  I hope everyone that reads this feels just a little bit nerdier. I just found it interesting how well formed teams in online games, where efficiency is generally valued over many things, coincides so well with the structure of Scrum teams. Please let me know what you think in the comments, and I hope you look forward to my next post, hopefully coming next week.