Whilst researching for activities to do at North West Tester Gathering, Stu suggested we have a go at the Lego Game.
After some digging, I found & swotted up on the Lean Lego game. Turns out this wasn’t the game Stu was talking about - he was suggesting the Scrum Lego game.
Rather than letting what I learned about the Lean version of the game going to waste, I decided to try it out with my team on my current client site.
So what is this Lean Lego game all about then?
The Lean Lego game is a tool for helping to demonstrate lean principles in action & then applies that knowledge to software development
I wont go into details about lean principles here - Wikipedia will do a better job than me.
This post is focussed on what we as a team got from the session.
Go on then - what did you learn?
A bit of background - we as a team are meant to have a base knowledge of the lean principles, even if we can’t put them into words. For example, we have adopted a Kanban approach, in that we pull work rather push it, delivering as fast as possible & we are heavily into team empowerment.
With this in mind & a limited time schedule, we skipped a lot of the intro & got straight into the game.
So when the game started, most of the team attending the session (voluntary!) had half an idea of what to expect. This made my life easier as Facilitator as I openly admitted I wasn’t sure how the session was going to pan out.
The game is split into 3 iterations, with each iteration itself being split into 3 or 4 30 second rounds. After each iteration their is a retrospective (debrief) to talk about what went well & what didn’t go quite so well.
The next iteration is based on the lessons learned of the previous iteration & the scope is set by the game.
During the rounds in the first iteration (push system) we didn’t manage to build 1 house per round. This didn’t cover the cost of the inventory which was already in the system at the beginning of the iteration (which swelled during the iteration!). We also had several ‘departments’ doing nothing whilst they waited for the other departments to clear their backlogs.
Similarly, in the second iteration (pull system), we still didn’t manage to build 1 house per round. This resulted in swollen inventory & ‘departments’ either too busy or too bored.
The third iteration involved the team setting up work cells - each cell would build their own houses entirely. One major flaw was finally identified as the iteration began - only 1 team knew how to actually build the house! All the others had previously only been involved in sorting the raw materials. One bright spark had the idea of splitting the cell up with the build instructions in their head across each of the cells. This worked really well as it resulted in knowledge share & demonstarted the whole team approach to development.
Due to lack of bricks (see lessons learned section), I didn’t specifiy a colour of house to build for this round. The result was 11 houses (1 per team member), everyone was busy & no iventory - hoorah! The iteration was also changed to 1 round 2 minutes long - due to lack of the iventory, the iteration was completed in around 80 seconds. If I had more lego, there would have been more inventory & thus houses.
After the third round, the team moved into ideas of how we could improve the flow - the self improvement phase. This was great & there was loads of energy & ideas. We tried ideas like the customer could only buy 2 houses at a time, thus imposing WIP limits, as well as market demands (which colour house to build)
We tried things like each work cell building a section of a house & pulling the sections to add to their sections when the WIP limit was reached. This even resulted in cells merging to help clear WIP limits!
As a curveball, I included some lego bricks which were not in the building plans (e.g. 1×3 instead of 1×4, 2×4 with slope instead of regular 2×4 block) as ‘bugs’. It was interesting to see these bugs go through the different team members only to be flagged in the last station, or eaven in Production. No one questioned the presence of the piece, or didn’t notice it. To fix the bug, we just passed a correct peice through the system until it got to defect piece for replacement.
To wrap up the session we talked about how what we had just seen in the bricks related to our processes & Kanban wall. Very insightful.
I personally got loads out of the session & I hope the other team members did as well.
Lessons Learned
- I’d printed the build instructions too small & on one piece of paper - difficult for team to read
- I need way more lego to play this game!
- Actually display the cost of the iventory as well as the number of the bricks - highlight to team how many houses need to be built to cover cost of iventory.
- ‘Bugs’ worked well & we were all suprised when they were found in the last stage & even in Production!
- for future runs - when the bug is found, development of the house is paused, the defective piece passed back to an inventory where there is a proper piece (bug fix) & the proper piece passed forwardso that development can start again.
- With more bricks:
- the work cell iteration would have worked even if CEO had specified market demand (colour)
- could apply different prices to different colours to introduce the idea of value as well as volume
If you’re interested in lean development & possibly running the Lean Lego game, I would thoroughly recommend reading The Goal by Eli Goldratt. It will help put the theory behind what you see being put into practice in the game