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.

The post Applying Agile Practices to Create an Agile Serious Game 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.

This article is the story about how this game was born and about applying changes principles to a game talking about changes. This shows the very same approach we should follow when facilitating changes in organisations, which we call Transformation. This article is about a new game designed to help people in experimenting with changes; in their way of working, in collaboration protocols and in their innovation mindset. However, we will talk also about how change impacts the game itself, because this game was actually designed as an evolution of another game, and step by step it became something unique.

Originally this was written as a series of small posts, published on linkedIN on a weekly basis, so there is a lot of information there. For Ludogogy I revised the material into two articles: one published in this number and the second one in the Feedback Issue. I hope you will like them.

This is not my first submission to Ludogogy magazine. In past I talked about other games such as “DSbuilders”, a game about scaling collaboration, that will be presented in June at XP2021, and “PDCA elements”, an icebreaker game about scaling innovation. Follow this link to access Corrado’s author page

The reason behind the game

Change must start with “WHY?”

Kanban Pizza is an amazing game you can play with your teams to introduce most of the attributes of the flow of change and how you can use kanban principles to survive an evening in a pizza restaurant. You can also integrate a retrospective (between rounds) to help team understand the impacts of  improvements in the process.

If you want to know more I suggest that you watch the following video, which, in particular, shows you how you can manage the session virtually (really useful in these times).

I have played this game many times and facilitated a few less sessions, and this game has a lot of good points. However (IMHO) this game has also some pain points which we could describe with the following questions: Is the work realistic of a true team? What is the competence needed to copy & paste or to cut paper? Where is the collaboration in the team? Are teams really working following such confused norms? And are our teams working in such a confused environment? Maybe these are the reasons why this game often “degenerates” into a chaotic room where people cut coloured paper sheets and run across desks screaming about timing.

My hypothesis when starting this experiment, was we could add new perspectives to the game, inheriting some mechanics from card and board games, and, at the same time, keeping the (challenging) time presure that gives the fun. And, obviously, to find a way to help preparation, debriefing and learning. That’s why I started designing a Real Time Card Game (RTCG) version of the game.

WHAT should be different?

Define criteria to identify the value of your game

In the original version of the game, there is a small level of uncertainty, because we have very few pizza types, few situations to be managed, few blockers… This makes the game predictable and sometimes not challenging except for the manual activities. But maybe this is not the situation we want to create: we would like to put people in challenging situations where the process is the core, not the activities or the material.

Unpredictability is one of the key attributes for a card game, where the unexpected let you take the best of yourself and the fun. Clearly you have to properly balance the game (I mean build a balanced deck of cards and a decent rule set) so that people are focused on the “serious” goal of the game. Keep in mind this is a serious game, that some facilitator could use with a specific intent, so we should provide some guidance to help create the required situations, so uncertainty should be also controlled if needed, maybe creating different scenarios, maybe to enhance one or few of the above attributes.

Finally, the new game should help with its own setup, minimising the time and effort for organising a session, providing some components that you can simply distribute to players or place on desks, and reuse for many sessions. These components should be considered as the constraints for the mechanic of the game because reality has constraints: for example if you are working in a large company, software architecture is not controlled by the team (I know this is against 11th principle of the Agile Manifesto, but, again, this is life!). So these “limitations” should be in place to put players in the position to adapt their improvements considering their current situation.

Another valuable attribute of the game could be “scalability” (working well also in the original game). A game is normally designed for a defined number of players (not always true…), but it could be interesting to create a situation when we have many teams competing or (why not!) collaborating, or maybe create large learning sessions with players coming from different teams.

So our new game should:

• Consist of a balanced deck of cards to create the right level of uncertainty
• Have different configurations of play to create different experiences
• Create constraints to mimic real world experience
• Be scalable to make a multi-team
• experience possible.

Now it is time to talk about the name of the game: Pizza KATA, where “kata”, other than the Japanese word for “model”, is coming from “KAnban TakeAway” which is the actual payoff of the game. Note that “kata” is also a martial term strictly connected with the practice to perfection, a true lean metaphor (also Toyota uses in this way in its TPS, Toyota Production System).

I want to mention that this name was decided after a few tries and experiments, so this process also used the evolutionary approach. It was generated later in the process of game creation, but I need to put it here for obvious reasons.

