9 min read

The Paladin’s Guide to Agile Teams

Explaining Agile teams through the eyes of a gamer (and a self-identified Paladin)
The Paladin’s Guide to Agile Teams
The Paladin's Guide to Agile Teams
The Paladin’s Guide to Agile Teams
Explaining agile teams through the eyes of a gamer (and a self-identified Paladin)

Disclaimer: there will be a lot of gaming terms in this article.

Hello! I’m a Paladin. I’ll protect your Scrum!

So yes, per the title, you can probably tell: I love games, especially MMORPGs. I’ve clocked many, many hours in World of Warcraft, Final Fantasy XIV, and plenty of other MMOs and games.

My UX designer, E, is a massive gamer too. She played, and continues to play, almost everything from WoW to Apex Legends to Animal Crossing. Over time, we developed this thing where we use gaming terms to basically explain anything, and discuss everything. After all, the fastest way to communicate is really to find that one common topic that everyone can relate to, that all parties understand.

Let me share with you some examples.

Gaming — a universal “language”

In reference to a food poisoning incident:

“Your damage-over-time debuff is much higher than your HP regen”

A mage suffering from food poisoning. That’s you, E.

When we were talking about her chronic back pain problems that regularly causes her to be in pain from just walking or standing:
“I need a new back”
“That one you need to isekai first. Isekai with OP stats, strength, vitality, agility”
“If I isekai, I want to be in a farming simulator. Cooking and farming”

Str and Vit stats too low to even do farming effectively.

(Beyond gaming, we also clearly enjoy watching isekai anime. Doesn’t everyone want to resurrect with overpowered character stats?)

In reference to our favorite ultra-workaholic Project Manager who always seems to be tiptoe-ing on the edge of burning out:
“If he’s not taking damage, he won’t enjoy the game”
“He keeps his HP constantly under 20% for the increased damage buff”

HP under 20% taking all these arrows. Attack increased 100%!

In reference to an app development project:
“I feel like I’m tanking this app”
“What tank? You don’t have any DPS or healers in this dungeon, you’re not tanking for anyone. You’re just solo leveling”

Playing solo is lonely (and scary).

I think you get the idea. Somehow it was just easier to relate everything with gaming terms — it made our communications and conversations not just fun, but also with a certain precision. What all of those conversations led to though, was this idea: what if software development and project management was just one big dungeon? Everyone’s just in a party together, working towards the same goal to clear the dungeon. Which means the next thing we need to figure out is, who’s playing which role, or class? We started assigning roles to the people around us — a bit like those personality tests.

The software development dungeon party

There was one thing we both always agreed on: our Project Manager was undoubtedly a tank class. Every time something cropped up, he was the first to the frontline, brandishing his shield, steadfast and sturdy, protecting the team. Clients, middle management, product owners, all sorts of folks would be bombarding him with messages, but he held the line, letting us focus on solving the actual issues without dealing with all that aggro. Undoubtedly, he was our ever reliable Scrum Master tank.

Our fierce warrior protector, Project Manager H.

Then there was our Solution Architect, agile and deft, his swordplay honed over many years, even decades, of experience. He was always the fastest to pick out the root cause of an issue, drilling down quickly to solve it and move past a production bug. Striking his blade right into the weak points of the dungeon boss, scoring critical hit after critical hit. Probably a melee DPS with a weakness exploit buff?

The ever skillful and nimble Solution Architect, W.

What about E? Well, she said she identifies as a Black Mage or Warlock. I pondered on it for a bit and decided that it made a lot of sense too. After all, she was the one operating from the distance, with each strike being an extremely heavy hitting Meteor AOE attack. Translated — she worked remotely most of the time, but would churn out massive amounts of diagrams, screen mockups, user research, Lo-Fi and Hi-Fi wireframes and UI, accelerating our development cycles. Definitely a top-notch ranged DPS (albeit a glass cannon one with a chronic back issues).

Black mages like casting huge fireballs and meteors with loud explosions.

Then came the question — what class am I?

So what’s my dungeon party role?

I’ve always been a Paladin, since the WoW days. I have a fascination with Paladins. Be it Diablo II, WoW, FFXIV, Guild Wars, etc, I’ve always picked this sword-wielding and magic-wielding knight as my class. More specifically, I enjoy playing the tank role — where you are expected to lead the charge in dungeons, managing the size of each mob pack, drawing aggro across all the enemies and bosses, diverting and pointing bosses away from the party, and taking on as much of the damage as possible while the rest of the team works to take out all the enemies.

The Paladin - knight protector. Tanking all that aggro and damage.

Naturally, I should also be a tank, right? But no.

“You’re definitely not a tank. You’re a Bard.” E replied, laughing.

A Bard! I was suddenly struck with an identity crisis. 17 years of playing tank classes, and suddenly I’m told that I’m not one. I couldn’t sleep that night.

