This game is intended not only for Agile coaches, but for people who may be new to Agile, and looks at the main concepts through the lens of a SWOT analysis.

Show & Tell videos will all accumulate at the Show & Tell Page as they are published. If you want to find out more about Corrado, and the other great games he has created, visit the Agile Game Factory.

If you would like to appear in a Show & Tell episode, get in touch at info@ludogogy.co.uk

The post Agile SWOT – A Game to Introduce Agile first appeared on Ludogogy.

I love everything about this show, from the storylines, through the uncompromising female characters (especially the totally wonderful Erica), to the game that we who were there (in the 80s) can play, spotting the numerous visual references to films and TV from the era. School corridors shot from the same angle and with the same lighting as Nightmare on Elm Street, Teen Wolf basketball moments etc.

But what I love most of all is reliving my early monster-slaying days – not in the Upside Down, but on numerous kitchen tables and student bedsit floors. I even remember playing a few adventures featuring a Demogorgon, which as any schoolchild knows (if they have a copy of the Monster Manual, or the Deities and Demigods cyclopedia), is a Demon Lord from the Abyss, worshipped by the Ixitxachitl.

The Deities and Demigods cyclopedia is available on Amazon

And the stats mattered… so much. Even when not playing, there were deep discussions about all the numbers. Adventures were remembered and analysed not just as pieces of narrative, but as mathematical representations of an experience. Did this encounter yield too many (or too few) XP? Is that piece of equipment or spell over-powered? Should I distribute points to my character attributes differently to get the best from my character?

I still play, we I can find the time myself, and more importantly, when I can find others who also have the time (and inclination) to play a campaign. Like many adults who have an RPG past, I’ve tried the (easier) option of joining MMORPGs like World of Warcraft, but it’s not the same. Someone else has created the experience for me, and I am more a consumer than a creator. I want to feel the D20 in my hand, and experience the thrill of creating a story with others around a table while quaffing mead (or Thunderbird – being the closest proxy which the local beer-off could provide).

While D&D is not a Quantified Self (QS) game as such – you’re not playing yourself, for one thing – the mechanisms and experiences within RPGs have definitely informed the QS movement. This has not gone unnoticed and there are many RPG-flavoured QS and self-improvement apps and games out there.

Here are a selected few:

Chore Wars

Gain experience points for housework. This was a firm favourite in our house when my girls were a bit younger, and having just sparked it up after a few years away (for the purposes of writing this article), my younger daughter is showing every sign of wanting to start playing again.

This game allows you to create character with all the stats of a D&D character – strength, constitution, charisma etc., who can gain experience points (XP) and level up (at every 200 XP) through carrying out domestic chores. A Dungeon Master (DM) account allows you to create adventures and quests. Adventures are recurring tasks which can be claimed by a character each time they are performed, while quests disappear after being claimed once.

When creating an adventure / quest, a DM can name and describe it, as well as applying XP (usually the no. of minutes it takes to perform the task), the gold and treasure that may be found (and %age chance), and monsters that may need to be battled. They also specify which of the character stats is used in the task and at what level (low, medium, high).

Gold, treasure and monsters are largely window dressing that add to the RPG feel, although you could ‘spend’ gold on real-world treats, once you have accumulated enough – likewise with treasure effects. The character stats feature is the most interesting. On levelling up, your characters stats will be adjusted up, and, unusually for an RPG, down, depending on the adventures you have undertaken. This, to me, is the most QS aspect of this game, because it helps you to see how well you are balancing different types of activities.

I’m now chuckling at some of the treasure and monsters we came up with creating adventures back in 2011. For doing guitar practice, for example, my elder daughter had a 60% chance of discovering a Map of Carnegie Hall, and a 33% chance of encountering a Plectrum-spitting Tuna

Not to be confused with….

BBC Women’s Hour Chore Wars

Which was a survey carried out to discover the split between men and women in terms of who does the most household chores. The survey is no longer available, but you can still see a broadbrush overview of its findings.

SuperBetter

Jane McGonigal sustained a concussion in 2009, after hitting her head at work. Recovery was slow, and Jane suffered from suicidal thoughts during this time. As a game designer, she decided to create a game which would help her to recover and build resilience, and ‘Jane the Concussion Slayer’ was born.

This was later renamed Superbetter, and now exists as an app and website which uses evidence-based approaches to building resilience and aiding recovery from challenges.

Players are encouraged to specify their Epic Win and the Goal that win will help them to achieve. There is plenty of help to get you there, and the app presents you with daily challenges which will slowly but surely move you towards your Epic Win. You can enlist the help of Allies – people who will support you during your journey, and use Power-ups – quick and easy actions which will give you an instant boost. There is recognition that it won’t all be plain sailing, as Bad Guys, like persistent thought, or bad habits are there to get in your way. Superbetter also encourages you to list your Future Boosts – things that you have to look forward to.