Now we have a goal and we have requirements. We can describe how this game works.

First of all we need to clarify what a RTCG is: this is a card game where the turns are defined by a time pace and not by the players. This means that time overides the potential time required for all action a player needs to play. This is a completely different logic from a turn-based game (like traditional tricky  games, for example or most board games). The reason behind this decision is about keeping this realistic and similar to our working situations where we have to perform our activities in a world, where timing is not waiting for us.

This is a true constraint players have to deal with, but this is also the main reason for fun in the game, together with the uncertainty that is mainly based on the menu.

The menu of our restaurant

Pizzas must be the most relevant component of a pizza game.

One of the attributes of this game was to create a menu with a certain level of uncertainty and so many more options (instead of the two in the original). Obviously we cannot have a real menu with all possible options and ingredients. However, after some research with some friends we were able to define eight main ingredients that can help to create a decent (in terms of variety) menu. Our pizza restaurant can deliver eight different pizzas:

Focaccia

Marinara

Napoli

Margherita

Diavola

Carrettiera

Capricciosa

Boscaiola

However, if you ever have been in real Italian pizza restaurant, the strength is the possibility to modify your pizza according to your special taste. For our restaurant this is exactly the same. In fact we are able to accept fifteen different special variations. So actually, the menu is composed of 23 pizzas, with just eight ingredients!

Above you can see pizza MARGHERITA card that has 3 variations on the ingredients:

A. is with double mozzarella

B. is with ham and mushrooms

C. is with artichokes

The circled number on the top right corner is the price for the pizza and for each variation you can have different prices.

Clearly as you can see there are some tweaks of the real ingredients, however I think you can understand that this is not really impacting the goals of the game.

Below you can find the menu with all pizzas and “most” of the variations.

Two more comments about pizza cards:

1. The last card is a recap of all ingredients (read “tokens”) that we are going to use in our restaurant (read “game”).
2. I mentioned, in the list you can find “most” of the variations. Actually there is one more variable the customers can control: the cooking time (did you notice the “flame” icon?). As you can imagine this is something which deeply impacts the dynamic of the game, as we will see later.

We just introduced one of the components of the gam. Now we will focus on all other components needed to play Pizza KATA.

Components of the game

Components let you manipulate the reality of the game

Pizza KATA has cards and boards. We will explore them in detail later in the series. But first of all, we need some tokens to play the game. Most of these tokens are related to ingredients for our pizzas. Sure, you remember the pizza cards shown above. One of the cards (the ninth) shows all the components and variations, so we can use this card as a guideline for our introduction.

To make a wonderful pizza you need tomato sauce and mozzarella (line A) and then, to create different pizza recipes you can use ham, salami, artichoke, mushrooms, olive and onions.

These are the basic 8 ingredients and you need a type of token for each of them to add them on the pizza.

Then you need two more tokens (line C) if a pizza requires a “well done” extra cooking and when you have some impediments in the restaurant (be prepared!).

Line B is for removing some ingredients from the basic recipes, so no token is required.

Finally you need a d6 dice and a bunch of timers.

When you are preparing a PnP (print & play) game, tokens are the most “complicated” to create. Actually in the package you can find a paper version of them you can print, however I always suggest to work with 3D objects because these are easier to manipulate, and you need to manipulate them, because this is part of the game (again, be prepared!)

Here you can see the tokens I am using in my sessions and an example with a pizza Capricciosa ready for cooking (with another preview of the crust card used to prepare the pizzas).

As mentioned above, you need timers, because this is a Real Time card game.

You can use the timer on your smartphone but keep in mind, you will need more than one timer at the same time. We will see later how they are used, but for the moment keep in mind the following sequence 1-3-3 (you need from 4 to 7 timers). Maybe you can use a “multi-timer” app that can have many timers running on the same screen.

However, if you want to increase the fun, I strongly suggest using hourglasses. You can use the one suggested for children while brushing their teeth. They are very cheaply available on every marketplace on the web.

I use one minute timers, to create a fast-paced game. You can also use two minute timers to create a more quiet (but frankly, less fun) situation. As mentioned, you need at least four of them.

The specific set of component makes Pizza KATA a true game, complete and “out-of-the-box” as it is. But this approach bring another difference with the original. Game preparation absorbs energy and time that actually should be dedicated to conversation and experimentation.