Having an identity crisis trying to select which weapon to pick. Must I give up my shield?!

I thought back to the most recent fire-fighting incident I had, with both my tank PM and DPS SA. I was the product guy, with my high familiarity over the user flows of the product and the product roadmap. If you wanted to know how the system was supposed to work, I always had the answer at the snap of my fingers. More often than not, my role was to stand further back with the eagle-eye view, and step in where it was most appropriate. As the team was deploying to production, I spotted an error with an environment variable and quickly informed the SA. When the PM needed support explaining something to the client, I quickly shared a flowchart and jumped in the call. When we needed to verify the fix we pushed, I quickly pulled out Postman to test the APIs.

I guess in this case, I did feel like a Bard. A support DPS role, focused not just on dealing damage, but also supporting the party with well-timed buffs to boost their damage, and maintaining that eagle-eye view to call out scenario changes. Essentially a playmaker.

I see everything. Careful of that additional mob pack coming this way!

But I wasn’t always the Bard. Sometimes I was that tank PM, sometimes the melee DPS, sometimes ranged. (Or sometimes AFK 😆).

The Agile software development dungeon party

Most MMOs focus on classes that fulfill the Tank, DPS, Healer roles, with some classes also acting as party-wide support or providing other kinds of utility. This has always been the “holy trinity” of MMORPGs. But as I reminisced about my WoW Burning Crusade days, I recalled a time when this holy trinity wasn’t that important. We could go into dungeons with any kind of party configuration. I remember doing a dungeon with 2 hunters and a Retribution Paladin — essentially, 3 DPS classes with no actual tank or healer. Getting through a dungeon wasn’t about following a framework strictly, but about having the right teamwork and coordination, and every player in the party pulling their weight accordingly.

After over a decade of playing MMOs, what’s my favorite part about all these games? It definitely wasn’t the leveling grind. It wasn’t always about the story either, or about how challenging the dungeons and raids were. It has always been about playing with people, playing with friends, and succeeding together.

To build a delightful and fun product, you kinda need a team that knows how to have fun together too.

Roles can switch, depending on different situations. In a raid, the tank can be taken out. The whole party can be wiped out, but the dragoon, a melee DPS, can step up to do his best to pull aggro from the boss, while the healers attempt to resurrect the tank and the rest of the party.

In real life, things aren’t all that different either. Roles switch, tasks get transferred, depending on situations, people’s availability, and different problems faced. Ultimately it’s not about roles. It’s not about classes. It’s about a group of folks getting together as a party to conquer dungeons/raids and the most difficult bosses. I mean the dungeon boss fights, not the boss paying your salaries (although sometimes the real life bosses are indeed the boss fights 😆).

Does it really matter whether you label it Agile, or Scrum, or some other project management framework?

I think Agile was never about project management. It was never supposed to be a question of Waterfall versus Agile, or what methodology allows for faster development or higher quality software. Ultimately, being Agile is about building team culture, aligned values and principles, responsibilities and ownership, and relationships and communications amongst team members. And only with all of those aligned and in place, do you get your high performing team. And with that high performing team, you get the improved results.

The Agile dungeon manifesto

Individuals and interactions over processes and tools.
Team dynamics and communication matter more than anything else in a dungeon or raid. The same goes for software development. How the team functions together and communicates effectively is more important than trying to measure them with some arbitrary statistic like “velocity”. Having the DPS players scoring record-level damage outputs doesn’t matter if the dungeon still wipes because the healer or tank died.

Working software over comprehensive documentation.
There’s no need for a hundred-percent rigid strategy before going into a raid, because things will definitely change. Not everything is going to play out perfectly. But the objectives and deliverables do need to be clear. All party members should know what that product vision is, and how they can contribute towards it. Beyond that, a high performing team can hit the ground running and clear a dungeon together, even if it’s their first time.

Customer collaboration over contract negotiation.
Unfortunately in the real world, the customer isn’t an NPC quest giver with a fixed “kill 5 rats” quest with a 50-gold reward. A customer’s needs can evolve. Working together with the customer is probably much more effective than treating the customer like the dungeon boss. No point arguing at the tail-end — rather, keep them engaged throughout the development process.

Responding to change over following a plan.
Adaptability matters a great deal in a world full of unexpected obstacles. Everyone has a role and responsibility, but what matters more is being aware of what’s going on, and picking up the slack where possible. Just like a Red Mage DPS resurrecting the healer in a raid in FFXIV.

Does it mean we will always succeed? No. Sometimes it takes multiple tries before we successfully clear a dungeon. Embrace change and unpredictability — focus instead on building a team that performs well, not a game where every move and outcome is pre-fixed.

So are you ready to build your own high performance dungeon party to take on those savage tier raids?

I think we are ready for Savage Raids!

P.S. I guess in some ways, does that make LinkedIn the Party Finder tool?