Role Playing Delivery

I spent many hours of my life playing RPGs. It started in a secondary school with “talking” D&D and Warhammer, and then smoothly moved to less problematic computer games such as Icewind Dale (I still have nightmares related to the second part), Baldur’s Gate, Neverwinter Nights, Morrowind (which is probably my favorite one), and phenomenal The Witcher, of course.

A few years later I logged into World of Warcraft for a while and … logged out after almost two years, due to the necessary visits to the addiction treatment center. Oh, I had a similar love story with Football Manager, but only a few will understand this fascination;)

Why am I writing about it?
What turned me on the most in role-playing games was building a team from characters with different traits (races, classes, specializations), leveling them by gaining experience points, and — in the case of WoW — a team PvE mode.
What always interests me at work are the people I work with. Mindset, Skills, Tools, Communication, Communication.

Comparing a fearless group of adventurers who are trying to get the magical artifact guarded by a terrifying and invincible demon, to the development team trying to deliver features to the Client is… funny :) Let’s say that our Deamon’s name is Deadline, his Minions are Users, and our boring daily work turns into a pretty good dungeon.

To be clear: the main boss is NOT the Client, although I know the comparison fits very well in many projects :P The client, or his representative, should be a part of our Team.
I am saying it quietly, bowing my head under the burden of my own mistakes.

Let’s build the Team!

For me, the most natural way to deliver software are agile methodologies, so let me describe Scrum roles using roles known in World of Warcraft :) What? Creativity is a precious gift and you have to go on the road.

Tank:

This role draws the opponent’s attention to himself. His goal is to allow other members to focus as much as possible on their tasks.
For me, the equivalent of the Tank in scrum is the Product Owner, as by definition he is a part of Scrum team, he sets the direction for the development of the application. Because he has direct and most frequent contact with the client (let’s do not consider a situation where PO is our Client :P ), he takes the greatest responsibility. Without him, the Team would have no results and the developers (DPSes) would suddenly have too much contact with the client, which would create chaos and reduce the team’s efficiency. And eventually, they can die in the terrible flames of burnout.

Dps:

Their responsibility is to deal damage to the opponent. Theoretically, the least responsible role, because there are few of them, but it gives a lot of “easily measured” satisfaction and allows you to compete internally in the team.
In the project, these are all people building the product: programmers, testers, designers, graphic designers. The more specialized they are and the better they know their job, the easier it is to build an efficient team that becomes more effective in the fight with Deadline. Just like the DPS in the game has to “make numbers”, the technical person has to be as productive as possible.

Healer:

My favorite role. This is a support that has no real impact on the fight, but he keeps the team alive, healing it, removing diseases, curses and not allowing anyone to die. He usually stands “behind the scene” so he has an overview of the “battlefield” and the possibility to analyze the situation.

Ok, that’s naturally Project Manager, right? No. I see here rather a Scrum Master, and the keyword here is Servant Leader — a person who takes care of other team members and has the Client in the context. He has to observe, he has to react, and he has to have a brain in addition to his eyes. He needs to be responsible for the entire team. This role is a bit ungrateful because people pay attention to it (they shout at this person and swear) usually when they die, but when everything is going fine then no one thinks about healers. But often when Manager wants to build a team he is looking for Healer at first.

Tactics

Each opponent has its unique characteristics and difficulty level. He requires proper preparation, knowledge of what and when to do, and what to watch out for. It often turns out that the skills of a specific character are what we need to win. What if we don’t have him/her on the team? Well, you have to find them or consciously improvise.

In the professional reality, we have different projects, different pressures, and we have to have in mind not only technology, infrastructure, but also the composition of the team and different characteristics of the members. I saw and participated in projects where there was chaos, although the team was consist of great specialists

Communication

In all this fun, the key things are synergy and communication between team members.
Having even the best players in the team individually, we may not make it, if they cannot cooperate and sacrifice their individual statistics for the team’s goal.
And this metaphor does not need to be explained — the same rules apply to the development team.

It was the point that began my fascination with agile and Scrum because tools such as pair programming, planning poker, daily scrum are mainly aimed at improving the quality of communication, so understanding, so efficiency, and helping to respond better to the crisis in the project.
Then the technical quality comes by the way.

And to be clear: communication in scrum is not daily scrum moved into the waterfall and “more talking than doing” just so that the Project Manager or Team Leader can build and satisfy their comfort zone;) by maximizing micromanagement.

Epilogue

I like games because they allow me to practice management and human interactions in a safe sandbox. Although it’s a bit risky when they also learn me to looking at characters as “avatars” and a set of numbers, but, in large companies, we do not talk about people, but about Human Resources, so it may even be an advantage;)

Yet another thing is metaphors. One of the best books I have read about Scrum is “Scrum. How to manage agile projects. “ written by Mariusz Chrapko. This reading helped me to realize that scrum, and especially its translation, is a constant play with words and metaphors. We build an abstraction that allows us to better focus on the goal and achieve it effectively because everyone understands the story they are actors of.

Games can be understood by little children. If you have made it so far, thank you, and feel free to share your thoughts in the comment section below. I am glad if this post provokes someone to reflect on the perception of the team, co-workers, or employees. And games, of course.