We have already seen different types of cards available in the game but now it is time to describe the reality where the game is played: the restaurant.

Cards required to play the game

Cards are the essence of a card game.

So far, we have already presented two types of cards.

The Pizza cards describe the ingredients of each pizza and all possible variants. You can find also information about the value of each pizza and instruction for baking it.

Dough cards are very specific double face cards that have been designed to simulate pizza preparation. Preparing the dough is a real manual activity, inspired by true pizza baker: you have to slap on the table with the first side up, then you must roll and stretch for a given number of times. When the dough is ready you can flip the card and place ingredients (tokens) following the specific pizza recipe.

Order cards are the source of the flow and the core dynamic of the game, because this should create realistic, challenging and fun situations. That’s why designing and testing this deck is one of the essential tasks of the whole game creation.

Each of the order cards is designed to show the list of pizzas and the total value. It also has a special marker to easily identify the different types, and an ID to indicate the level of difficulty of the order.

There are seven different order types, organized in decks to be shuffled

• Three decks (I, II, III) of common orders differentiated by size and pizzas: we have basic orders with the simpler pizzas in small quantities, which are actually the most common in a pizza restaurant. We have family orders with all pizzas and medium quantities. These comprise the largest set of the three. Finally we have party orders where we have big orders of all pizzas. These are the most valuable.
• One deck of special orders (S), where some of the items have special variations ofthe eight pizzas in the menu.
• One deck of extra-cook orders (K) where some of the items requires extra time in cooking.
• One deck of urgent orders (X), where delivery in the given time can bring extra value.

Finally, there is another type or cards, event cards mixed with the orders that creates unpredictability with situations that impact on the flow of work: missing orders, double orders, missing ingredients….

All of these cards are designed to create well defined impact on the flow and, as a consequence, increase difficulty but also the fun for players. So let’s see how to use order cards and how Pizza KATA is a unique game.

A session is a sequence of “days”. Each of the days has a sequence of orders and at the end of the day the players have the possibility to discuss and introduce some improvements that can be applied in the following day. Using the order deck cards, the facilitator can apply his/her strategies to create the situations the team has to deal with. Example of strategies are:

• increment the number of cards from one round to the next one,
• mix cards from different sets to increase difficulty with the same number of cards,
• add one or more events to break the flow
• shuffle (or not) the cards to control the sequence or to add unpredictability,
• reuse the same sequence to verify improvement
• a mix of the above strategies in a single deck.

As an example, find below one of my favourite strategies, which you can apply in a 90 minute workshop:

• define 10 cards as a standard day of work and shuffle them every day
• continue the rounds in a day to complete all orders (to empty the queue) and count extra rounds
• Day 1: this is a warmup, with 10 cards from deck I
• Day 2: 2 cards deck I, 7 from II and 1 event
• Day 3: 2 from I, 5 from II, 3 from III and 1 event
• Day 4: 2 from I, 3 from II, 2 from III, 1 from S, 1 from K and 1 event
• Day 5: same as Day 4 but with max 3 extra rounds

As you can imagine, this deck provide the facilitator with a lot of opportunities for experimentation but above all it lets the facilitator design the workshops for the team’s needs, without having to worry about the material because everything is in the game box.

Tracking performance during the game

“Without data, you have just another opinion”

Another asset of the game available in the package (even if this is not exactly a card or a component) is the set of “tickets” you can use to track how the team is doing the job.

The first type of ticket is useful to collect when an order enters the system (collection) and when the order exits from the system (delivery).

This is perfect to calculate the lead time of an order but also the average and helps the team to understand their performance and make predictions on time to deliver a potential future orders. This is the basic statistical analysis a team can perform on their job.

But if you want to understand better the behaviour of the system, you need to analyse the “stages” (i.e. sub-systems), because actually each stage tells a different story. So in the package you can find a second type of tickets

While the first ticket is for all orders in a session, this one is for a single order and let the team track all intermediate times: you can understand bottlenecks, calculate different cycle times, and obviously here you can collect the same information you have in the first ticket.

These tickets can be placed close to each stage, or maybe on a dedicated kanban board that visualises the flow into stages. So, using this second ticket, you can also visualise the Work In Progress (WIP), simply counting the tickets in a given stage.

