Lego Flow Game

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)

Analyst

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)

Supplier

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)

Builder

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.

Checker

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.

Manager

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.

VN:F [1.9.22_1171]
Rating: 4.9/5 (7 votes cast)
Lego Flow Game, 4.9 out of 5 based on 7 ratings

9 comments on “Lego Flow Game

  1. Pingback: Lego Flow Game « TastyCupcakes.org

  2. 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

  3. 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.

  4. Pingback: Lego Flow Game | Joe Blogs

  5. Pingback: Was bedeuten Scrum und Kanban für den IT Betrieb? | proSense

  6. Pingback: Sind motivierte Mitarbeiter erfolgreicher? | Initiative Wirtschaftsdemokratie

  7. Pingback: Lego Flow Game | Chris Mitchell – Project Manager

Leave a Reply