Lego Island Project Sim

From AgileMe
Jump to navigation Jump to search

Introduction

Inspired by (TED 2011) and finding (Krivitsky 2013) this workshop was put together to enable the adoption of Agile practices through the use of a project simulation and gameplay. The idea being that a real small project can be done by the attendees within a short timeframe using an Agile framework to manage the project.

Experiencing what it is like to use an Agile framework rather than just hearing about it was seen as a key distinctive difference in attendees' abilities to connect with the new information and wield it for their projects after the workshop had finished. Hence, using an interactive gameplay approach has since been found to provide not only an engaging exercise that is fun and also unique every time, but also promotes deeper learning in the attendees generating more appropriate searching questions than traditional slide deck based training.

In addition, this workshop has been adjusted to use the 4 C's principles described in Sharon Bowman's book Training From The Back of The Room(Bowman 2009) to provide a little more concrete structure to the approach.

In the workshops that have been conducted so far, attendees have retained their attention for up to 3 hours during the workshop with a higher probability of knowledge transfer and retention long after the workshop has finished, providing analogies and real examples that can be referenced from game experience to illustrate future lessons in subsequent coaching engagements with the attendees.

Learning Objectives

  • To sufficiently prepare the attendees to apply Agile practices to real life projects
  • To provide an opportunity for attendees to complete their first Agile project and benefit from the experience
  • To enable a deeper insight into the Agile principles and how these might be applied to real projects
  • To experience working in multiple teams in a scaled approach
  • To experience agile in a fixed cost project context

Timings

This workshop usually takes up to 3 hours to complete 4 sprints / iterations if using pre-seeded backlog items.

N.B. The use of pre-seeded backlog items was introduced rather than encouraging the teams to devise their own PBIs in order to place more emphasis on the Scrum framework and its rhythms rather than spending an hour (33%) of the available time on PBI composition. Also, using pre-seeded PBIs enabled up to 4 sprints to be used within the same timeframe with PBIs were already sufficiently granular, easy to achieve and fun to build.

Materials

  • 8 boxes of 6177 standard Lego bricks for 4 teams (6 person teams)
  • Windows and door kits
  • Roof tiles kit
  • Plates for rooves
  • Minifigures – very good to indicate the scale of items to be built
  • Large 25 x 25 building plates to build upon
  • Large map of the island to build upon and to provide a central area that demonstrates the final product

N.B. Other materials can be used, but Lego seemed to be the best reusable, physical and tactile medium, which has yielded great results. It also reminds attendees of being children again.

Additional Items

N.B. Teams of 4-5 people tend to work very well, with larger teams leading to more discussion and delaying the timings.

Initial Setup

Prior to the session starting, it is recommended to have the following already made and ready to go:

  • An illustration of the agile framework to be used - could be a hand drawn diagram on a whiteboard, posters up on the wall, or a slide on a projector screen. Occasionally the group may need to understand where they are in the wider context of the agile framework, and so a big reference diagram that can be highlighted throughout the game is very helpful to the attendees when they are trying to figure out when and where the Scrum ceremonies are in the timeline for example.
  • The story map headings that will form the Backlog story map stuck to the wall with lots of space to allow everyone to gather around it
    • Hold back the sprint / iteration cards, as they are introduced during the course of the game
  • The game map taped to tables as a centre piece for the session
  • The improvement cards in a pack in the centre of the map
  • 1 x Sprint Backlog per team - can be hand drawn on flip chart paper
  • 1 x Velocity chart or Cumulative Flow Diagram per team - can be hand drawn on flip chart paper
  • 1 x Retrospective chart per team - can be hand drawn on flip chart paper

Connections (60 Mins)

The Super Villain

Every project needs a Product Owner who can provide guidance on what is high priority and what is their vision. So ask the attendees if anyone wants to volunteer as a Product Owner. Ask the team and the product owner who the customer is and what their "Super Villain name" is to add a bit of fun.

Team Setup

Ask the attendees to begin to sort themselves into teams of 4-5 people. Using the minimum amount of instruction possible encourages the group to self organise themselves into teams.

Setting The Scene (10 mins)

Once a Product Owner is identified, then provide some context for the game, e.g. the scenario and the vision for the game.

The Scenario

Whilst gathering the attendees around the map - "We are no longer in the IT business, but instead are in the Lego island improvement business, and our new customer <insert Super Villain name> is a new Super Villain who has recently come into a small amount of money. Enough to buy a small island in the mid Pacific and to pay for our time for 4 iterations to improve the island."

"The island has several features and there are some concrete pads available <refer to the grey lego plates>, although anywhere on the island can be built upon. There are also some workers that have been deployed to the island <refer to the mini figures> who represent the scale of things to be built. If a house is to be built for example, then the minifigure has to be able to go through the door etc."

The Vision