As you can recognize, these are KANBAN in the strict sense, because “Kanban”, in Japanese, means “card” and these are the perfect prototype of tickets that teams are using to track their real work, so that they can measure their performances.

Note that both tickets can be used to track the orders (as described above) but also to track the pizzas in an order. The difference will be in the number of tickets and in the analysis you can perform with them. It is a team decision how to use them, maybe evolving the monitoring session by session after realising what information they need to track.

This is the end of the first part of this article. In the next issue, we are going to talk about the line of work of the pizza restaurant and how this has been implemented in the Pizza KATA. Finally we introduce the different play modes available: one team, more teams collaborating, and one team competitive.

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

The post Pizza KATA or “Change is a Mindset and not an Action” first appeared on Ludogogy.

The goal of this article is to explore how these two lenses (System Thinking and Game Design) can work together.

Instead of a tedious lecture to explain how this connection works, I thought to use a technique from ancient Greece which was also commonly used in the Renaissance period; the dialogue. In a dialogue the author invents a conversation between people who have knowledge, but different perspectives, around a specific topic that he wants to explore. In this way he could present different views, objections and responses, performing a true exploration of the subject. Just to give an example the “Dialogo sopra i due massimi sistemi del mondo” is the book where Galileo Galilei presented his disruptive vision of the universe.

Clearly, we are not here to discuss such an important topic, but we can imagine a dialogue between a Game Designer named GorDon (GD) and a System Thinker named STephanie (ST), and listen to their conversation about the creation of a brand new game, while trying to understand the different roles in this process.

NOTE. To distinguish the different speakers we are going to mark each comment using their references (GD or ST). I have highlighted, in bold, the unique contributions to the conversations coming from the different speakers.

GD: Good afternoon Stephanie and thanks for accepting my invitation to spend this warm day in the Italian Gardens of Hyde Park taking about a new game I am thinking of.

ST: You are welcome Gordon. It is a pleasure to listen to you while you think of a new game, to give some contributions, and at the same time, enjoy this wonderful place and weather.

GD: That’s true Stephanie, we can walk while talking.

I was asked to create a new game for the leaders of a big Company, to explore the advantages of scaling processes across large enterprises. I have identified some requirements of this game but I am a little bit stuck on the mechanic.

ST: Let’s start with the boundary conditions of this system, what are your requirements?

GD: The subject of the game is scaling, and the game should be (obviously) scalable and eventually involve a large number of players. Let’s assume we have 100 players. It should be a sort of icebreaker to prepare people around scaling and synchronicity across the organisation. Players should be leaders of business units of a large organisation who have some anti-patterns while collaborating.

ST: What are the interactions among the different parts of the systems (players, components…)?

GD: We need to define these, but ideally, as an icebreaker, should be easy to play like the Rock-Paper-Scissors game (later RPS) and easily scalable like Bingo.

ST: Let’s explore the RPS game and try to clearly understand this system, and let’s also use a mathematical perspective . This game is perfectly balanced for very specific attributes (conservative, essentially polyadic, strongly fair, and nondegenerate). Let me summarise the effect of these attributes on the new game:

• First each element should have that same number of winning and losing cases. This requirement implies the number of elements should be odd (3, 5, 7…).
• Second if you want to scale the RPS game you need to manage an exponential number of combinations (3→9, 5→25, 7→49); this could create situations not easily manageable with large number of players (100→10000)

GD: That’s an interesting, and challenging, starting point but something we can start from.

To simplify the process of collecting the choices we can use cards (instead of players’ fingers/hands), but clearly we need to define a different interaction model also because, as described in the linked RPS article, apparently the position of the player is relevant, and this is not feasible in the situation we want to create.

ST: Sometime, in Nature, when groups of individuals are interacting with each other, you can consider the clusters of individuals that have something in common. The model assumes that this “something” must be relevant for the interaction: we can call this a “role” and when a role is clear, we can model the interaction among clusters instead of individuals.. For example, people in organisations and Business Unit organisation.

GD: So we can cluster all players’ choices (read collect cards in decks) by similarities and see the results. But again scaling is too complicated and also where is the fun to draw a card if we miss the goal?

ST: We need to add some strategy. This could lead to a goal and also to a reason to take a decision to pick a different card and lead to win the game. The original RPS doesn’t have any strategy (randomness is not a strategy), but each system should have a goal. Again, we can use Nature as a reference: when you have some consumable resources you need a strategy to keep or collect resources.

