Learning Scrum With Lego
He shared his experiences on Lean, Agile, Kanban and then went into the Scrum Methodology. One of the things that stood out for me in the morning part was when to choose for Kanban and when for Scrum. I’ve seen quite some teams that use (sort of) scrum and then when they reach a deadline, they move to Kanban. That Kanban looks more to me like a mess where everyone is just trying to finish the project in time.
But the core concept of Kanban is to manage ‘flow’ (instead of ‘iterations’ in scrum). Because the central thing is ‘flow’, it’s well suited to manage for example support: tickets come in and need to be completed in a continuous flow. The general conclusion was that teams CAN switch between Kanban and Scrum. But it’s better to choose one method, because teams get a certain routine, a rhythm of working. And if your rhythm is based on scrum, you work in iterations and you try to manage the velocity (upwards), that’s what will define the productivity of your team.
In the afternoon, we practiced theory using lego. Some people didn’t want to be on a photo or even seen playing lego :). But I general, I found the use of lego to practice the Scrum concepts, very useful. Alexey Krivitsky, the founder of the lego4scrum follows this game for his Certified ScrumMaster classes.
Here’s how the afternoon went in pictures:
After the 11 people self-organizing int 2 teams, we started with a backlog grooming session with the product owner (Arjan). The vision of the Product Owner was a lego city. We had created a backlog of items (e.g. one storey building, church, kindergarten, park, road, bridge, etc). During the grooming session, the 2 teams could ask the PO questions and analyze the backlog.
We then went on with an estimation session. We practiced 2 variants: Planning poker (using an app, which miraculously was installed on everyone’s phone within minutes) and Swimlanes. This part took quite some time, but also helped the teams to understand the requirements of the PO better.
Some team member even started writing out the detailed specs for some of the user stories.
To make the estimates better, teams started looking into the lego boxes. You need to get an idea of the materials in order to estimate how long it’ll take you to build the constructs.
Next step was for the teams to commit to the workload for the sprint(s). We had a ‘boss’ popping up here! Because discussions kept going, he figured he could just start assigning user stories to each of the teams (including the team he was NOT part of). And actually, this worked, the teams agreed to his arrangement with a few changes.
We did 3 iterations with 3 minutes sprint planning, 7 minutes sprint and 5 minutes review (including retrospective).
Here’s a short video of team A going through their second iteration.
And here’s the end result of the game: our city
We’re going to do more scrum courses using lego in the near future and we’re also hosting a distributed lego training (experience distributed teams).