The Red Dragon approaches from the distance, its wings brought terror and death. An impending doom is coming towards the city. The bell rang and the kingdom shook ablaze. A group of brave adventurers are ready at the gates, waiting silently to face off this monstrous beast.
The Red Dragon is a massive creature. Its body weigh around 100 story points. Its wings made out of uncertainty of business decisions. Its breath weapon is an acidic taste of coffee in the late night overtime. Its speaks with Draconian magic, commanding people to obey him and serve him forcefully like a corporate slave.
The adventurer that stood at the gates, never slain a beast this big. They probably nervous and scared at the same time, as if the spell of Imposter Syndrome washes over them. Before the battle begins, we gonna take a look at this brave adventurers:
- Tim, a young Frontend Ranger. His quiver is full with the Tailwind Arrows. His bow is made out of Javascript wood, its probably not the best but it will serve its purpose.
- Greg, The warrior who clad himself in the full body armor who called himself the “Iron Golang” is arisen by the horn of war; the sound of API CALLS.
- Sue, a Mastermind Rogue who strategize how they will approach the monster. The layout of the terrain and building is being drawn into series of Patterns and Architectural Design.
- Steve, in hooded robes leaning on a crooked stick. Nobody knows him, but rumors said he is The Devops Warlock. He understand the Ebb-and-Flow of complicated Sigil of AWS. He secretly draws power from a Fiendish Machine God called Linux. Furthermore, he is existed in this world before we all even exist, he is the one who maintains the SQL Databases to not meddle with the mortal world.
- The last member is Bob. Bob is a Technical Writer Bard. He is apparently useless in this fight. His spell is charisma-based. It won’t work against the dragon, but Bob is a good bullshitter. He can write API Documentation and Technical Manual just like a poetic edda. Bob is just fine, he can join the team.
The battle starts at dawn, The group plans ahead by scouting the designated System Architecture. Validating if they can pull and ambush on this dragon. The Warrior began to appear first, sounding the API Calls to lure the dragon. Its chased him down. Tim notch his arrow and releases a barrage of attacks in quick succession. The arrows barely scratch its thick scales. The warrior turns around preparing his sword, but the dragon flaps its wings and produce a massive wind that shoots Greg into the Deadline Wall.
They are running out of time, Sue sees her party unable to do anything. She decided to leap from the shadow and started to climb the dragon’s back. The red dragon thrashed around looking for someone to blame, but sue still maintains her grip. Until she eventually thrown up to the air and being swallowed by the dragon. On the inside, Sue manages to damage the dragon internal organs.
Make it reeling around in pain, but sue knew this is not the part of her job description. But sacrifices needed to be made. In the final push, Steve open a portal to the Outerplanes of AWS. Ship it away sealed within the prison of containerized image of a red dragon.
Bob, however he’s busy stealing drinks from the nearby tavern. He said that booze can help him to find a great story to tell to the kingdom authority, or simply the management. They lost Sue that day, she was swallowed by the red dragon and never be seen again after the incident.
The Question:
“Who unleashed The Red Dragon in the first place?”
The Answer:
“It was you, the Project Manager. The Dungeon Master.”
I will get a bit serious here, the project manager is almost like a Dungeon Master. The job is to weave stories and telling tales. That’s why its called “STORY POINTS” for a reason. The technical team doesn’t know what coming to them. The element of surprise and unpreparedness of the team can overwhelm even in the greatest of individuals.
⚔️ The Party of Adventurers
I like the idea of Dungeons and Dragons group. Its small, concise, reliable, and fairly easy to maintain. set your team around 3-8 people max. Its always the rule of thumb for me. The bigger the people, the bigger the cost to miscommunicate and harder to schedule an appointment or meetings.
🧙♂️ The Roles
Each player character will be given out roles. Whether it was damage dealing, magic, ranged attacks, etc. Some character is good at certain tasks, other can also be an all rounder that good at many things but probably not an expert. Same like in project management, knowing which individual is fit for carried out certain task. give them the worthy opponent which suitable for their playstyle.
for example, you need to know that the frontend is suitable to fight in styling CSS and create a responsive web pages. Otherwise the backend is suitable to fight in REST API and Microservices. But some people can also do both, but check their job description. Even if they can, doesn’t mean that they want to do it. Maybe the someone like Sue can handle Frontend and Backend really well, but that’s not her job, and maybe that’s take a toll on her and eventually quits from the team.
🧌 Scaling Up The Enemy Encounter
Maybe a Red Dragon is a bit much for level 3 character right? or we can set the encounter into smaller parts. First the goblins, then the ogres, scales up into the dragons. We can chop things around and sees how the team manage it. You should also needed to keep close eye on the team. Ask around what make the task so difficult, what can be evaluated on each sprints. What works with them and what didn’t work with them. Remember, the team is in the same boat for you. You are not with the company nor with the management, but you are here to tell a story.
🏹 Magic Items, Loot, and Treasure Chests
Let’s say that the team had multiple encounters before facing the dragons, you can see how the goblins might have treasure chests filled with magic items. It’s a common thing in D&D that players would get magic items, loot and treasure chests after completing an encounter.
Imagine that the magic items, loot, and treasure chests is a part of project milestone. For each small encounter that they tackle, it may help them to make the final boss to be much more easier. You also need to keep in mind that this small encounters is also a way to understand the viewpoints of the bigger problems before actually executing it.
🔮 The Game Rules
Probably many people will not agree in this. But in order to create a neatly woven story, you needed to understands the rules. Technical stuff, like concepts of API. What is a Framework, Databases, and different environments is basically easy to learn. You don’t need to master it, or became an expert, being able to know the concept is enough. Learn with your team about these things, ask them around how they created an OAUTH token just for your curiosity. Take a little bit of walk with your system architect and discuss how MVC works while enjoying a cup of coffee.
👩🚀 The Responsible Dungeon Master
Being a Dungeon Master is not an easy task, for those of you who create a D&D campaign might know this. Its sometimes comes with sacrifices; such as the time to ensure the miniatures is available, the story is easy to understand by the rest of the player, and so on. The Project manager will also have the similar fate. The management will push you around, telling the deadlines is near, but you also cannot blame the devs (unless if they are an as***le).
In D&D, plot can also suddenly changes. It’s mostly to many things. Lets pretend that the number business decisions is a number of dice rolls. Sometimes it is a successful or failed roll. Either way it can shifts in sudden changes. But you can never do anything about it. Accept that the management will always put the pressure on you because of you are the Project Manager.
The way you handle management expectation is also the challenge of project management. In the world full of KPI’s we often forget that it is also our job to communicate to the company management what is happening inside of the Team and what to expected from them.
P.S.
Yes, this is my late night thoughts. I don’t even proofread it very much. There’s gonna be grammatical errors. But, I decided not to care. This probably looks like I’m consuming a ton amount of mushrooms while writing this article. Also check out Matt Brunt talking about D&D and project management, its such a great talk.
Top comments (0)