GD: We have cards that can be consumed in some way and everyone is starting with the same set of cards. Maybe we can use double sided cards where the choice on one side could influence resources on the other side, so we could create different combinations of front and reverse sides where the players could pick (and consume) one of the possibilities, defining their own strategy on future actions. Each player can follow/predict different strategies so we have differentiation.

ST: That’s a great idea! In this way we could also override the limitation of the odd number of combinations, because we could create combination of the front/reverse excluding repetitions: ideally we could create a mechanic with four elements where, for each of then, you can have the other three elements, on the reverse side.

GD: That’s trivial to achieve. We can have a “called element” that is the attribute to play a card (front side) and use the elements on the reverse side (”hidden element”) to cluster cards and collect combinations. So you have the called element as a consumable resource and the hidden element to apply a strategy for future choice. Given that back and front could be identical, you can have a lot of different combinations and so apply different strategies.

We can create a game mechanic with four elements, where four is a very common number in Business Strategy. For example we could use the Plan, Do, Check, Act (PDCA) cycle that is very related to many processes of innovative organisations. In this way we can use the game to educate organisations in the PDCA cycle.

[Gordon starts drawing the PDCA cycle on the ground with a rod]

[Stephanie takes Gordon’s rod and draws diagonal connections to the cycle]

ST: Each step of the PDCA cycle has a previous and consecutive step and in combination with the last one we can have a tie (impossibility). So the game is balanced following exactly the same logic as RPS. Also scaling is easy because every player has the same set of cards and clustering can be managed even with 100 players.

We need to work on the double sided cards from the statistical perspective (combinations).

[Stephanie draws a matrix just beside the cycle]

This is the matrix of possible combinations front and back of the cards.

       P         D         C         A

P      X         –         =         +

D      +         X         –         =

C      =         +         X         –

A      –         =         +         X          

(“+” beats, “=” equals, “-” loses)

You can observe the balance of the signs by row and column.

As you can see the diagonal is forbidden (give the constraint to remove repetitions) and this diagonal actually create two identical areas above and below, so we can use just one of these. In this configuration we can have six double sided cards.

GD: Six is not a good number for cards. If we’ll use poker size cards, these are printed in A4 sheets of nine cards. Is there some way to create 9 balanced cards?

ST: Actually we could duplicate the two tie combinations (“=”) so we can create one more option for each of the elements. In this way we can arrive at eight.

GD: That’s fine. We can create a ninth card with instruction of the game or something to identify players. In this way if we want to scale to 100 players we need just to print the same sheet 100 times and distribute one to each player that could personalise it. Scaling the game could be absolutely trivial.

ST: As per the above matrix you can see that given any called element, at the beginning of the game players have four possible choices for hidden elements, and player’s choice at every turn influences following decisions. At the beginning, in theory you have 16 choices in total, four for each element.

GD: That’s great. So we can define that in each game you need to consume all the cards, so it is based on eight turns and the first player changes at every turn. In this way your choices are reduced every turn and at the end of the game you will have just one card. We need a specific rule to manage the condition of not having the “called element”.

Can we explore the resulting clusters of the played hidden elements?

ST: With this configuration of cards, in each turn, we can have three different possibilities of clustering  the hidden elements: one cluster for all, two clusters, three clusters. Because of the structure of the PDCA cycle, we can use the cycle itself to identify winning elements

GD: I see that we can use the cycle to assign points:

• three clusters: we can have lower (0 point) higher (2 points) and middle element (1 point);
• two clusters we can have lower (0 point) higher (2 points); in case of a tie combination 1 point for all players
• one cluster same points to all (0 points)

and make ‘maximise score’ as the goal.

ST: Now back to one of the initial questions: we have the components, we have the mechanic, we have scoring rules, but why do our players want to play? Or, from the system perspective, what is the goal of the system?

GD: The mechanic of the called and hidden element can work from a competitive point of view, however we could use a collaborative perspective and make ‘maximise score’ a goal. This means to select the same hidden element and, from the scaling perspective, the message is, to be synchronised. So we could change the score, in the case of one single cluster, to 3 points to make it clear that this is the best situation for the system.