"The aim of the game is to improve the island with up to 40 possible improvements <refer to the product backlog items> within 4 iterations, as this is when the money runs out so that it supports habitation and has a means to generate more income. Deciding which things to do and when can be very important"

(Parallel Activity) Prioritising The Backlog (20 mins)

  1. Once the group understands the overall context for the project, the fixed cost nature of the project, and an overall vision etc. then give the stack of backlog cards to the Product Owner and ask for 1 volunteer from each team to help.
  2. When a small group of volunteers and the Product Owner are assembled give them the stack of the product backlog stories and ask them to arrange them under each of the story map headings on the wall. This activity then sees them building up the story map.
  3. When they are all done, insert the "Sprint 1" or "Iteration 1" card on the left hand side of the story map and ask the group to arrange the story map with the top 10 items to be aligned with "Sprint 1" or "Iteration 1" with the remaining cards underneath.

(Parallel Activity) Team Workstation Setup (20 mins)

Ask the remaining team members to sort out their team workspaces with the following items that should be in their chosen work area:

  1. A Sprint Backlog or Visual Management Board up on the wall - flip chart paper with state lanes hand drawn on it
  2. A Velocity / Cumulative Flow chart up on the wall - flip chart paper with axes, scales and labels hand drawn on it
  3. A Retrospective Board up on the wall - flip chart paper with labels and columns hand drawn on it
  4. Some Lego blocks
  5. A tennis ball, (if doing a daily scrum as well)

Concrete Practice (90 Mins)

Once the Project Product Backlog story map has been setup and the team areas are all set, then it is time to start the game.

Start by drawing attention to the agile framework diagram indicating the flow of the work and the various ceremonies that are to be done.

N.B. Don't spend too long on this as it delays the concrete practice, but do answer questions and ensure that the team have enough information to begin to use the framework. 5 minutes should be sufficient for an overview, but not any longer, as the attendees will get to experience it for real rather than just hear about it.

Once the teams are ready to start then:

  1. If using Scrum, give the team(s) 3 minutes to plan which of the Project Product Backlog Items that they are going to work on and suggest that they transfer these to their respective team Sprint Backlogs
  2. Begin the first sprint / iteration and encourage the teams to start working on their selected items for 8 minutes - using a big timer projected on the wall works well
  3. End the sprint / iteration and suggest a daily scrum with each of the teams for 2 minutes in front of their team Sprint Backlog using the tennis balls as talking balls
  4. Hold a sprint review / showcase session with all attendees at the map with each team taking turns to show and deploy their creations.
    1. Take it in turns reading from the backlog items and examining the creations to get feedback from the group and a consensus if it is done or not. (The Product Owner should be able to clarify details on behalf of the Super Villain.)
  5. If the creations are deemed "Done" then encourage the Product Owner to hit the desk bell with a resounding "Ding!"
  6. If the creations are not "Done, then encourage the Product Owner and the group to provide the team with valuable feedback on how they can improve
  7. Ask the teams to go back to their work areas an update their velocity / cumulative flow charts with the number of backlog items completed for that sprint / iteration
  8. Finish the iteration with individual team retrospectives for 3 mins
  9. Repeat for the second, third and fourth sprints / iterations
    1. After the first iteration, give the remaining sprint or iteration cards to the Product Owner so that they can arrange the Backlog story map accordingly and put together a release plan for the remainder of the game.

In Game Coaching

During the game play it is good practice to provide coaching to the teams when needed and attention can be drawn to these areas:

  • What is the scale of things to be built with lego? (N.B. It is good to have a few Lego minifigures with the lego to indicate the size of buildings and vehicles etc. otherwise a single lego block could be interpreted as a house)
  • What is the quality of the work? Are the teams proud of their creations?
  • How many sprints / iterations are left and should the Project Product Backlog be adjusted?
  • Are we using too much imagination for this imaginary, invisible, protective force field for it to be testable?
  • How are the teams going to implement their retrospective improvement?
  • How much capacity does the team have with respect to how many PBIs they have chosen on their Sprint Backlog?

Conclusions (30 Mins)

Having a solid structured debrief fosters the main learning from the exercise. It's easy to think that everyone learns whilst doing the activity, but some ample space to reflect on the experience really helps to crystallise the learning, so don't overlook the debrief and instead give it as much value as the main exercise.

  1. Arrange the Learning Objective cards around the game map
  2. Ask all of the delegates to split into 2s and 3s
  3. Provide each of the mini teams a sheet of flip chart paper
  4. Ask the mini teams to pick up one or two of the learning objective cards
  5. Ask the mini teams to spend 10 minutes to ask themselves the following questions with respect to the learning objective cards that they have chosen:
    • What did you observe?
    • Why did it work that way?
    • How can you apply it in your work?
  6. Ask each of the mini teams to share back to the wider group what they observed and learned
  7. Finish off the session with any general questions and answers, and photos of their creation

(N.B) Writing up the three questions on a flip chart paper for each team to see tends to work well

See Also

References