The Game Masters Framework for Software (GeMs)

~A thought experiment for products in a complex or chaotic environment~

This entire article is a thought experiment describing how we can fuse Agile, Lean, or other ideas such as game mechanisms from Role-Playing Game (RPG) into a framework. Why on earth would you do this, you might ask? First, it is fun. Secondly, it helps focus on "the why." If you do, the result might be a "pimped" framework suited for your unique situation and context.

Because organizations are unique and deserve their own touch.

A beginning

Picture from Stefan Keller

The GameMaster Framework for Software (GeMs) promotes existing "gaming" generation skills and combines that knowledge into an Agile business context. It is time for a generation being experts in coordination, leadership, and collaboration from playing online RPGs to change how companies work.

Starting point

Imagine you work at Acme Inc. Your primary business is a web application launched some time ago. You have many ideas for the next feature, 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 to test a hypothesis that could bring value and revenue. You base the investment on risk appetite and how much the company is willing to pay to test the theory.

The team is given the briefing and conditions by the Game Master (GM) Joe. Joe follows the custom checklist in GeMs to ensure everyone understands the scenario. The organization agreed on the prerequisites in the list, such as stakeholder mapping and a hypothesis. Further, it is crucial to have a team with the necessary skills.

The GM secures time from Non-Player Character's on which the team has dependencies. Before starting the mission, the GM 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 discusses how best to complete the scenario within the time box. They have decided to use timeboxes as the company allocates funds every quarter, and the economists want to have "control." They decide that the UX will start by talking to end-users to show mock-ups and see if the proposed feature is valuable. The developer 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 work progresses, the team will encounter unexpected problems. The Game master will help the team handle problems outside the team's zone of control.

After three weeks (or after reaching goals), the team will have a briefing to evaluate progress and verify the hypothesis. If the assumption was correct, the team might continue completing more scenarios (a campaign). If the team produced nothing of value, the company might not invest more time and money. Instead, let's focus on something of more importance.

The described scenario follows mechanics straightforward to use:

1. Create a scenario with a hypothesis
2. Decide how much time and money to invest
3. Select a team with the right skills to solve the problem
4. The team works on the hypothesis for a fixed period
5. Measure and evaluate
6. Goto 1

Does this all seem very abstract? Read how the first day at work might be for a new adventurer :)

So how do you go about creating great software using RPG ideas?

Form a band of heroes

Imagine a goal worthy of pursuit where funds are secured. The first step is to form a band of heroes participating in the scenario.

To start a scenario, you will need a team of adventurers. You will find them in your organization or as consultants. What is essential is that the band has all the necessary skills to test a hypothesis with as few external dependencies as possible.

When forming a band, you want to think of:

1. Career class
2. Skills
3. Alignment

Career class

Career classes refer to the profession of a band member. A more experienced person will have better skills. Based on her level, you can understand how skilled the person is.

When forming a team, think of the scenario you need to finish and create a multi-skilled team to complete the goals. You might need to add persons having unique skills or knowledge.

Skills

Band members must have the right skills to complete the scenario. Putting together the right team is crucial to success. Sometimes the team sticks together for a long time conducting several campaigns. When different skills are needed, the team might "borrow" a skilled adventurer from another band or a consultant. In other cases, the organization might put a band of heroes together to complete a quest.

If the team lacks some core competency, Beware, the band might not complete the scenario or prove the hypothesis. Maybe the team did not enlist the services of a UX researcher. Perhaps delivery was not possible as the team did not have a DevOps skilled in continuous integration.

Alignment

Putting people with the right skills together doesn't necessarily create a winning team. It would be best to have a team with various character traits. Some people are naturally more easygoing and extroverted. Others do hard work in silence and don't need all that chit-chat.

Navigating in the real world requires persons with different alignments. A team consisting of introverted, conflict-averse persons might have problems asking the right questions. A team with only visionary persons without doers might have great ideas but never fulfill them.

Be aware of your team members' alignment. Use your team's strengths and weaknesses as best as you can. Decide if you are a protagonist, diplomat, adventurer, or entertainer. Or something else. There are plenty of models to use.

That's it. Hopefully, you will put together an autonomous self-managing team that can work together. And now it is time to decide who should be the GameMaster.

Picture from Stefan Keller

What a GameMaster does

