This game is a co-creation, born of the blending of ideas by myself and Dr Sallyann Freudenberg. The earliest version was the Flow Experiment which I ran at SPA in 2010. Sal was in the audience that day, and liked the concept, but found the equations a little tedious and requiring too much effort, which took away form the primary learning objectives. She wasn’t the only one! She went away and reworked it using Lego rather than maths, making it much more fun, and last year (2013) we were able to run it together. The version described below is the result of some minor tweaks since then.
Overview
The Lego Flow Game is a fun exercise to compare and contrast different approaches to processes, with respect to how work flows. The aim of the game is to build Lego Advent Calendar items, with a defined workflow: finding the next advent calendar number (analysis), finding the matching set of lego pieces (supply), creating the lego item (build) and checking the item has been built correctly and robustly (accept). There are specialist roles for each stage in the workflow – analysis, suppliers, builders and acceptors – as well as an overall manager, and some market representatives. The game is run three times, each for a different type of process – batch and phase driven, time-boxed and flow-based.
Materials
As a facilitator, you’ll need to download:
- Instructional Slides
- Results Spreadsheet
Each team (consisting of at least 5 people) will need to have:
- 1 Lego Advent Calendar kit, with 24 door numbers cut individually, and the equivalent sets of 24 pieces, broken up and individually bagged.
- Blank index cards (around 50)
- 1 stapler (with staples!)
- 1 ball of BluTac
- 3 metrics sheets (1 for each round) – use the hidden slide in the deck
- 2 pens or sharpies
- Stopwatch
The Workflow
To begin, all 24 advent calendar doors should be shuffled and stacked in a single pile, and all 24 bags of Lego should be in an unsorted pile or bag. The Lego flows through the process, with roles performing their work as follows:
Analyst
The Analysts needs to have the stack of shuffled doors, the index cards, a pen and the BluTac. They find the next number in the pile of doors, starting at 1 and progressing in increasing numeric order. When they find it, they write that number on the top of an index card, stick the door to the index card below the number with the instructional picture (i.e. the reverse side from the number) facing up, and then pass it to the Supplier (as defined by the policies for each round)
Supplier
The Supplier needs access to the bags of Lego pieces, and the stapler. For each index card received from the Analyst, they find the bag of Lego that matches the picture on the card, staple the bag to the index card, and pass to the Builder (as defined by the policies for each round)
Builder
The Builder needs the index card, with the instructional picture and the corresponding bag of lego pieces attached. They build the Lego item for the pieces in the bag attached, as defined by the instructional picture on that card, and pass to the Acceptor (as defined by the policies for each round)
Acceptor
The Acceptor receives the index card with the instructional picture and the completed Lego item. They check that the Lego item exactly matches the picture on the index card. Exactly means that all heads, bodies and legs are facing in same direction and items are placed or positioned correctly. Additionally, they check for the robustness and quality of the build, such as whether all the pieces have been pushed together sufficiently. Assuming that the Lego items are correct and robust, then they can be considered Done, otherwise they are rejected. Each round will have different policies regarding what happens to rejected items.
Manager
The Manager will need a stopwatch (unless the facilitator does all the timing), the metrics sheets and a pen. Their role is to keep and eye on the process and ensure that no rules or policies are being broken. They may also keep time for their team, stopping and starting the rounds and letting the group know how much time they have left. However, we tend to do this centrally as facilitators. Finally, the Manager captures metrics by counting how many items are in each stage of the process every 30 seconds, filling that number into the metrics sheets. The number of items includes all items, whether queued, being worked on, or ready for handing on to the next stage. Note that the number of items ‘Done’ is incremental so will never decrease.
Market
This role is optional, but can be useful if there are lots of observers. We have noticed that Acceptors often allow items that we would have rejected because they want their team to do well. Therefore, having a few people independent of the teams to double check the quality, may help highlight this, and generate a discussion on quality and fitness for market. Ask for some volunteers to represent the market and instruct them privately (e.g. while the first round is in progress) to check the Done items and highlight any that they consider unfit for the market. Any poor quality items should be highlighted at the end of the round.
The Rounds
Before each round, explain the particular process policies that you are putting in place, as follows:
Batch and Stage Driven (Waterfall-like)
This is a single six-minute round. Teams should be given a pre-defined number of items that has been set as the expected target (we use 5), and that this number of items (i.e. the whole batch) must be completed in each stage, before being passed in their entirety to the next stage. Thus the Analyst must find and process all 5 doors before all 5 completed index cards are passed to the Supplier, and so on. Stages are independent, with roles being specialist skills, so workers may not help each other. Any work which is sub-standard and rejected is stuck where it is – it is expected that all the right work is done to the right quality level first time.
Time-Boxed (Scrum-like)
This time, there are 3 sets of 2 minute time-boxes. Before each new time-box begins each team should estimate/plan how many items they can complete within that time-box, and at the end they should review/retrospect how they did against their estimate/plan. We find 30 seconds should be sufficient for this quick discussion. When the time-box starts, as each item is completed in a stage it may be immediately passed to the next stage – there is no need to wait for the whole batch to be completed. Primary specialisms still apply, but now teams can be more collaborative and help each other if there is nothing for them to do in their stage. Because of this teamwork, rejected work can now be passed back and improved. At the end of a time-box, if there are partially completed items they can be kept and continued to be worked during the next time-box begins. If a team completes all their estimated work, they may take further work in, but only when all the items are accepted as done. Encourage teams to keep to the spirit of Scrum by planning on working only on what they feel they can complete in 2 minutes rather than starting more work than they should knowing that they can continue it.
Flow-Based (Kanban-like)
This is another single six-minute round again. There is no need to estimate how many items can be done, but instead a WIP limit of one item per stage is introduced. This limit includes both items being worked on and those completed and ready for work in the next stage. Thus a basic pull system is created, such that only when a stage is empty may it pull a ready item from the preceding stage. For example, when a Supplier has finished their work on an item (e.g. door 3), they cannot pull and begin work on the next item from the Analyst upstream (door 4), until the Builder downstream has pulled and begun work on their completed item (door 3). As in the time-boxed round, primary specialisms still apply although team-members may help each other if there is nothing in their phase. Similarly, rejected work can be passed back.
Debriefing
After each round, gather up the metrics sheets and quickly enter the numbers in the spreadsheet. We have found it useful to have a different file per group. While the numbers are being entered, the teams can tidy up their tables ready for the next round, including returning all the advent doors back to the shuffled pile. This is so that that the Analysts job doesn’t get easier as the number of cards decreases.
Teams can also discuss what worked and what was challenging about the policies after each round. The goal is start thinking about pros and cons of different approaches rather than trying to prove one way is better than any other. At the very end, show the Cumulative Flow Diagrams and use them to also compare and contrast the different rounds with respect to flow.
Finally, if you have time, you can ask teams what other policy changes they would make to try and improve their processes and performance, and maybe even try them out and capture the metrics to see.
[…] Link to Game: https://availagility.co.uk/lego-flow-game/ […]
We run the game at my office in Barclays and it was very useful. Thank you Karl!
We changed few items:
1. We got rid of supplier role
2. We added 4th phase – self improved round
3. We changed the logo design to easier ones ?
Kamila
Hi Kamila
Thanks for these comments.
1. Did you combine the Supplier role with the Analyst? How did this work out?
2. Agreed – I also like to do this when time permits.
3. Can you share the designs you used? I would like to simplify them and reduce the cost of getting the advent calendars!
Karl
I ran the game at the Agile North East meetup group and it was extremely well received. Lots of good comments from people who enjoyed the event. (Pictures can be found here: http://www.meetup.com/Agile-North-East/events/219802845/ ).
In place of advent calendars I used ‘blind bag’ Lego Minifigures (This sort of thing: http://www.lego.com/en-us/minifigures/products/71008-lego-minifigures). I stuck the leaflets that come with them to card and cut them up writing numbers on the back to replicate the advent calendar doors.
The lego minifigures worked quite well in general. I’m convinced they cost me more than advent calendars would when they’re around at Christmas but maybe less than they would have this time of year. Some of the minifigures were much harder to put together than others and one team in particular had a few with strange capes giving them a reasonable disadvantage over the other teams. I actually thought this worked quite well to illustrate different workloads.
A couple of other interesting things happened with individual teams.
One group was an entire testing team from a large software firm. They knew each other well and whilst working effectively together having a good understanding their specialty took over a little. They were the team who were harshest rejecting work, they were more meticulous than the other groups.
Another team had one of our regulars as their ‘Manager’, a character working for a big open source firm on quite research and development projects. I wouldn’t quite say he’s an anarchist but he’s used to working without much structure. That team were not held as tightly to some of the rules shall we say. They collaborated more than others, adjusted some of the processes a little bit and were actually more productive.
I had one very interesting comment / suggestion from someone at the end. The idea was that we should find a way to introduce some change into the requirements (probably during the Scrum round) to demonstrate the ability to cope with change. I haven’t quite worked out how to do this yet (perhaps varying the order of the numbers at the last minute?) but thought it would be interesting.
[…] by Karl Scotland and Sallyann Freudenberg, and you can read all of the details of how to run it on Karl’s page. It makes sense to look at how the game works before reading about how we got […]
Hi Karl,
I like this game. In the lack of Legos I chose the Ubongo Game (http://www.amazon.co.uk/Kosmos-Verlags-GmbH-Co-6961840-Ubongo/dp/B0006VSLJ0/). It works fine as well. I made “order cards” with value and effort points. If someone likes to have them, drop a line to jan_fischbach at yahoo.com.
Bye, Jan Fischbach (Germany)
[…] sondern ausprobieren. Mit dem von Jan entwickelten Ubongo Flow Game – abgeleitet aus dem Lego Flow Game – lernten die Teilnehmer spielerisch die Vorteile und Chancen von Kanban-Systemen und agilem […]
[…] unseren Workshops benutzen wir eine Variante von Karl Scotlands “LEGO Flow Game” (https://availagility.co.uk/lego-flow-game/). Dabei hat ein Team die Aufgabe, für ein Projekt mindestens 6 Arbeitspakete abzuschließen. Wenn […]
[…] https://availagility.co.uk/lego-flow-game/ […]
Hello Karl.
We are going to test out this Lego Flow Game. Do you have any recommendations on which Lego Advent calendaer to buy for this purpose? Best Regards Roger Toftum
Hi Roger,
It doesn’t matter which calendar you use – although the “Friends” ones might be too easy. The Star Wars ones are usually popular, but it depends on the audience!
Hope that helps.
Karl
Thanks Karl. We will take a look at the Star Wars. Roger
Hi Karl,
I just tested the game in a meet-up with scrum masters, agile coaches etc. I was a fun evening. I like to share some thoughts, ideas and questions.
EXPERIENCE
We used the most recent version of the advent calendar. Some of the toys were quite complex. So it took quite long to build them. Especially in the third iteration and the WIP limit of 1 the numbers of the teams went down and the experience was somehow depressing and did not show the positive effect of WIP Limits.
MY LEARNINGS
Some learnings I made for myself and would use:
– I would rather do two rounds (waterfall and scrum). Reason: The target group for me would be people who are new to the idea and I would like to introduce things step by step and spend time on reflecting. I found the additional round was more confusing than helping. If I would do another round it would be to create a system that would work best, after the experience they made and after some comparision and reflection after the first two.
– In the scrum round I would ad time not just for estimation but also to adjust the process (mini retro). Could also be quite short but I think it is a core element which would otherwise be missing.
FUTHER IDEAS
I can also imagine to use the game for further sessions and that this game helps to introduce new elements.
It is much easer to talk about day to day problems through the game rather than adressing a person directly. So the problem is on the table and not pointing a specific person. So the game can also become a great tool for feedback and continuous improvement.
A) Working with sets of items (defined combination of items that are per definition a product e.g. all minifigures are one set). By this you can also implement the ideas of deliverable increments or at least start the discussion about it. Working with sets also has the benefit that people cannot cheat as the numbers are not increasing numbers. So they won’t know upfront. By using sets you can also adjust complexity as you predefine what a set is (you can leave easy or complex models out).
B) Create impediments (e.G. exclude sets from the stack, so they have to ask the facilitator. If they do tell them they can have it in one minute but when they get it, they have to start immediately // e.G. create sets that are not complete: one wheel is missing at a car. Lets see how a team handles the problem). Reflect on how to deal with impediments.
C) Add effort and value for each item (it does take you some time but if you reuse the sets it’s worth to do). By this you can add product ownership and also the question of how to set priorities (There was one Item that took 2 min for building!!! Which was 1/3 of the whole time.) Would be interesting to see how team prioritize.
D) After some experience with the LEGO – Exclude the pictures, just put on a card what you expect the builder to do “create a car” (You can reflect on user stories, micromanagement and product ownership of the team).
Some questions:
– In round 3 you recommend a WIP limit of 1 and at the same time say that everybody can support s.o. else in case he or she has nothing to to. How is that possible with a WIP limit of 1?
– Close to the above question. Would support mean to support the role in the work he or she is currently doing (e.g. support the builder in building the car he/she currently creates or take another fresh item and start building that). We played it the way that people could take new work. This then lead to the problem that priorities were mixed up (item 12 was delivered earlier than 10).
Quite a long feedback. I look forward to hear from you.
Thanks for creating and sharing the game.
Oliver
Hi Oliver,
Thanks for the great feedback. The game is CC-BY-SA so please feel free to experiment with your ideas within that license!
Regarding your question, the aim of the game is get participants to reflect on the strengths and weaknesses of all the rounds and policy types, rather than show e.g. kanban to be the best. This a WIP limit of 1 is intentionally low. Debriefs often mention this and we discuss what the impact of WIP limits and what better WIP limits might be. Often this relates to the amount of collaboration and utilisation. Similarly, what might a sensible batch size be (from round 1) and what sort of cadence would be useful (from round 2).
Hope that helps.
Karl
Hi Karl, thank you for your reply. You are absolutely right. The idea should not be to convince s.o. of a certain method but allow them to reflect on different approaches. I tend to also forget that this is what agility is mainly about. So thanks for reminding ;).
Still one remaining question regarding the rules. If I keep the WIP limit of one, doesn’t it contradict the other rule. “you can support each other, if you don’t have anything to work on“. I am struggling a bit with that one.
People support each other by collaborating on existing work in process. Thus the WIP limit is 1 item per workflow stage, and not 1 item per person. For example they can help the supplier rummage through the bags, or help the builder by finding pieces. Or if an item is rejected they can help fix it. Occasionally someone has nothing to do, and thats something to discuss in the debrief i.e. flow v. resource efficiency.
Karl
[…] Flow GameSource: availagility.co.uk/resources/games/lego-flow-game/Author: Karl Scotland and Dr Sallyann FreudenbergTiming: 60-90mins ~Year created: 2013License: CCAs […]