However, we need also to introduce a further rule: no communication and no planning in advance of the sequence of the cards. This is a strong message from the organisational perspective because we need to know what other units are doing without any communication and this requires being synchronised in some way.

ST: Finally, the goal of the system in the collaborative mode is exactly the message you want to deliver to the players: scaling is more effective if units are synchronised. Maybe we can use competitive mode as a warm up and collaborative as the final game to generate constructive conversations among players.

GD and ST together: This game is ready to be implemented. [both are smiling each other]

Conclusions

I hope you enjoyed this “divertissment” (a la française), but I also hope you had some doubts on who Gordon and Stephanie could be in reality. They are not different persons but actually are different aspects of our thought processes: we have the more creative, intuitive and divergent perspective (Gordon), and we have a more rationale, analytical and convergent perspective (Stephanie). So you can understand why creating a game is a complete activity from the intellectual point of view that can be compared to other “more serious” tasks.

Now, what about this game?

PDCAelements is a real game, and is available on the DriveThruCards portal in an implementation for 12 players using a standard poker double deck based on 12 different business components to distinguish players. Clearly the game could be scalable to a larger audience.

The real process of creation of this mechanic (called “elements”) was not very different from the one described above and you can find some track of it in a couple of threads on BoardGameGeek, where the game has been introduced and is one of the game selected for the 54 cards game context 2021 (the only serious game in the list).

The”element” mechanic here described is absolutely flexible and can be used for many different situations: for example I have created a Christmas theme (also the rules) and its first implementation is based on the 4 natural elements and the zodiac signs.

As an Agile coach I really loved this PDCA themed implementation because this is probably the only game available on this subject, it is easy and quick to play and every play test highlights different discussions.

If you are interested the mechanic is available under Creative Commons 4.0,  (also the rules) the only request is to mention the name (elements) and the author (@agileDex). Feel free to contact me for more details.

The post A dialogue about creating a new game using two different lenses first appeared on Ludogogy.

The following is Corrado’s post – originally published on LinkedIn which explains more about it.

You can also read Corrado’s other posts in Ludogogy.

The Virtual Collaboration Deck is a deck of 9 double sided cards that could facilitate virtual meetings and create easy communication protocol across all participants.

I don’t want to enter here in the discussion about non-verbal communication, its percentages in people common interaction (30,40,60%…) and how this has been impacted by the current situation where everyone is working alone, only virtually connected with others. It is however out of any doubt that non-verbal communication is really hard to reproduce in pure virtual environments and we, as human, miss this a lot.

That’s why I was exploring different ways to activate it within teams. Cards immediately appeared as a good idea and also as a perfect example of gamification (yes, this is not serious gaming). Moreover cards can provide one more reason to activate video connection  and a fun way interact with the meeting participants without interrupting too abruptly the flow of the conversation. During in person meetings there are plenty of these situation (one for all? nodding with your head when you agree).

The best example of such a deck I have found on the market is the “Supercards” deck from Lisette Sutherland’s “Collaboration Superpowers”  that I strongly suggest to experiment.

The usage of these cards is pretty easy: take the card related to something you want to communicate to the speaker or to the participants and show it on the camera (obviously turned on). Immediately your message is delivered across the meeting without interrupting the speaker. The “raise hand” option in MS-Teams has exactly the same usage, but with these cards you more options.

I’ve used this deck for months (ask my team mates!) and I have identified some different situations/ideas to create my own deck. Here is when the experience as a game designer can be helpful, becasue I designed this deck following the same approach I use for games.

Below the attributes of the CVD deck:

• A deck easy to transfer and print (ideally a 1 page PDF < 1MB)
• Black and white cards (not grey-scale or coloured) to maximise visibility also using awful laptop cameras
• Standard icons, but also a short description in case of different cultures
• Standard paper should be used to minimise reflex
• A Low Ink version easy to Print and Play at home with cheap printers
• Be sure what was the card showing, so need a recall on the back of each card
• Want to optimise the usage of the single page, so moved to a double sided card solution
• Card and recall should avoid confusion (particularly critical in double sided cards)

The card is upside-down to be clearly used front-back (even if in this configuration there is no back or front). This solution seems to be very effective to be used in other games too. You can find all above attributes too.

This version of the deck collect the following collaboration cards.

