Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/eficode-academy/lego-scrum-game

A scrum team simulation with lego
https://github.com/eficode-academy/lego-scrum-game

Last synced: 2 months ago
JSON representation

A scrum team simulation with lego

Awesome Lists containing this project

README 

        
# Praqmatic Lego game

At [Praqma](http://praqma.com/) we have run quite a bit of training in Agile Task Management. Recently while doing [CoDe Academy](http://www.code-conf.com/academy2016/) we added the [LEGO scrum game](http://lego4scrum.com). 



The reason that we have added the LEGO scrum game to our toolbox is

that it allows us to run a number of very short sprints with focus

being on the managing the backlog. Introducing some malicious Product

Owners also allows us to simulate the frustrations of dealing with

real world issues such as changing requirements and priorities,

product owners that might not know what they want, know anything about

the domain or care about details.



The actual sprints lasts seven minutes, this is rarely where the

actual learning is taking place, so it is nice that with the LEGOs we

can actually move closer to a finished product in such a short amount

of time. Using LEGOs to induce frustration also removes a bit of the

tension.



This document describes the implementation as used by Praqma of the LEGO scrum game platform from lego4scrum.



In this document we assume that we are working with a large (40+)

people, it should be trivially reducable to lesser groups.



## The story

You have a vision. A vision of a city of grandeur, a large spaceport or a cozy garden. It is YOUR city. You don't have it entirely planned out, but you think you know what you want. You are the Product Owner from Hell. Luckily you have a pool of strong developers that will help you. They will work in teams using state of the art Agile Task Management methods! They will help you realize your ever-changing vision of this city.



## Pre-game prep 

### Supplies 

* Lots of post-its - a pad or two per team

* Pens

* Something to provide a surface on which to place the cities - large pieces of paper will do

* Boards, flipovers or big pieces of paper that you can put on a wall. These will hold the swim lanes

* LEGO bricks - set #6177 is recommeded by lego4scrum. Anything that does not force the users into specific things will work. One box per team.



### Setup

Make sure that each team has a table to work. Each city should have a spot where the elements of the city can be placed after acceptance.



Each team also needs to have a place to put their swimlane. It is nice if they have a wall near their "workplace"



Depending on how many participants you have group the teams together in "cities". In our experience three teams to a city makes sense.



## Running the game

### Roles



#### Trainer 



The trainer is usually the person in charge of the

event. The trainer introduces the game. He describes the setting and the tools that are going on.

The trainer has the responsibility for keeping the pace.



#### Product Owner



Product owner is also from the event team. It is best if there is one product owner per city/group of teams.



#### Developer

#### (SCRUM master)

### Making teams



### Naming teams 

Make sure to get team names, they are fun and serve as a nice break and garner team spirit.



### Selecting team leads 

Make sure to elect team leads on each team so they can make sure that they have the right backlog. Also team-lead is the one both product owner and trainer communicates with.



### joint backlog

After teams are made, named and has elected a team lead we create the common backlog. What we need for our city. You can create it with the developers helping - again giving a nice community feel.

Make sure that

#### Suggestions for tasks



* Multiple 1-storey buildings 

* fewer 2-storey buildings

* Shop

* Church

* Hospital

* School

* Police Station

* Fire Station

* Park

* Bridge

* River ( Optional )

* Amusement Park

* Roller Coaster 

* Zoo

* Bowling Alley

* Dev shop

* Intersection

* Round-about

* Roads

* Pub

* Parking



Make sure to have each team lead gather the tasks that you agree upon, and produce the post-its for them.



Each team have their own backlog which gets fed from the city backlog.



### Game rounds

#### Sprint planning

The product owner prioritizes each task in the joint backlog. 



The PO has the team estimate how big each task is.



Each team makes a "deal" with the PO of which tasks they can finish in this sprint.



At this point, it is important that the PO does not have an idea about the scope, or necessarily cares about implementation. The PO does not know everything, he just has a vision.



The priorities are not static, the product owner is allowed to change priorities and ask for new tasks.



Each team grabs what tasks they believe they can finish and puts them into the team sprint backlog.

#### Sprint

This is when the teams actually play with the legos, trying to produce solutions to the tasks that they have agreed with their PO on.



If they forget to things to the __in progress__ column the PO can go to the team, that is very likely extremely busy building, and ask them why they are not working. The PO of course does not know what they are working on if it is not on the board.



A global clock may be used, or it may be up to the teams themselves to keep track of time. The important part of the exercise leader is to make sure that the sprints do not overflow the timeslot.

#### Delivery

At the delivery the PO can ask the teams to show the products they have made either accepting or rejecting each task.

Tasks that are not done of cause stays in the team backlog. The PO of course tries to push the team to overcommit and add more tasks to their backlog.



#### Retrospective

We are not doing agile if we are not trying to improve our process.

The retrospectives can be timeboxed or just last as long as is needed for each iteration.

It could reasonably be said that most of the learning takes place at the retrospectives and this means that time spent here is well spent.



There can be an advantage in timeboxing them in order to give a more cohesive experience for the participants.

Especially with multiple teams having them aligned in schedule is advantageous.



So far in the lego scrum games we've done the POs have been the ones driving the retrospectives.

This is probably a good idea if the games are relatively brief. 



In a longer setting there could be a point in having the team leads or scrum masters run the retrospective and have the POs serve as coaches to the people running the retrospectives.



This is of course a more difficult assignment to do efficiently, for both teachers and students, but could provide a more solid and relatable understanding.



#### Events

A lot of external events can influence on how efficiently an agile team can work.

We are tinkering with the idea of having these events happen at random during a game.



This could give fun, more gamified approach rather than having all the troubles stem from the POs being incompetent or annoying.



This of course needs to be balanced with the events not obscuring the learning goals or just being useless distractions and frustrations.



The following events could be written on notes and be drawn at random points in the game:

- Send a developer to another team

- Switch team lead

- Rotate teamleads between cities

- A dev is sick and will not participate in the next sprint

- PO is at a conference and can not receive any deliveries this sprint

- Trade a team with another city

- New policy from management: all buildings must be peer reviewed

- Team lead is at meetings entire sprint and will not be building anything this sprint



#### Learning goals for each round

Here are some ideas for learning goals:

 - Small self organizing teams: start off by not dividing people into 4 groups but having them in one and look at the bottlenecks.

 - Minimize work in progress: try to make them work on more than they can chew, preassure them to overcomitting.

 - Communication with the PO.



 

 

## Post-game evaluation

After the game it is important that we reiterate what learning points we are trying to emphasize throughout this game.

Most likely the students are confused and a bit annoyed with the product owners.



The following points are essential to bring forth: 

- It is not that far from real life experience

- Small Tasks

- Minimize Feedback Loop

- Destroy your assumptions

- Continous Integration / Feedback is an enable

- Demand access to your PO throughtout the sprint



## Outline for session of 2 x 45 minutes

- Introduction (15 minutes)

  - Who's got the roles

  - Place people

  - Make sure everyone has supplies

- 3 iterations with retrospectives



- Break



- 3 Iterattions with retrospective

- Post game evaluation (15 minutes)