Roleplaying games, the kind you play using odd shaped dice sat around a table with friends, are about three things. You play a role, usually a dramatic heroine or hero, you are part of a story and you overcome challenges together achieve some goal. Software development is also best done sat in groups, with people you like. It’s also about overcoming challenges to achieve a group goal, and often each person in the team has a particular role to play.
Diversity
The most famous RPG is Dungeons and Dragon, in which a party of adventurers explore Tolkienesque worlds fighting foes and finding treasure. The secret to a successful adventuring party is diversity and the same is true for development teams. If everyone in your team has the same background, the same experiences and outlook they’ll tend to solve problems in singular way and make software for people like themselves. An adventuring party made of just dwarven warriors might find it easy to fight their way through hordes of orcs, but without a cunning thief who will pick the lock to the impenetrable doors that guard the dragon’s treasure? Better to have a diverse team and end up with software that has been thought through by people of different backgrounds, genders and cultures, teams who won’t get snagged by issues that come from a single perspective.
Leading
Roleplaying games require a Game Master, sometimes called a Dungeon Master. This is the person who has the story their head, who frames the challenges and who plays the parts of the other characters in the story. It’s like a Scrum Master and Product Owner in one. The worst kind of Dungeon Master is one who ‘railroads’ the players. Rather than encouraging the players to figure out how to proceed, they tell the players what to do and railroad them into a particular course of action. This isn’t much fun for the players and rarely goes to plan as the Dungeon Master can’t think of every turn beforehand. It’s not playing to the strength of the game. The same is true for software development. When you’ve hired a talented group of developers, testers, product owners and sys ops don’t tell them as a manager what to do. Tell them what is required, and let them get there themselves. If they wander off from the user story, guide them back to it by reminding them of the features needed.
Resource planning
A big part of roleplaying is essentially resource management. Players worry about how many spells they can cast, how many gold coins it costs to buy that magic axe or how many sips they have left in their potion of healing. Eventually it becomes risk management. Trolls have hidden enough gold to buy the magic axe and a bunch of healing potions, but the fight might be so tough that characters could be defeated. Perhaps it’s better to face the orcs first and use the little treasure they have to buy a single healing potion so that they have a better chance of defeating the trolls. Or maybe they should try and sneak in and steal the treasure instead.
Software team’s dilemma is how to divide the work up between them. It’s rare that there are enough programmers, let alone QA to work on all the ideas the company has at once. It helps to think of resource planning in terms of risk management. Is it possible to take a small step that brings in some value rather than rushing into a big long project without knowing it’ll be successful? This of course is a fundamental principle in Agile software development, but incremental gains work just as well in D&D as it does in product development. When you don’t have quite enough QA engineers to give you complete coverage, do you risk reducing coverage or match the pace of development with that of testing? It depends on how valuable and risky the project is. Orcs or Trolls? Silver pieces or gold?
Experience
As characters gain in experience in roleplaying games they also gain in power, and more interestingly options. A freshly made wizard can recite a single and low powered spell once per day but as they gain in experience, and go up in levels their titles and options change. An experienced Enchanter can change shape, go invisible, befriend monsters, throw fireballs. They can also build magical towers that aid their spells and train apprentices to do their lesser magic.
The same is true in a way of developers, both in terms of technical and product experience. When they start out they are often given very specific jobs to do that aren’t very complex. As time goes on they learn more about best practice and the way their software is used. The variety of problems they can solve increases, but additionally and vitally the creativity they can bring to bear on product development also improves. Senior team members should be building wizard’s towers and training apprentices.
No More Heroes
There is one area where software development shouldn’t be like RPGs. In Dungeons and Dragons the heros and heroines grow in power and become superheroes, saviours, invincible and invaluable.
When you have heroes in a software development team it can cause all manner of problems. These are the people who stay late, who can seemingly solve any problem, who will avoid all the process and management layers to get things done. The trouble is they never look back, they rarely leave behind code that others can work with in their quest to get things done and disrupt the workflow of others because of their sudden needs for unplanned QA or releases. The set expectations that others can’t meet, hoard knowledge and avoid helping others. While the hero mentality is noble, and not to be squandered, it is better to show them why teamwork is finally more productive and desirable that wearing spandex and a mask.
