As many of you already know I am working as Agile Coach for a large organisation, and I am a creator of agile serious games. In fact I deeply think playing a game can be often more effective than a classical lecture or presentation, in particular when we are talking about soft skill (and agile mindset definitely is).
Creating games is also a way to apply in different context the agile approach that I is winning for more serious products. If you are wondering if agile is just for IT, you are wrong!
I successfully already applied agile in marketing, HR, finance and, obviously, in game creation.

If you are asking what agile is, this is too long to summarise here. Just to give a clue, agile is a way of building great products in uncertain scenarios: based on values, principles and practices this successful (and fun) way of working requires a different mindset and this is why you (or your company) need coaching (and not training). For more details google is your friend, on the web you can find zillion of articles, or maybe you can follow me on linkedin because I often wrote article on agile topics.

In this article I will try to describe the process of creating a game, using agile. In the next three chapters I will introduce a basic agile process (Design, Build, Improve) and I will present in each of the chapters one practice directly derived from agile ones showing also a specific real example.
Keep in mind that today there hundreds of agile practices, and very probably all of them could fit in your work. However remember that applying a practice without the proper mindset (values and principles) is only mechanic and not really effective.

To help in this r-evolution Agile Game Factory is working on a specific game on the connection among Mindset/Principles/Practices in agile. Stay tuned!.

Designing a game

When you start designing a new game you have keep in mind very clearly WHY you are building the game. To help in this process I have developed a Game Vision Board. This is directly derived from Product Vision Board by Roman Pichler and adapted to specific context of game design.
This canvas is composed by 5 areas where creators put main attributes of the game and, at the end, the Vision statement that will guide in all decisions. These attributes are:
1) TARGET: who are players? (think of personas, how many, interactions, …)
2) NEEDS: why players want to play it? (think of what is motivating players to play it)
3) FEATURE: what makes the game stand out? (think of unique/new and imported/improved mechanics, components,… you would like to have)
4) GOAL: why this is useful for us? (think of what is motivating us to build it)
4+) How do we MEASURE success? (think of some metrics and how to measure them)
5) VISION in a sentence (think of a tweet)

FOR EXAMPLE recently I worked with a team of serious game designer about a possible new game on sustainability. We spent a couple of sessions to understand and share our ideas around this game and we put everything in the canvas below

Clearly we could have a open conversation, but the canvas give us few rules and help us to have an well defined outcome to be used in future.

Building a game

To build a game you can use Kanban or Scrum. These are the most used agile frameworks that are PERFECT also for gaming. First you have to identify the parts of the game to build, then organise them is small pieces and prioritise them, later you can build starting from the most relevant. Prioritisation is very important because this let you create MVPs (Minimal Viable Product) of the game at different levels and test them following an iterative and incremental approach, collecting more and more information around you game.
Note that you can use this approach also for more complex activities like design a mechanic or write a narrative manual. Furthermore, the fact that you have designed the game starting with a vision, helps you to keep the right direction. Finally agile frameworks are great if you are working alone, but they are much better if you are a team.

FOR EXAMPLE in these months I am working together with a team of 6 people distributes across Europe to build a new narrative RPG. The image below is a section of the scrum board

The board is a visualisation of the process to build stuff and each stage have “cards” that represent activities, most of them are directly related to the players’ experience.

Improving a game

To understand if a game is working or maybe how you could improve, you need to collect feedback.
Feedback is one of the core attribute of the agile mindset and, for a game, comes mainly in two modes: from play-testers and from actual players.

To collect feedback of a game I have created a dedicated model called TARGET from the initial letters of the 6 dimensions:

• Theme: Is the theme enjoyable and close to reality? Are information on which game is based on realistic? Is the goal of the game consistent with the theme?
• Aesthetics: How is material in the game? How is the iconography of the artefacts? What about readability of the information (cards, rulebook,…)?
• Replay-ability: How your knowledge of the game can change the game experience? How many variants you can play? How many players combination?
• Game length: Is game length consistent with theme? Are there some moments where some player is only watching? Is the flow of the mechanic fluent or start&stop?
• Easy of play: Are rules clear and straightforward? Are there some weird exceptions to normal flow? Are there support to explain the game?
• Tactics & strategy: What is the role of luck? Can player predict, monitor and control different phases of the games? Are players able to adopt different working behaviours?

Note. The TARGET model has been presented in this article.

You can measure each of these with a score 1 to 5 (or stars) and with an open text to ask to the player how to improve the actual score.

As you can imagine this can be easily automated using an online form.

FOR EXAMPLE at the following link you can find the google form I have created for Agile Game Factory’s customers.

Here a link to an article showing an example on how impacting could be the feedback from real players.

Final thoughts

Sometime you want to check if an hypothesis can work in a multi-layer context.
Well I can bring an example strongly related to this connection between agile and games: in these weeks I am working in agile on a agile serious game on core concept of the agile mindset. This is a 3 times spiralling logic and it is probably a tough case to check an idea, however apparently it is working. So the final thought is that agile works.