Corrado De Sanctis has generously given Ludogogy permission to re-publish this article. The original article can be viewed at his Agile games site
As many of you already know, I work as an Agile Coach for a large organisation, and I am a creator of agile serious games. In fact, I deeply believe that playing a game can be often more effective than a classical lecture or presentation, particularly when we are talking about a soft skill (which an agile mindset definitely is).
Creating games is also a way to apply the agile approach in different contexts. If you are thinking if agile is just for IT, you are wrong!
I already successfully applied agile in marketing, HR, finance and, obviously, in game creation. If you are wondering 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 write 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 sections one practice directly derived from agile practices, showing also a specific real example.
Keep in mind, that today, there are 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 a mechanic and is not really effective.
To help in this r-evolution Agile Game Factory is working on a specific game on the connection between Mindset/Principles/Practices in agile. Stay tuned!.
Update : You can see this game in action in Corrado’s live playsession of The Agile Mind
Designing a game
When you start designing a new game you have to 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 the Product Vision Board by Roman Pichler and is adapted to the specific context of game design.
This canvas is composed by 5 areas where creators can put main the attributes of the game and, at the end, the Vision statement that will guide them in all decisions. These attributes are:
1) TARGET: who are the 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 designers on a possible new game about 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 had an open conversation, but the canvas gave us a few rules and helped us to have a well-defined outcome to be used in the future.
Building a game
To build a game you can use Kanban or Scrum. These are the most used agile frameworks which are also PERFECT for gaming. First, you have to identify the parts of the game to build; then organise them into small pieces and prioritise them. Later you can build starting from the most relevant piece. Prioritisation is very important because this lets 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 your game.
Note that you can use this approach also for more complex activities like designing a mechanic or writing an instruction manual / rulebook. 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, I am currently working together with a team of six people distributed 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 has “cards” that represent activities, mostly directly related to the players’ experience.
Improving a game
To understand if a game is working or maybe how you could improve it, you need to collect feedback.
Feedback is one of the core attributes of the agile mindset and, for a game, comes mainly in two modes: from play-testers and from actual players.
To collect feedback for a game, I have created a dedicated model called TARGET from the initial letters of the six dimensions:
• Theme: Is the theme enjoyable and close to reality? Is information on which the game is based realistic? Is the goal of the game consistent with the theme?
• Aesthetics: How are the materials of the game? How is the iconography of the artefacts? What about readability of the information (cards, rulebook,…)?
• Replay-ability: How can knowledge of the game change the game experience? How many variants can you play? How many player combinations can be used?
• Game length: Is the game length consistent with theme? Are there some moments where some players are only watching? Is the flow of the mechanic fluent or start & stop?
• Ease of play: Are rules clear and straightforward? Are there some weird exceptions to normal flow? Is there support to explain the game?
• Tactics & strategy: What is the role of luck? Can players 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 open text to ask the players how you might 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 how impactful feedback from real players can be.
Final thoughts
Sometimes, you may want to check if a hypothesis can work in a multi-layer context.
I can show an example strongly related to this connection between agile and games. At the moment, I am working in agile on a agile serious game on the core concepts of the agile mindset. This is a three-time spiralling logic and it is probably a tough use case to check an idea. however apparently it is working. So the final thought is that agile works.
“To help people, teams and organisation in their agile journey”
- Applying Agile Practices to Create an Agile Serious Game - 24th September 2021
- Pizza KATA IIRetrospect is a Mindset and Not an Action - 8th July 2021
- Pizza KATA or “Change is a Mindset and not an Action” - 14th May 2021
Be the first to comment