The GameMaster runs the game and helps the band to navigate through the scenario. The team will encounter many challenges trying to deliver value to the customer. The GM's task is to guide the team through these challenges, helping them decide the right action. Not by telling them what to do but by being their eyes, so the team can act on that information. You are storytelling!

The players will often demand information about their surroundings. Who can I talk to about this, or who is the manager of Bob? When can we expect to have a new laptop for Sam etc.? What are we supposed to build, and for whom? Most of the time, a GM doesn't have the answers to their questions but will have to improvise and find your way.

There might be a need to navigate political landscapes and bureaucratic processes to help the team. The GM's primary role is to ensure that the team has an even flow and focuses on creating value for the end-user.

The GameMaster must be one step ahead, anticipating what the team will need next to ensure flow.

Picture from Stefan Keller

What a Game master ensures before starting a Scenario

A scenario has specific actors, set time, and happens within a particular space. To complete it, the band must reach the goal. If not, the scenario will fail.

Before you can start a scenario, there are several things the GameMaster must ensure are in place:

1. Budget. Secure buy-in and the go-ahead from sponsors to start the scenario.
2. The context. A story to tell the band of heroes, explain who they might interact with, the hypothesis, and goals of the scenario.
3. Secure a band of heroes with the necessary prerequisites and skills to finish the plot. For example, the right software, constellation, equipment, post-its, whiteboards, and can focus 100% on the scenario.
4. Stakeholders. It would help make sure Non-Player Characters (NPC's) are available and understand their role in the scenario. Ensure that they show up at the right time and interact with the players; this is very important as some NPC's can have crucial information or need to perform a task to complete the scenario successfully. For example, an NPC setting up a test environment at the right time.
5. Research. Are there any prerequisites or material that the team needs to read up on before starting the scenario? If the team uses new technology first, it might help spend two days fooling around. If there are intricate business rules or domain knowledge needed, maybe they need to talk to major NPC's, read manuals or have a workshop.
6. Any deadlines or risks? If so, this has to be communicated clearly to the team. They should do risk assessments and mitigation plans. Or a plan A and B and C.
7. Decide on the number of Experience Points and communicate what action or task gives how many experience points.

How long should a scenario be, you might ask? That is up to many factors such as risk appetite, time constraints, money, and more. Basically, how long is a rope?

However, if a scenario becomes very large where the number of experience points the team can get is in the thousands, you probably have a campaign. Break the large plot into several scenarios and call it a campaign. You might also wish to take this path if several teams strive towards a common goal—a horde of adventurers.

How to imagine a Scenario

Think of it as a movie with scenes. A movie consists of many scenes that help bring the story forward. The same thing with a scenario; some are longer, some are shorter.

As in any good story, a team fully commits. Being an adventurer in a tale is a full-time job. Have you ever read a story where the main characters perform other tasks simultaneously? That means all team members work 100% on the scenario.

Again, think of it as a story in a movie. It would be pretty dull to watch a scene where the main characters go into a bank, and you have to watch them wait in a queue for fifteen minutes. That would both be boring for characters in the movie and those watching the movie. And as a movie usually is roughly 90 minutes, it would be approximately 17% of the film. Not to say how costly it is to have the team waiting before moving on.

As with any situation where you deal with people, they do unexpected things. They will, of course, take actions no one imagined. When this happens, you will have to improvise. Don't worry; this will be second nature to you after a few scenarios.

Ending a scenario

A scenario ends when all the scenario goals are complete or you run out of time. The goal is to create value for the adventurers and the end-users. If you are running a campaign, the goals should contribute towards the campaign goal. So choose your objects wisely.

When ending the scenario, all members gather and go through their actions; the GameMaster distributes experience points, and if anyone has reached a new level, you all celebrate.

The sponsors are informed and decide whether to continue on the scenario or focus on something else depending on the outcome.

While the GameMaster prepares for the following scenario, the band might wish to read up on the latest and greatest or stay on alert monitoring or refactoring. Or revisit what went well or not so great in the previous scenario.

Picture from Stefan Keller

Game mechanics

There are a few game mechanics that GeM uses, such as

• Experience points
• Handling NPC's
• Team Setup

Experience Points

As you practice and study, you get better at what you do. You gain experience. You can't see how much experience a person has in real life.

In the Game Master Framework, you get experience points (XP) after completing tasks in a scenario. When you reach enough experience points, you get a new title:)