Like Chore Wars, you are able to select predetermined ‘programmes’, or, more usefully, to create and edit your own entries for all elements of your Superbetter journey.

Jane McGonigal’s second book, also called Superbetter, details the creation of this game. It is available from Amazon.

Habitica

Back in 2012, I was busy working on the design of Habitochi, a habit-breaking / forming app based on Tamagotchi. Sadly, it never got beyond the design stage, ironically, probably, because of my own inability to maintain the habit of working slowly and steadily towards raising the funds to build it. It’s still a possibility, if anyone is interested, but, several people have beat me to it – including Blobby, MOTi, DailyPet, and indeed Habitica, to a certain extent. I’m not one for sour grapes, though, even though all of these post-date the Habitochi concept – that’s entirely my fault.

Habitochi is still a better name than any of these, though, right?

Habitica allows you personify (monsterify?) all your tasks, which can be habits, regular e.g. daily task, or to-dos into monsters which you have to fight.

It includes many of the features of RPGs which are the things which keep us playing. Doing what you should – regular maintenance of your habit, ticking of your to-dos will enable you to upgrade your avatar with cool new armour and other stuff. Not doing so will mean that you start to move backwards, and in particular it will start to damage your health. There is also the (highly) rewarding feature of random reward – the psychological strategy which underlies gambling addiction, and keeps up killing monsters in RPGs because we never know whether the next looted body will turn up some knackered leather boots or a mithril broadsword (yeah, right!).

There are also pets, and social challenges (*mumbles sub-audibly about Habitochi*)

But what is really interesting about Habitica, in terms of presenting a variety of ideas in this article, is that it is an open-source project, which means that it has a dazzling array of integrations with 3^rd party tools, some of which measure and track (the usual thing that people think of when hearing ‘Quantified Self’). Habitica can be integrated with e.g. Trello, Cloudflare Workers, Zapier etc.

Fill your (seven-league) boots!

Life RPG

I have become (sometimes, painfully) aware throughout life that not everyone is as interested in Dungeons (or, indeed, Dragons), as I am. If you have been reading this, and thinking, ‘I can see how this might work, but I can’t be doing with all the sword ‘n’ sorcery shizzle’, then LifeRPG is probably more up your (non-magical) street. It strips away a lot of the narrative while retaining the basic mechanics that help you to get (mundane) stuff done.

It is also, arguably, the most customisable of the solutions presented here. I would say that this has most in common with productivity apps, and co-opts the idea of XP to add that extra bit of motivation to ticking off the tasks and projects.

Some of the game-like features included in this app are:

Categorising projects by difficulty, importance, and by assigning a Skill to each one, enabling you to further ‘gamify’ your prioritisation. ‘Eat that Frog’, anyone?

Levelling up. Like any other RPG, XP allows you to level up. In LifeRPG there is not cap on the level you can achieve, you can enter your own title to go with your level.

Skill Stats. If you (optionally) assign skills to tasks and projects, those skills will be improved when you complete tasks. This allows you to see life areas (Stats) where you are performing well, and others which are lagging, indicating that you could do with more practice.

Momentum Bar – measuring your ‘stick-at-itness’. Your momentum bar will drop each day unless you recharge it by completing tasks.

Aside the game mechanics, LifeRPG also contains some useful features for a productivity app, including different databases for different contexts, e.g. work projects and home projects, and a project log.

Do-It-Yourself

These are the solutions which others have created for you, and which in many cases, have stood the test of time, and have thousands of raving fans. But what if you want to really customise your game of life. Several Game designers and productivity experts have proposed that you design your own games to do this. I have already written one article this month about Yu-kai Chou’s Real-life RPG ideas, now known as 10,000 Hours of Play.

In addition, here is a great resource from Reddit detailing a simple ‘Player Guide’, to create your fully-customised life game.

I am also working on Character and Quest design templates – owing a lot to Steve Jackson’s GURPS system, which will be posted here in Ludogogy as soon as they are done. These are geared towards achieving medium and long-term goals by focusing on attributes and skills (and mini-quests) needed to achieve them.

What Next?

Many of the apps and games mentioned here have been around a while, as RPGs themselves have been, so will we be seeing anything new from the genre. Well, yes. At least I think so. RPGs have been undergoing some changes recently, as I wrote about in Learning Powered by the Apocalypse.

These are RPGs without the stats and numbers, so perhaps the next step is the ‘Qualified Self’ (not to be confused with the ideas in the book of the same name by Lee Humphrys, which is about social media sharing of mundane everyday life details). Maybe the new kinds of RPGs can help us to learn about the qualities of our lives, rather than the quantities, relying more on creating narrative and eliciting emotions, than creating measurable data.

