Making Lego4Scrum Workshops

Setting the stage

Lego4Scrum is a role-playing workshop, and we started by explaining everyone’s responsibilities. There are three roles in Scrum: I put on the ScrumMaster hat, my fellow NoA Ignite’ project manager assumed the Product Owner role, and the students formed the Development Team. The Product Owner role is particularly demanding as you have to be mean to a bunch of people who didn’t do anything to deserve it. But well … the end justifies the means, and the goal was to illustrate that collaborating with clients is not all roses.

Project vision

After explaining the roles, we took the participants through the early project stages. Ania introduced herself as the Product Owner and presented the project vision: Our Norwegian guests were going to build an Eco Village for 10-15 reasonably well-off families. The participants were instructed to listen carefully and note important information on sticky notes. They were also expected to ask questions as required to be able to build a Lego city according to the vision, and missing information will hit the group later. For example, Ania specified the location of the Eco Village in northern Europe, where heavy winters are common. The participants only realised the importance of this information when she rejected all the buildings with flat roofs!

All exercises had a time limit, and ten minutes into the session I had to interrupt so that we could move on to building the product backlog.

The product backlog

During the project vision stage, we used sticky notes with information like “educational options” and “entertainment to engage all citizens“. The product backlog session went one level deeper. All participants were expected to help the Product Owner (a role often assumed by the client) break down the vision to tangible pieces of functionality. In the next 20-30 minutes, the group filled the backlog with items like “twin house“, “church” or “park“. This was an entertaining session where everyone pushed their creativity to come up with ideas. There was hardly enough space on our A0 sized paper.

The interns were very pleased with their work, until the Product Owner asked them to confirm that they were going to build everything in just four iterations – this was an external constraint, as we didn’t want the workshop to go on forever. Some of the students nodded optimistically, but the consensus was unavoidable: it was simply not going to be possible, but how could they have known? They had not had much Lego building practice, and it was the first time they worked together.

Item estimation

These circumstances set the perfect stage for the next exercise: estimation. The Product Owner explained that she couldn’t prioritise backlog items without rough estimates. At this point I explained the idea of story points estimation in less than 5 minutes (!) and encouraged the group to try it out.

Our backlog contained more than 30 items, so each participant had a chance to estimate at least two items. Each backlog item was considered in relation to all the others, and after 10 minutes of swarming around the flip-chart, the group was ready. The exercise confirmed that the concept of story points is easy to grasp, without a need for a long theoretical introduction.

While Ania prioritised the backlog based on the size (just delivered) and the business value, I explained some theory and why story points work so well in practice. The group still didn’t know how long it would take them to build a 1 story point bus stop, but they expected a single family house to take five times longer.

This was the end of the pre-game. The backlog had been prioritised and the deadlines understood – the group was ready to start building with Lego!

Finally, some fun with Lego

Playing with Lego is a lot more fun than reading about others playing, so I will not go into details here. In short, this is what we did:

• The group was divided into smaller teams
• Each team had an environment – a separate table with around 1 kg of Lego bricks
• The teams then went through 4 iterations, including:
  • Planning meetings in a multi-team environment
  • Sprints, i.e. the actual building phase
  • Review meetings in which the Product Owner rejected their deliveries due to quality issues, communication issues, scaling issues etc.
  • Retrospective meetings, when the group spent a minute or two reflecting on how to outsmart the Product Owner next time.

There was some tension in the air when the Product Owner rejected a few buildings from Sprint 2. It turned out that Ania had told Team A that all roofs had to be red, but this information had not been passed on to the other teams. Our Norwegian guests could not believe this would happen in real life projects. Sweet innocence :)

“We do not learn from experience …

… we learn from reflecting on experience”. This quote from the American philosopher John Dewey was an eye opener for me, and I always refer to it when I run training sessions.

And so the workshop ended with a 30 minute debriefing session. A discussion of similarities between the simulation and real-life projects resulted in many useful insights. One of the most important findings was that frequent inspections by the Product Owner led to process improvements and, in the end, resulted in a high quality product.

If on the other hand the group would spend 70 minutes building followed by 20 minutes reviewing, this would certainly lead to embarrassment in front of the Product Owner. Misunderstandings that would be easy to spot and fix in the early project stages would get multiplied and magnified, becoming almost impossible to correct towards the end of the project.

Everybody has something to learn

So far I have run this workshop for over 100 participants in three countries. I have learnt to be humble and to expect a lesson or two from every group. This time, I truly wondered if a group of interns with hardly any project experience could teach me anything. After all, I have spent the last 17 years working on projects!

But it was a lesson for me, too:

My usual way of teaching agile, in particular iterations, is to show how different it is from its predecessor, the waterfall process. However the confused faces of the workshop participants made me realise that they were not familiar with waterfall! Lucky them. Next time I coach a group of novices, I need to explain agile from a different angle. For this lesson, I am grateful.

Ha det bra, my Norwegian friends!

PKD

If you want to learn more on Lego4Scrum and Scrum framework:

• Visit www.lego4scrum.com to learn more on the original idea by Alexey Krivitsky.