For example, when the automation wizard has reached 1501 experience points, he is at level two and can call himself "I am Sam, the adept automation wizard."

Experience Points is really about having fun. But also because our brain works well with rewards, this can promote the correct behavior. It feels great to say that you are Fredrik, the hero GameMaster, for example.

The amount of experience shows how many scenarios a person has completed, how much the person has helped others in the team, and time spent learning. Members get XP for completed actions assisting the team to become better or creating value for the end-user.

Players gain Experience Points at the end of the scenario by the GameMaster.

For example:

The Gamemaster asks, "Tom, how many code reviews did you actively participate in?".

"Umm, let's see. I participated in three, but I had not prepared myself for one of the reviews and had no comment to give. I still learned some though listening to Ann explaining why she used interfaces." answered Tom.

"Ok, I will give you half the XP for the last one. So in total 250 XP for code reviews."

For more examples of setting experience points, see the sample scenario at The GameMasters framework site.

Handling Non-player Characters

Non-player characters (NPC's) are stakeholders, domain experts, or any other person the team can and will encounter during the scenario. There are many tools and practices on best interacting with NPC's. Stakeholder maps are one example.

You can create a stakeholder map to see dependencies and know who to contact or keep informed.

Below is a sample stakeholder map. Just write down all persons you can think of outside the team and then place them in the correct quadrant.

Inform, make contact, and book meetings as needed to ensure you have the support you need.

To put it very simply, the team can very seldom handle everything without interacting with the outside world. The stakeholder map can help you understand who you need to keep satisfied, informed, or engaged.

Team setup

In Role-Playing, a team usually sits in one room with a Game Master in front of a table.

How teams sit together and how many people are in the team influence how easy it is to communicate and how much overhead there will be. Each person added to a team increases the number of communication channels and the overhead.

The engagement and interactivity in a meeting decrease for each person added. When more than (roughly) six people meet, people begin to zoom out and stop being active. Try to keep teams as small as possible but make sure you have all the required skills. Physical location affects communication.

If possible, the recommended setup is for a band of heroes to sit in a room of their own so that they can listen to their music, write on the walls and leave their stuff on their desks (no clean desk policy here). Think war room. Below is an example of how to put together a team. An added benefit is that you can also use the space to play real RPGs after a day of work ;)

The team sits together with the GM at the far end. A circular table with whiteboards on the walls to brainstorm or discuss ideas with NPC's.

Picture from Stefan Keller

When can you use GeMs?

GeMs works in the intersection between Chaos and complexity in the Cynefin Framework. Creating software in this intersection is unpredictable and full of variations without clear causality. Meaning you can't predict how long it will take to complete a product or do proper estimates. It is a discovery process where you always act and react.

How can you get reliability, predictability, and numbers in this intersection? How can you know that all the money they spend gives a return on investment?

An excellent approach to minimizing uncertainty is identifying the problem, creating a hypothesis, experimenting, and evaluating. The scientific method:

Illustration from Robert T Hanlon

You try and try and see what works, and then you use what works. The shorter the cycles are, the faster you fail, the quicker you will be wiser. If you have the budget, why not work on multiple hypotheses simultaneously?

Work order

1. Form a hypothesis of how you can solve a problem.
2. Decide how much time you wish to spend on the hypothesis
3. Assign a band of programmers to complete the scenario.
4. Measure progress.

Picture from Stefan Keller

Techniques and practices

Bands of adventurers operate in their little microcosmos where different policies, principles, ethics, conditions, and values rule. Thus, the rules that apply to one team will not apply to another band, even within the same organization. Even within the same department, things can differ depending upon the manager, your budget, and your work's criticality.

Therefore, there is no golden bullet about setting up or completing a scenario successfully or which tools or practices to use. If there were, we would all do it the same way all the time. There would not be so many frameworks and project methods.

You and your team must analyze the world you work and live in, use your creativity and problem-solving skills to navigate this world best, and deliver something of value to the end-user. That can involve politics, making alliances, building a network, changing tools, improving processes, reducing bureaucracy, looking at sociological and psychological factors, and much more. Take a breath and look at what is most important for the team to deliver. Think of it as having an empty container that you can fill with what suits you.

Your organization has often decided what to use — then you need to adapt and see how you can incorporate existing policies and rules into your reality in the best way possible.