A game to play to explore this idea would be Logan, where the player gets to experience their own version of a series of events that actually happened in the game designer’s life – a game play experience that is at once empathetic and self-reflective.

The post RPGs to Level Up in Life first appeared on Ludogogy.

3D printing workshop

In 2014, I led 3D printer assembly workshops. Students had the opportunity to build their own machine. They not only improved their mechanical skills, but they discovered cooperation and the exchange of know-how in programming and project management. So I had the idea to hack the “Arduino” boards, the sensors and actuators to make my own materials characterization instruments. The concept of the role-playing game “Hack and jaM” was born.

Hacking 3D printer parts to build a new device

In materials science we need to know the mechanical and thermal properties to choose the material suitable for a specification. In a 3D printer, all the ingredients are there for the design of a new prototype. Teams of six players challenged each other to design a new measuring instrument. As a client, I announced my expectations to clarify my needs. The players then had to analyze the market and check the overall feasibility. As the game master, I announced unforeseen events that players had to adapt to. Due to the limited duration of the session, the players had to outsource some of the work. To avoid boredom during the session, I limited the number of players to three per team : a project manager, a business engineer and a designer. The agility of the role-playing game has allowed the emergence of new rules such as the use of a currency: experience points, XP. The first six students who enter the room earn 100XP for their team. If a player character does not have a skill that slows down the progress of the project, he or she has the option of going to training. Delay points and a loss of XP are counted but
the success of the project is guaranteed.

Soft Skills development in Project Management

Although the main theme is mechatronics, students are assessed on skill development. They will know how to choose a sensor (temperature, pressure, force) and how to physically connect them to an “Arduino” board. But they will also know how to organize themselves, how to distribute tasks, how to manage time under stress. And they will also have to adopt collective intelligence strategies to solve complex problems. Sometimes I ask for the design of an instrument with a lot of features. The teams work on part of the problem first. Then they come together to share their progress and join together to complete the challenge.

Patent filing and book writing valuation

I first used Post-it notes for the first play tests. I then quickly designed square cards in 3.5 inch format using LATEX. A pattern-matching and color coded key on the cards allows the technical feasibility to be checked. The cards also serve as a “supplier” catalog. The card game has been patented (e-Soleau). University of Montpellier has supported a patent filing of “Hack and jaM” Role Playing Game (INPI). The game play can be easily adapted for other situations in Project Management, e.g. how to organize a social event, or how to develop a new prototype and so on.

Laurent’s book – Innovation Pédagogique, Serious Gaming et Game Design (French Edition) is available from Amazon

The post “Hack & jaM”: The birth of a Role Playing Game first appeared on Ludogogy.