1. You are on mute; Mute yourself please
2. Cannot hear you; Your voice is disturbed
3. I like this; I don’t like this
4. Awesome; Hello everyone
5. Cannot see the screen; You look frozen
6. Hear some background noise; Thank you
7. Need a break; Must drop off
8. I’ve something to say or ask; Ok for me
9. ELMO (Enough Let’s Move On); Slow down pls

If you like the idea, you can download the deck , use it and provide your feedback in the comments below.

To print them, do a double sided print in portrait mode, flipping on the long edge.

I hope this could help you and your team to move to a better level of collaboration.

NOTE: If you are asking yourself “Why CVD and not VCD?” It is because of the logo. 😉

The post Virtual Collaboration Deck Download first appeared on Ludogogy.

The game is a work in progress. This article deatils the version that you can see at Corrado’s workshop at AgileTour London 2020 in October.

As both these article refer specifically to terms related to Agile methodology, you may find this terminology reference in the Ludogopedia useful.

In this article I want to tell you the story about how DSbuilders evolved from the initial version with particular reference to card design. I think this is helpful to understand how creating a game can be complex like writing a book.

I started working on this game in March 2019, after a couple of PI Planning sessions with a SAFe ARTs (Scaled Agile Framework – Agile Release Train). During those situations I noticed teams were struggling in collaborating and we were not able to engage people in the right way. SAFe is very clear about the objective of PI Planning and defines a very precise agenda, but there is no clue on how to make people work. The reason is because this is based more on the experience and ability of the team members rather than the coaches’ experience. What could we do to enhance this ability? A game obviously.

So I had the idea to create a situation where teams have a complex interlocked backlog of stories to let people test the collaboration model quickly and safely. Ideally this should be a serious game because we should have some fun to make this really effective (otherwise it is just like normal work) and we should create some realistic, challenging but feasible scenarios where people can understand what they are going to do without worrying about building it.

So we came up with the idea to use a Star Wars like scenario.

The first draft of the backlog (i.e. the set of all components to build) took around two months, in the spare time of my working days, and gained great momentum with the idea of arranging a meetup on team collaboration.

I was so focused on the backlog, but actually I had no idea on how to build 100+ cards. So I started to learn about standards (cards are poker sized so you can use standard products and services), tools and techniques.

Keep in mind that the game now has four different type of cards (Components, Initiatives, Events and Roles, 135 cards), but at the beginning I focused on the Components cards.

Here is the first version of the cards: apart from the basic graphic, the logic of the connectors was completely different (here you can see three of them in the bottom right corner: “MOD”, “LIV”, “DEC”). However most of the information were already there and even with this basic format we were able to arrange the first sessions and in particular Play14 unconference where we managed two different sessions. Here we had a lot of gamers and I collected a lot of feedback that brought about the second version.

This card on the right in particular is just from the second session of Play14 where I introduced the new version of the connectors literally drawing them on the card. Good or not, this prototype created overnight was good enough to be successfully tested.

Next time you are asked for an example of MVP you can mention version 1 of DSbuilders!

With all the feedback collected, I approached version 2 and we tried to experiment with colours. Even if  the main graphic goal was to concentrate most of the information in the top of the cards to optimise the distribution of the cards on the mission board.

The colour experiment was not really successful, also because I think that colour shouldn’t convey any information, so that ideally, cards could be printed also in greyscale.

Here I added the second evolution of the connectors, directly based on the feedback collected from players until that moment (100+ people have been already involved).
Connectors looked like the weakest feature of the game: apparently players were not able to understand how these were working. In the image on the right you can see in the card I06 how the “connector producer” card is differentiated from the other components cards. Also connectors switched to four types.

On the right you can see the true version 2 of the cards. The design of the card now looks more linear: I created specific icons for Defence, Supremacy and Complexity and I integrate the new connector icons. As you can see cards are still greyscale.

In this version I also reviewed  dependencies: a few mistakes were fixed and some more logical connectors have been created. Finally I introduced at a later stage the third improvement on the connectors: tokens.

This version has been developed for a series of workshops between October and December, planned as follow ups of the successful September sessions. And obviously I collected more feedback, but also I started thinking that the game was almost ready to go public.

Finally came the new version of the cards that have completely redesigned with the metaphor of the “blue print”.

