Key Takeaways
- GeMs combines ideas from the agile world with skills, terminology, and familiar ways of working for the gaming generation
- The framework targets solving problems and reducing the risk in complex situations closer to chaos than being complicated.
- The framework describes which actions to take to move from an idea to something of value in a short period of time where predictability is low using a structured approach based on well-proven ideas.
- GeMs hopes to fill a gap where traditional project approaches or estimates are less efficient, where practices are emergent or novel, basically, in situations where you hardly know where to begin, where you have to experiment or just do.
Are you a software nerd who likes role-playing games?
Have you ever wondered how your skills from playing Warhammer, WoW, Dungeons & Dragons, Cthulhu could be applied in the software industry? Have you ever thought about combining gaming tactics with software creation? The GameMaster Framework for Software (GeMs) builds on existing skills such as coordination, leadership, and collaboration that the “gaming” generations already have and incorporates that knowledge into an agile business context.
Why GeMs?
The Game Master Framework for Software (GeMs) uses the fundamentals of Role-playing games and applies them to Software development, effectively creating yet another framework that can deliver software. At the end of the article, we will discuss geMs from a business perspective.
GeMs is an alternative to other agile frameworks. Often, practitioners wonder, “are we doing this according to the rules” instead of focusing on relentlessly becoming better. GeMs show that agility can come in many shapes and flavors. Frameworks are a starting point, and you can start at different locations. This framework is a starting point. You should make it your own.
The framework is not a one-size-fits-all, but it can be beneficial for some, especially for new products in complex environments having a handful of teams.
Why the name “Game”?
In most cases, working software is not the work of a single person working alone. Delivering software requires teamwork and coordination across team members with skills and abilities combined that make the total more than each individual. Skills and abilities are needed to provide something valuable.
In addition to having the right people, you also need standard rules on how to “play” the game of software delivery. That includes how to work in a team and interact with the world outside yourself.
There can be cooperative games and competitive games. To play a game, everyone must understand the rules for the game to be enjoyable. You might, of course, cheat and break the rules. That, however, will most likely end in anger, frustration, and chaos. The result is that no one wishes to play with you.
The name “game” might sound strange at first, but actually, there are many similarities in how you create software and how to play a game, whether it be online or as a role-playing game. You can use the skills you have from playing games to create games.
An example
Imagine you work at Acme Inc. Your primary business is a web application launched some time ago. You have lots of ideas of what the next feature should be, but you are uncertain what brings the most value to customers. Your budget has limits. You have a few great software teams.
You have agreed to invest one team’s time for three weeks in hypothesis Zed. The investment is based on risk appetite and a calculation of how much the company is willing to invest in testing the hypothesis.
The Gamemaster Joe is given the briefing and conditions. Joe follows the checklist in GeMs on creating a scenario to make sure enough is prepared to avoid chaos but not in too many details to be inflexible. In Roleplaying, the characteristic of a great GameMaster is to be able to improvise. The checklist verifies that a stakeholder mapping exists, adding OKRs based on the hypothesis, ensuring the team has the necessary skills, and securing time from NPC’s to which the team has dependencies. Joe decides on the number of experience points the scenario is worth.
Joe gathers the team and briefs on the scenario, including goals, NPC’s, experience points, dates, and significant stakeholders.
The team huddles and begins to discuss the best way to complete the scenario within the time box. For example, they decide that the UX Wiz will start by talking to end-users to show mock-ups and see if the proposed feature is valuable. The developer warriors will speak with a domain sage to understand business rules or legal aspects. The team will work on a list of possible security concerns and use case diagrams simultaneously. And so on.
As the scenario progresses, the team will encounter unexpected problems. Problems outside the team’s zone of control the Game master will try to handle.
After three weeks (or after reaching goals), the team will have a briefing to evaluate progress and verify the hypothesis. If the hypothesis is correct, the team might continue completing more scenarios (a campaign). If the team produced nothing of value, the company could choose not to invest more time and money and pursue something more valuable.
What makes GeMs work?
GeMs uses well-proven mechanisms to help create a software product of value in complex environments using hypothesis and a probe-sense-respond approach.
Did that sound complicated? Well, think of it this way. To deliver something of value, a team of players gathers together to reach a goal. The team has the right skills, competencies, and personalities to complete the scenario. Each team member’s alignment is taken into account to make sure the team complements each other.
Scenarios are game-mastered by a Gamemaster whose primary role is to guide the team through the scenario. The team plays the scenario and completes it by meeting the pre-determined goals. Persons outside the team are called Non-player characters (NPC’s). Before starting a scenario, you identify important NPC’s. The team interacts as necessary with NPC’s during a scenario.
The game master prepares “enough” before starting a scenario. That includes talking or informing NPC’s, align goals with company strategy, and more.
As a team progresses and completes scenarios, players will gain experience and level up. Do you want to be a champion? Well, play the game, get the experience points enough to title yourself “Champion.” Do you wish to lead a team? Be a GameMaster.
Think of GeMs as how a fantasy book or movie works. You have a band of adventurers who come together because they have a mission or quest they need to complete. As in a story, the team exhibits proper group dynamics. Combined, the team can do wonders, but alone, they can’t survive.
In GeMs, you put together a team with the right skills to complete a scenario. You can be a warrior developer, DevOps wiz, Software sage, or any other career class. Scenarios have villains and protagonists so beware of some career classes such as the necromancer. When encountered, you must be careful. Goals are appealing and valuable, and flow throughout each scene is vital.
Before starting a scenario, the team will huddle and decide how to achieve the scenario goals. They will then work their way through the scenario in the way they find best. As in any game or book, the players decide what action they will take. The GM describes the world to them with as much detail and knowledge as needed or possible for them to make the best possible choice under the circumstances.
After each scenario, the Game master and the team will sit together and go through what happened. Each player will get experience points for completing goals and activities such as doing a code review or helping someone else who had a blocker. Experience points will, well, show how experienced you are and also give you a fancy title.
Picture from Stefan Keller
Is this fantasy, or can this work?
The framework applies concepts from “the agile manifesto” and “the declaration of interdependence”—principles proven in Scrum, Crystal clear, and other solid agile frameworks.
GeMs work best in complex environments where prediction is hard. Where analysis and estimates usually are wrong. The game uses mechanisms to reduce risk and costs. Conversely, there are no estimates: only goals, fixed time, and frequent inspection.
GeMs is open enough to add any other process that is already used successfully in your organization. From the idea of history, history shows that most ideas work as long as they are coherent and used in the right environment. Good ideas seldom die; they come back with a different name. Why not re-use what works rather than inventing the wheel again and again.
GeMs also tries to correct the mental model of Software progression. Software is connotated to a terminology not suitable for how to create solutions. The result is that we apply approaches less ideal for software creation. The words we use give us the wrong mental model. Most models work as long as they are coherent. They can be more or less suitable, though.
For example, the use of the term “building software” is misleading. Building a house or a bridge is too often mass-production where you have an engineered product…“Progression of software” is a better term. Or the confusion that software development is “engineered.” To engineer something is a discovery process that takes time and requires experimentation. Once engineered, the software product works predictably (hopefully). The outcome of software engineering is an engineered product, a software product that can be reproduced and sold. Progression of software requires engineering.
The path to creating a new software product is often unknown and unpredictable. GeMs acknowledges this by introducing scenarios where you have goals to complete. You reduce financial risk by timeboxed scenarios having limited budgets.
The biggest differentiator is that GeMs borrow from role-playing games. Believe it or not, role-playing games follow agile principles exceptionally well. And many persons are already exceptionally good at gaming and motivated to use those skills.
Principles
GeMs have straightforward principles. First, understand the rules, the scenario, and the player limitations. Next, good leadership and training will be a deciding factor as each game you play will be different and provide various challenges.
The progression of software has similarities to chess; the variations are almost endless. In chess, the environment is well known with the board and the pawns. As in chess, a game doesn’t play out the same way every time; chess has too many parameters, changing the possible outcome after each move. To get good, you need actual practice. You need the experience to master the game.
In GeMs, this is the fundamental axiom for game mechanics. As with football, the rules are easy to understand, but it is not until you get on the field that you get the skills. In the framework, players gain experience points when they complete scenarios to show progress.
The goal of the game
The goal of the game is to deliver valuable, working products. To do that, the players will work together, led by a GameMaster (GM) responsible for creating scenarios and keeping the team on the right track.
It is the Game Master’s task to run the game. The GM is a person who acts as an organizer, officiant regarding rules, arbitrator, and moderator for a team to help the players work together towards common goals in a scenario. The GM prepares a scenario. The players will complete the scenario with the GM’s help creating an environment in which the players can interact, work together, and deliver working solutions. The GM creates a “flow” for the players through a scenario to focus their time on valuable activities.
The scenarios take place in the real world, where strange and unforeseen things happen. Where the end-users are actual and dependent on our result, sometimes we will encounter villains and unexpected obstacles in our path blocking us from reaching our goals. Players will have to use their skills, wit and work as a team to overcome these obstacles. There will be excitement and challenges ahead, just as in a role-playing game.
GeMs from a business perspective
We are all children of our time. Each generation behaves differently based upon what society looked when they grew up. In the eighties and nineties, role-playing games such as Dungeons and Dragons were popular. The generations from 2000 and forward have grown up with online gaming playing Dungeons and Dragons (and other fantastic games, of course).
These generations have created their unique cooperation and communication methods that have allowed them to play together, showing outstanding coordination and results. Very many of these persons work in the IT industry or will work there very soon.
A person from these generations going to work today has to re-learn hierarchy, project methods, agile dogma, etc.
Why not let this generation do what they are great at already, work in a way they know, and use the skills the new generation already has?
Let them bring the skills they have honed for years to work. That is where GeMs come in. Using terminology and ways of working that this generation already knows, they already have the necessary skills and can work directly. They will recognize the framework and can use their existing skills.
Time to market
A critical principle in the framework is Aristotle's scientific method. A well-known method for a thousand-year, used by many companies today, where successful hypotheses and quick feedback loops are vital to surviving as a business. This principle is very much the basis for all agile frameworks and other industries as well.
The actual cost and source of frustration is usually not the real-time spent working. Time thieves are hand-overs and waiting for other persons to complete work. How much will it cost each month that we do not have our product available to customers? How much income could we have had while waiting for the software to be ready? The pharmaceutical business is hugely aware of this. They both need to be first on the market and only have five years to register the product until other competitors can make copies. The cost of waiting here is expensive. Time to market is crucial.
With all the necessary skills, having a team working together means a faster time to market Yummy. It is also great for a team to control their goals and take pride in delivering something valuable fast.
You control Risk by approving a scenario, testing a hypothesis using Objective Key Results. You regularly verify the value of what you do and take decisions based on progress against the value produced.
Takeaway
GeMs combines ideas from the agile world with skills, terminology, and familiar ways of working for the gaming generation—the framework targets solving problems and reducing the risk in complex situations closer to chaos than being complicated.
The framework describes which actions to take to move from an idea to something of value in a short period of time where predictability is low using a structured approach based on well-proven ideas.
GeMs hopes to fill a gap where traditional project approaches or estimates are less efficient, where practices are emergent or novel, basically, in situations where you hardly know where to begin, where you have to experiment or just do.
Does this sound inspiring, weird, or downright confusing? Why not invest an hour in reading the Game Masters Framework for Software? I hope that at least it will awaken some thoughts or new ideas. Maybe you are even crazy enough to try it?
Picture from Stefan Keller
About the author
Fredrik Carleson, an agilist, philosopher-hobbyist, tabletop player, and software nerd, has helped deliver software for private companies, governmental and United Nations for the last twenty years in Europe and South-East Asia. Since childhood, his interest in games and philosophy, combined with various ways to deliver software, has begun to converge coherent thoughts of how it all fits together. Fredrik believes methods and frameworks come and go, but good ideas are eternal; we just change the names.