The pandemic, however forced us to think about taking these workshops online, initially with the idea of improving engagement and seeing how close we could get to “the face-to-face experience” (see this article from Kanban Zone. What we discovered, though, was that we could make the de-brief and learnings from the workshops extremely relevant and engaging, and thus more convincing, in an online setting.

Light-bulb Moments

The debrief part of all of these games is designed to give an epiphanising “light-bulb” moment where participants suddenly “get” the idea. However, many of the explanations rely heavily on data, and it is often tricky to calculate this data quickly enough to replay it in the debrief. Hence, we must use either use stock datasets and graphs to illustrate the concept or have a break while we do calculations and draw graphs. The former doesn’t always convince, however, and the latter leads to us “losing the moment” which lessens the impact.

Taking the workshops online necessarily meant writing software, and that gave us the opportunity to do any data analysis in real-time, based on the actual behaviours of the participants. We quickly realised this was much more relevant and convincing. Sceptics can easily argue against stock datasets, but it is much harder to do so when the conclusions are based on their behaviour in a game they have just played.

We saw a great example of this when playing the No Estimates game at the recent Agile 20 Reflect conference. The No Estimates game demonstrates that estimating is futile, as it is impossible to do it accurately – quite a big mindset change for many people! In the game, we give players more information (e.g. the exact number of tasks to do, and the effort required for each task) than they would have in real-life, so they believe – as they are convinced they can estimate 100% accurately in real-life – that they will be able to do the same in the game.

The image below shows, for two of the teams in the game, their initial estimate, their estimate for the first 11 tasks, and the final number of days it took to do the. As you can see, even though both teams took the same amount of time – 40(ish) days – and had exactly the same information to start with, their initial estimates were wildly different.

Showing this information is much more convincing than saying “typically, people’s estimates are up to 50% out”, and is the first step towards dismantling participants belief in how accurate their estimates actually are.

The reason that estimates are always wrong is that people make many, many assumptions when estimating. Merely pointing this out never convinces anybody, but if we use the actual game data, we can demonstrate this very powerfully. As an example, there is an implicit assumption that bigger tasks will take longer. In the game, we can demonstrate this is not the case by showing the correlation between task size and time taken, as for one of the teams here:

A correlation of 1 means the bigger a task, the longer it will take. As you can see, this is far from the case; 0.49 is quite low. If we plot a distribution of the size of tasks, and how long they took, we will often see very small tasks taken longer than very large tasks. Again, showing this for the actual work the team has just done in the game really highlights this incorrect assumption.

In the face of these challenges to people’s prowess in estimating, one thing they often say “but we know there are variations, so we use an averages and standard deviations to give a range”. Unfortunately, to do this kind of statistical analysis relies on a normal distribution of data, and this is also an incorrect assumption. The game data comes to our rescue to demonstrate this as well. Here is the distribution of how long tasks took for two of the teams in the game

As you can see, neither is close to a normal distribution, so using mean and standard deviation is invalid.

There are many other graphs and datasets we show to highlight incorrect assumptions, but we finish the game with this real light-bulb:

This is a monte carlo simulation showing how long it will take to do N task in the future. It allows us to answer the question everyone wants answering when estimating – “when will it be delivered”. This is the real light bulb moment; given how you just performed in the game, we can predict when 100 tasks will be completed.

And this is the real power of using the real game data. Using the actual data that players have generated themselves, we have not only come to objective conclusions about their incorrect assumptions, but we have also given them tools to rectify the situation that they can use in the real world. We have come full circle; we started by stripping the situation right back to isolate the concept in a game situation, and have ended by demonstrating concepts and techniques that are applicable in the real-world.

We can see the contrast when using real data if we look at another game we implemented – The Coin Game – we haven’t yet implemented the real-time data features, so we just show the graph we usually draw in the face-to-face version of the game. This shows the amount of value delivered (y-axis) over time (x-axis).

This does get the concept across, but how much more convincing would a graph be if it showed the actual amount delivered by participants over time? We could even show the curve developing in real-time as the game is being played to really ram home the point that it is always better to deliver the next highest value items first.

One of the main reasons we brought workshops online was that they are really improved if played in a number of teams; the competitive element gets participants concentrating on the game rather than thinking too much about the concept, and this makes the light-bulb moment even more of a reveal! Break out rooms allow us to re-create this multi-team atmosphere online, but it also allows us to take the concept further; teams can play asynchronously – in different time zones, on different days – making scheduling easier, and, with some games, we can trend performance and scores over time to demonstrate improvements and changes. Again, all this is made possible through the recording of game data.

Online workshops have really given us an opportunity to use real data, in real-time, to convincingly demonstrate complex concepts to often sceptical participants, and has revolutionised how we present our learnings and feedback.

Check out Corrado’s Ludogogy author archive

The post Engaging and Relevant Feedback from Online Agile Workshops first appeared on Ludogogy.

This is the second part of an article published in the previous issue of Ludogogy about “Changes” , where we described Pizza KATA, a game designed to help people experimenting with a mindset on continuous improvement, which is a combination of Retrospective and Changes (now it is clear why this article spills over from “Changes” and arrives in “Debriefing and Feedback”).

In this second part we focus on a particular set of components of the game I called mini-boards. This is where the game is played but actually also where players decide how to implement changes discussed in the retrospectives between two “days” (rounds). Pizza KATA is a game played in different rounds (called “days”) and players are able to change strategy every day to achieve better results, like in real teams adopting Scrum.

The line of work of the restaurant

Mini-boards are the players’ world for the duration of the game

In traditional boardgames, you have a board where players interact with the system. However, in card games it is pretty common to place the cards directly on the table. This could work perfectly but for Pizza KATA we have a requirement: make the game both realistic and easy to set up. So I visited a real pizza restaurant for few hours over a couple of days and I was able to design a (simplified but realistic) workflow using a process we usually call Value Stream Mapping.

This image is interesting because other than the flow, it shows a couple of “dependencies”: the preparation of the ingredients (1) and the preparation of the boxes (5). Other than that, there is a starting stage (0) In Pizza KATA this is the source of orders and gives pace to the session. We have a very direct flow to last stage (6) where the pizzas are boxed and delivered to the customer.

This is the reality of the game and you cannot change it, but you can adapt and optimise your effort to maximise the attributes that are relevant for you: number of delivered orders, response time, minimise ingredients, maximise turnover,…

This reality is implemented through a set of mini-boards: each one is a step in the flow and has its intrinsic rules to perform activities. As an example, here you can see the “Kitchen”

Note. The kitchen actually uses two mini-boards and I hope you remember the tokens described in the previous article.

From now on, the images shown were taken working on a real order in a play session, and you will be able to follow it across all the stages, so you can see the game in action with all components. Notice the order is a “type III” order with five pizzas of four different types (see previous article for explanations of different types of orders).

Receiving orders

Phone calls are coming at a the pace of your main timer (or hourglass as I prefer).

The number of calls is defined by the number of order cards selected at the setup of the game (as described in the preparation of the order cards in the previous article).

Everything in the process is based on these incoming calls; and below you can see the mini-boards which manage them.

Here you can see the last received order of this session, which will arrive when the timer has finished.

Nothing really critical here, except that you could record timing using one of the tickets described in the previous article

Preparing ingredients

If you have ever cooked using a recipe, you will know how much time you must spend to prepare the ingredients. For the pizza it is the same, except that here time is critical and ingredients could be prepared in advance, or maybe by another player (this is a team decision), in the kitchen where there is a refrigerator and everything is safely stored.

The position of ingredients is pretty clear, the main rule is that you cannot mix ingredients that must be separated in their own area. This is by design to help you limit Work in Progress (WIP). However there are some icons which require explanation.

You will notice that each of the named food areas has a small circle with a number. This is to remind you that to prepare the ingredients you have to flip the tokens the given number of times, before placing them in the area. For example if you need one portion of onion you have to flip it five times; a portion of olives require three flips, ham just two and so on. The flip icon is different for tomato sauce (1+) and mozzarella (2+). Here the circle reminds how many flips you must do, but also that you can flip them in groups. This is faster, but also requires closer attention. This is a decision that a chef should make!

The dice icon is related to blockers that may come with events which occur when you draw an event card. These can be shuffled in with the orders.

Preparing pizzas

Preparing pizza is not easy, as you can imagine, even if you have prepared ingredients in advance. Pizza KATA is a fast paced game where you will receive an order every minute and so the queue of pizzas to be prepared sometimes gets large (and stressful).

The pizza preparation station is organised over two mini-boards: one to collect ingredients from the kitchen which you can use to prepare the pizza and another where you prepare the crusts on which to place the ingredients following the recipe.

The ingredient boxes is similar to the kitchen but has an important difference. Ingredients placed here cannot be boxed back in the refrigerator for safety reasons, so you need to move the right quantities of ingredients to avoid penalty points at the end of the game. That’s why the team will need to calculate the resources needed, and not simply add stuff without planning.

Then you have the “bar” where pizzas are prepared.

In the image you can notice that a player can prepare no more than six pizzas at the same time (there is a physical constraint on the bar). For this particular order, we have to prepare five pizzas and it is not a problem, but sometimes…

To prepare a pizza you need to first manipulate the dough. To prepare the dough you need to take the card and flip it on the dough side; then use you hand as you would do in reality: you need to stretch each corner twice and at the same moment rotate the dough for the given number of times (two or three). When you have done, you can again flip the card to show the areas where you can place ingredients and, eventually, the extra cooking marker.

The below image shows this stage with the five pizza order (notice the Napoli preparation).

When they have prepared the pizzas, the player must put them in the oven for cooking.

Cooking pizzas

The oven is a limited space where you can cook no more than 3 pizza at once. You can buy a bigger oven during the game but this has a cost and also requires a certain level of turnover to pay it back. The team has to think carefully about that.

In the below image, the player decided to put two Napoli and one Margherita in the oven (maybe not the best decision, but this is part of the learning curve with the game).

As you can see, next to the pizzas, you put a timer (the hourglass) to measure when they will be ready. Again note the Napoli pizza requires a specific timing for placing mozzarella….

Here the situation after the first timer: the Margherita is cooked and has been removed. The two Napoli have instead had extra mozzarella added and are ready for extra cooking time.

The chef decided to place the second Margherita in after removing the first one: again maybe not the best decision in terms of flow, considering the extra cooking required for the Boscaiola. However, this has to be managed. Meanwhile a new order has arrived and so you need to prepare other crusts… There are a lot of points to debrief for the team.

Serving the pizzas

If you ever been in a pizza takeaway you would have noticed that the pizza is placed on a plate before closing it in the delivery box. The pizza, when it is hot, must “take a breath of fresh air” to avoid the ingredients taking the taste from the cardboard of the box (this was revealed by a pizza chef!). The problem is finding the room to make this happen. That, in a takeaway restaurant, is often very limited.

Another important activity in this stage, is checking the order is properly managed, and that all the  ingredients are there so we can meet the expectations of our customers.

As you can imagine this is going to introduce a new constraint into the system, but this could also represents a buffer before the boxing process. Given this situation, I have configured the mini-board so that a standard oven is normally the bottleneck, but if you add an extra oven (yes, you can buy a second one) the bottleneck is moved to the serving stage (yes! This is simulating when you are increasing capacity in the bottleneck stage, without considering the impact on the whole system 🙂 ).

Let’s see how the transition between the cooking and the serving is implemented in the game.

Here you can see what happens when the first pizza in our order is (already cooked and) placed in the serving stage. Note this order is spreading across 3 stages, because there is still a pizza on the pizza bar (the oven is full).

The next stage (after one minute of the hourglass) is the following

As you can see now the pizza bar is free (a new order is probably already received), the oven has one pizza and the serving is full. We need to free space in this last stage and to do so we need to box the order.

Boxing the order

To box your order you need a new skill: you need an origami maker! (any thoughts about T-shaped people in your team?)

The last mini-box is the set of instructions to create the perfect box to collect and safely transport our order. This is a 12 steps process that uses a (recycled) A4 paper sheet.

When the box is ready, you can put the order card inside along with its related pizzas and ingredients.

In the above image you can see the four pizzas were in the serving area, now placed in the box. We have the possibility to serve the fifth pizza, that will be boxed (with the order card) in the next time slot.

This is the last stage of the process. Now you can deliver the pizzas, you can mark the order as completed and collect times in the provided ticket.

But a new order is very likely already in the line and more orders will come in the next minutes….

The importance of Kanban Principles

Mini-boards are designed for the players to experience true Kanban

As you can see in this scenario there are a lot of pitfalls but also opportunities to improve, and this is the reason why this game works. But you can also see the real time effect that is the basis of the game. This creates a really fast paced situation which is hard to manage but also fun to face. Finally, given that a day is 10 to 15 cards, you have 15 to 20 minutes each round, so you can play different days experimenting with all the Kanban Principles:

• Visualise the work: mini-boards are designed to visualise the work.
• Limit WIP: some mini-boards have explicit limitations.
• Manage Flow: you can follow and measure flow of the system on the mini-boards.
• Make Process Explicit: the game rules are transparent and visible. The team can define their own strategy.
• Implement Feedback Loops: even if the customer is not visible, you need to manage a budget.
• Improve Collaboratively, Evolve Experimentally: you have tools to collect data to analyse and improve by taking informed decision and verifying them.

How many people does it take to prepare pizzas?

People playing the game is the main goal of every game designer

This is the first question a facilitator could ask to people in the workshop: how many people can manage a pizza restaurant? Now that we know how the assembly line is composed we can understand how many people could manage it. But we need to consider another attribute of the game: the turnover. In fact the goal of the player is not only to deliver all received orders, but achieve this result with the minimum number of people, because the value delivered must be divided by the number of people that touch the line.

Maybe we can start from a real pizza takeaway where normally there is one person to prepare and cook pizzas and a second person doing all other the activities (receiving calls, preparing ingredients, preparing boxes and boxing pizzas). In this way we have the basic approach.

There is another person required in the game: the timekeeper who manages the pace of incoming orders and tracks all metrics using the tickets described in the previous article. This observer cannot interact with players or components or any artefact of the game. They just track times on tickets, or maybe on a board where the system can be represented. This is not an easy task and the value can bring is massive, so do not underestimate this role. The timekeeper is not to be counted in the turnover if they didn’t touch any component except the tickets.

Clearly, team composition could be different. Maybe you could have two pizza makers, or one person in the kitchen dedicated to ingredients, or any other way of working that the team themselves decides to adopt to be more effective. And this situation reinforces the principle that the team is empowered for  self-management and self-organisation. That is a strong attribute of real agile teams (at least four principles of the agile manifesto touch these topics).

In summary we need at least three players (two + timekeeper), and my suggestion is to play Pizza KATA with no more than six players per restaurant: one time keeper, one observer of the behaviours, one or two pizza bakers, one in the kitchen, one for reception and boxing.

What if we have to manage workshop for 10 or 20 people? These are too many for a single pizza shop, so we need to scale the game. Pizza KATA provides two different opportunities. We can create a competitive situation or a collaborative situation.

The competitive scenario is where you have different pizza restaurants with their own deck of orders (that maybe the facilitator can prepare in the same way), starting together, same pace, same ending and at the end of the day we can compare final result (value, orders, pizzas, rounds, metrics, ….). This is the scenario that players normally prefer.

The collaborative scenario is where you have one deck of orders and many assembly lines (like a big pizza franchising brand), starting and ending together and managing orders in parallel. This is the scenario I prefer because teams have to deal with real scaling dynamics and understand also how to work together as a team of teams.

The number of components required to manage a large scale session is based essentially on how you are scaling. Pizza KATA in fact lets the facilitator decide how to scale, and essentially this process is related on how to scale the WIP (not the people). So we can understand why scaling could be not directly related to teams but to the number of mini-boards used in the session. All rules for scaling are available in the facilitator guide. What we want to highlight now is that the facilitator could apply different approaches to scale the game. This is based essentially on the outcome of the session, but this possibility enables the facilitator to create different sessions with different objectives, simply adapting the scenario.

Having a Print&Play game is an enabler for scaling components, because you have all the material in the package, you need just to print multiple copies of what you need. It also lets the facilitator be creative in  experimenting with new scenarios that can be shared with other facilitators.

Retrospective of the day

People have the opportunity to improve every day, also in the game

Do not forget that this is a serious game and the goal is not only having fun but letting people experiment with how to improve their ways of working given a well defined goal. So we need to consider in the structure of the workshop, to include moments to analyse behaviours and change the processes in the restaurant. This is, IMHO, the most important moment of the session and it is strongly connected with the idea of the Kata. That’s why this is in the name of the game.

Retrospectives should happen at the end of every “day”, when the team discuss about what happened in the last day and take decision on what/how to change to improve. The time for discussion I normally recommend is 15 minutes, which is the duration of the “day” in the game (with 10 order cards).

I want to underline the role of observers. These watch the dynamics of the players and take notes during the session so they can share during the retrospective. Given the external perspective, they are in the best position to help the team to understand what worked and what didn’t.

Finally remember that playing this game without a retrospective for the team is useless (except for the fun, but maybe in that case it is better to play a ‘real’ board game).

Conclusion

Also the best games must end

We have initially identified some reasons why the existing pizza kanban game (a great game!) is not fitting for all situations and we have also identified some requisites an eventual new game should have. We could summarise this as “Before and after the execution, focus on the outcomes and not on the preparation. During the execution, focus on fun and not on boring stuff.” This goal has been achieved adopting a “board game design” approach and introducing game mechanics (components and rules) to enable a different level of game dynamics (player(s) interacting with the game). That’s why at the end this is an original game.

The game is articulated in different “days” where every team tries to improve its performance and increase performance and predictability of the activities to deliver pizza take,away: from order receiving to boxing.

This specific set of components, to Print & Play and reuse, helps facilitator to create the game session and at the same time expands to a lot of new possibilities. In fact, Pizza KATA has a deck of order cards and mini-boards which are able to create an infinite number of different sessions, but above, we define a few rules so the facilitator can create custom sessions focused on a particular situation the team should be able to deal with. We have also described how the game could scale creating situations where multiple teams compete or collaborate.

Pizza KATA has been created as a mindset improving experience. This emerges from the name (the word “KATA”), the way the game has been created (different experimental rounds), but also from the roles (the timekeeper) the mechanics (every “day” has a retro) and the components (the time tracker tickets). Everything has been designed to help the team focus on the real goal of the game: “having fun while experimenting with the effects of continuous improvement”.

Finally, the result is based on a financial perspective similar to our daily life where we do not have infinite resources. The team can buy a larger oven but that impacts their turnover. These are not constraints or limitations but enablers to achieve the best results possible in this scenario, with limited resources like our teams have to face in the real world.

I hope you enjoyed these articles on a game that essentially is about change and retrospectives. The last piece of information is the link to download the game: Pizza KATA, with all other P’n’P games I have designed, is available on DriveThruCards portal at the following link https://www.drivethrucards.com/browse/pub/17909/Agile-Game-Factory

DISCLAIMER. Notes presented here are personal and cannot be related in any way to any of my employers.

The post Pizza KATA II Retrospect is a Mindset and Not an Action first appeared on Ludogogy.

In an ever more complex world, large organisations rely on their ability to react or proactively change through large scale strategic initiatives, or as they are sometimes called, Must Win Battles. These could be initiatives such as implementing LEAN, changing production methods or finding new ways to engage customers. Unfortunately, many of these initiatives will, regardless of how great they look on paper, fail due to poor execution or a lack of stakeholder buy-in. Multiple studies¹ show that strategic initiatives often fail, because the people who run them have not prioritized the ‘softer side’ of change management such as timely involvement of the necessary stakeholders.

To be better at execution strategic transformations and lead major changes we need to get serious about stakeholder engagement and how we create the necessary support, commitment and empowerment. To be specific, we need a more refined and nuances approach that goes beyond conventual stakeholders mappings, and where we have an professional approach to organizational diplomacy and ‘office politics’. In short, we must expand our change leadership toolbox with inspiration and tools from both negotiation tactics, conflict resolution and influencing.

PLAYING TO WIN

On way to train and refine the critical skills of organization diplomacy and stakeholder engagement is to use game-based training and leadership simulations.

One example is Gamechangers, a board-game based leadership simulation, which focuses on the softer side of managing large strategy initiatives. In a fictive setting, the game lets the participants drive a large scale strategic transformation, and it shows how a large part of the initiative’s success depends on their ability to build coalitions and alignment. It zooms in on the crucial start-up phase, where stakeholder must come together and align expectations, and on the anchoring phase where they need to keep momentum and make the change part of the new reality of the organisation. In order to push through, they must be firm, but they also need to show flexibility in order to secure the right buy-in from key stakeholders.

The leadership simulation provides a safe training environment where the participant can learn from mistakes without jeopardizing real projects, budgets or colleagues. This helps the players to be much better prepared when they have to deliver when it really counts in real life.

TIME TO GO ANALOGUE

Digital tools for training are great for many things but when it comes to the training of refined leadership skills we need to put down the screens and engage face-to-face. IMD, one of the world’s best business schools, are among an increasing number of institutions and companies who use board-game based tools to train leaders and executives. In the words of Robert Hooijberg, Professor of Organizational Behavior: ”The leadership simulations stimulate, as we like to say at IMD, real learning with real impact for our executives.”

Every year new studies confirm that approximately two-thirds of all change projects fail. If your organization can accept these dire odds fine, but if you like to win and deliver, than you need to get serious about the softer side of change management, and in particular the aspect of stakeholder engagement. And for this, game-based training can be an invaluable training tool.

1. https://www.mckinsey.com/business-functions/organization/our-insights/how-to-beat-the-transformation-odds

The post Time to get serious about Stakeholder Engagement first appeared on Ludogogy.

“Work is actually very similar to play and even more like games. The main difference is perception.”

I agree with that whole-heartedly. In fact, if we look closer, we will notice that projects, especially those at work, and games have the same components. The following revealing definition of game components by Jane McGonigal in her book Reality Is Broken is known to many:

“What defines a game are the goal, the rules, the feedback system, and voluntary participation. Everything else is an effort to reinforce and enhance these four core components.”

— Jane McGonigal, Reality Is Broken

I am a business owner, so after reading this, I could immediately see parallels between the projects I was working on for my customers, and games. A contract or an agreement, which my customer and I both sign, contains all four of these components. Each project has a goal, there are specific rules, like how I shall do it and by when. There are reporting and evaluation systems in each contract, which is indeed a feedback system even if the progress is not recorded by getting points or badges. And finally, when my client and I sign the contract and make an agreement, we both demonstrate the free will to participate in that project’s “game.”

The same applies to job contracts which lead to your job “games,” with their goals, rules, feedback system (the regular meetings you most likely have with your boss, before or after which you and your employer provide some kind of evaluation of each other), and both sides demonstrating the voluntary participation by signing the employment contract.

So, any project (or task in that project) is already a game. We just rarely see them that way.

Why do we need to see and treat what we do as games? If we don’t want to see, call, and embrace what we are up to as games, then we won’t be able to “play” them and enjoy them in a similar way to games. Only when we become open to seeing our projects as games, can we identify how we can modify their design to make our “project games” exciting and fun.

The post To Play at Work, See What You Do as a Game first appeared on Ludogogy.

One of the best ways of learning for behavior change is through a simulated experience. These simulations create a practical context in which learners can practice repeatedly in a controlled environment.

Why are simulated environments key to learning new behaviours?

• They provide a safe space to make mistakes and learn from them.
• They provide the means for learners to immerse themselves in situations by performing tasks that resemble actual job activities.
• Learners can experiment with new ways to deal with the same solution.

Let’s take an example of simulating team work in a newly assembled project team. There are many new behaviours that need to be learned for a new project team to be successful, such as the need to develop an emotional bond between the team members, understand each other’s strengths and weaknesses, and how to help each other in times of need. There are also behaviors that might need adapting or improving, such as how to collaborate and communicate with each other effectively, how to manage time effectively, and how to prioritise when balancing several tasks.

Board games are a great way to create a simulated experience in the workplace. Project Ninjas is a good example of a collaborative board game that aims to achieve behavioural change through a simulated experience. It provides a practical context of working on a project team with time pressures and challenges. The original Project Ninjas board game is based around a traditional project management methodology with four phases: Initiate, Plan, Deliver, and Close. The team must collaborate to complete all the tasks and they win if they complete the project on time. The Agile Ninjas expansion provides a similar experience, but simulates agile project methodology in a practical context. This is great for project teams beginning to use Agile processes.

It’s really important that after running a simulation, you debrief with the group on their experience. If the simulation is a game or a fun experience, they might get carried away with it and forget what the purpose is. Give each individual time for self-reflection on their own behaviours so they can come up with key actions for what they need to change going forward. For example, someone might need to adapt their communication behaviour on a project because someone on the project team doesn’t like email and can be slow to respond, instead preferring more verbal ways of communication. These key actions should come out of the team reflection and/or the individual’s self-reflection.

The post How board games can achieve behaviour change in the workplace first appeared on Ludogogy.