As you can see here the graphic review was the main improvement, even if I added few more ideas to improve collaboration and make this more realistic (for example the adoption of the alien alphabet). Now the design looks more professional and with the 3D boxes with shadows gives an idea of a working desk with all information randomly placed over the project sheet.

Is this the final version? Let’s start collecting feedback and we will see, for sure I have in mind some expansions.

Are you ready to conquer the galaxy?

The post Evolution of DSbuilders cards first appeared on Ludogogy.

A brief introduction to the game

The game is called DSbuilder and it is about building the Death Star in the Star Wars universe, just after the “Rogue one” movie. We have the plan of the weapon and we need to build it. Simple? Actually this is the most complex ever (in the future too). Some numbers: Six initiatives, Six sprints +100 components to build. This game is for TEAMS, and will involve between 18 and 30 “builders”.

This game has been successfully presented at Play14 in London, and we have already played a few engaging sessions in some meetups and in real companies. In these sessions I have collected a few interesting learnings on team dynamics and I was really impressed by how the game was able to expose them. This article is about these outcomes.

Start the activities

In the image below you can see the first two sprints and the points that immediately emerged.

Three  teams were not able to deliver anything in Sprint 1 because they were so focused on the dependencies that they missed the timebox.

Two teams have been impacted by the above problem and, practically, even if something has been delivered, nothing was working because of the missing internal dependencies (the tapped cards).

One team was able to deliver something coherent with their own internal dependencies but failed integrating with others and nothing was working.

Sprint 2 was much better. Now all of the teams were able to deliver something, and only one team missed the dependencies.

Unfortunately integration was still completely missing and actually nothing worked.

I would like to highlight the reduction of the velocity in two teams. This was due to the lack of external dependencies not managed by other teams. You can see this very well counting the number of cards on the board.

At this point something happened

People started to analyse the goal in detail trying to figure out how to achieve it, and reflecting on how this might relate to their real-life work.

They started more effective conversations (the game uses a full team retro, a Scrum of Scrums and PO sync during the sprint, to facilitate collaboration), focused on the integration more than on the backlog consumption.

They started realising that they have to work together to effectively integrate.

They worked together as a “team of teams”, and a collaboration model started appearing. They found how to interact (respecting the rules of the game) and above all to define a way to help each other.

So we moved to the next sprints

Below is the image of sprints three and four.

Here you can see the magic happening.

In Sprint Three one team (the bottom one in the picture) was completely devoted to other  initiatives’ backlog (no story in their own backlog) because they realised that short term goals were not impacting them. The other three teams worked in similar way, minimising activities on their own backlog. Everybody was focused on helping team 3 because they were impacting all other teams (you can verify this from the number of cards, more than twice as usual in points).

Even if they were able to solve most of the dependencies (only two were actually missed), they missed the short term goal, but the status of the project was much more stable than in previous sprints.

On Sprint Four they received a new short term goal, in addition to the previous one, so they needed to work to achieve both. Unfortunately because of a single missing dependency they were not able to achieve the goals and they all suffered a terrible death at the end of Sprint Four by the Emperor (using his evil powers).

Game over!

Conclusion

In this 100 minutes we were able to see in practice how collaboration is a concept that is well known by all teams, but actually few of them have a clear idea of how much collaboration can impact performance.

Another learning is that this complex project cannot be controlled at team level (confirming the system thinking view) but builders can win only if they worked all together for the effective common goal that is not the consumption of their own backlogs. It was absolutely clear that, even if each team could be able to complete their work, the fact of working together (scaling) with other teams introduced an unexpected level of complexity.

Also they have proven how sub-optimisation could help to achieve the effective result, even if this requires a further level of collaboration (sacrifice?).

The game is able to provide a backlog with dependencies (internal and external) and with integration requirements, very close to a real complex software project typical of large enterprises. This simulation has been considered by players pretty realistic of the effective difficulties found by teams working together. The game is not about building (I always trust the ability of a team to build stuff), but about planning and is absolutely unique in this genre.

The mechanic of the game is impacted by events, happening every sprint and the teams must be very careful to understand and adapt. The goal is not simply to complete the backlog in the given time; better, completing the backlog is not mandatory if the goal is achieved. And this is a lesson for business people too.

The post Collaboration gaps enhanced by a game? Yes, we can first appeared on Ludogogy.