Lego Island Project Sim: Difference between revisions

From AgileMe
Jump to navigation Jump to search
 
(28 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[Category:Agile:Workshop]][[Category:Agile]]
[[Category:Agile:Workshops]][[Category:Agile]]
==Introduction==
==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.
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.
Line 33: Line 33:


===Additional Items===
===Additional Items===
* Pre-printed Learning Objective Product Backlog Item cards
* Pre-printed [[Media:Learning_Outcomes_Stories.pdf|Learning Objective Cards]]
* Pre-printed Project Product Backlog Item cards
* Pre-printed [[Media:Super_Villain_Stories.pdf|Product Backlog Stories]]
* Pre-printed or pre-drawn game map, (4 x flip chart sheets taped together or 2 x A0 sheets with rivers, beaches, marshland, high ground, forest, cliffs, reef etc. features on it.)
* Pre-printed [[Media:Lego_Story_Map_Cards.pdf|Story Map Headers]]
* Marker pens to draw priority filter lanes and available spaces to indicated WIP limits
* Pre-printed [[Debrief Cards]]
* Pre-printed or pre-drawn game map
** [[Media:Lego_Game_Map_(Left_Page).pdf|Left hand side sheet]]
** [[Media:Lego_Game_Map_(Right_Page).pdf|Right hand side sheet]]
* Pre-printed [[Media:Scrum_Worksheet.pdf|Scrum Worksheet]]
* Marker pens
* Flip chart paper
* Flip chart paper
* Blu tac or decorator's tape
* Blu tac or decorator's tape
Line 43: Line 48:
* A desk bell for when things are deemed "Done" during the sprint reviews / showcases
* A desk bell for when things are deemed "Done" during the sprint reviews / showcases


N.B. It is good to understand how big the group is going to be and how many teams are going to be setup. E.g. teams of 4-5 people tend to work quite well, with larger teams promoting abstention from the game. Knowing how many teams are going to play the game can influence how much equipment may be needed.
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==
==Initial Setup==
Line 49: Line 54:


* 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.
* 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 headings of the story map that will form the Backlog stuck to the wall with lots of space to allow everyone to gather around it
* 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
* 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 Sprint Backlog per team - can be hand drawn on flip chart paper
Line 56: Line 63:


==Connections (60 Mins)==
==Connections (60 Mins)==
===The Scenario===
Our anti-hero, (insert name of The Super Villain,) has recently acquired enough money to purchase this island in the mid Pacific and 4 sprints of our time to improve it. The sundry items such as food and water are already taken care of, but we can choose from 30-40 possible improvements in the backlog.
===The Vision===
To use our time and 4 sprints to improve the island using the 30-40 backlog items so that it can have a future source of income after the project. (This is the vision to help the teams align their choice of stories to be done.)
===The Super Villain===
===The Super Villain===
Every project needs a customer or 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. (In the Super Villain's Lair version of the game, a Super Villain is called for with suggestions for their "Super Villain's name", which is used as a pseudonym for the Product Owner throughout the game and provides a little escapism and fun.)
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.
 
Ask the attendees who is expecting to play the Product Owner role, and for the game, to play the Super Villain. Don't forget to ask them their Super Villain name and refer to them throughout the game by this name.


===Team Setup===
===Team Setup===
Line 71: Line 70:


===Setting The Scene (10 mins)===
===Setting The Scene (10 mins)===
Once a Product Owner is identified, then provide some context for the game, e.g. in the Super Villain's Lair version of the game a short narrative about how the Super Villain is a new super villain and is has just stolen some money. Enough money to buy an island, (gather everyone around the map,) and to pay for the group of attendees to improve the island for up to 4 iterations, (providing a fixed cost dynamic to the project.)
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."
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 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"
"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)===
===(Parallel Activity) Prioritising The Backlog (20 mins)===
Once the group understands the overall context for the project, the fixed cost nature of the project, and an overall vision, e.g. that the island has to be able to sustain an income for the new Super Villain within 3 sprints, then the Product Owner can be given a stack of the pre-printed Project PBIs and asked to select their top 10 items to be placed on the Project Product Backlog.
# 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.
 
# 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.
The wider group can also be asked to help out the product owner to sort through the cards, organise them into common themes and select the top 10 for example.
# 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.
 
Once the top 10 PBIs have been selected and placed on the Project Product Backlog, then ask the group to place this up on the wall in a central location where everyone can see it.


===(Parallel Activity) Team Workstation Setup (20 mins)===
===(Parallel Activity) Team Workstation Setup (20 mins)===
As a majority of the attendees assist the Product Owner / Super Villain to determine the order of the product backlog, ask 2 team members from each of the teams to sort out their team workspaces with the following items that should be in their chosen work area:
Ask the remaining team members to sort out their team workspaces with the following items that should be in their chosen work area:


# A Sprint Backlog or Visual Management Board up on the wall - flip chart paper with state lanes hand drawn on it
# A Sprint Backlog or Visual Management Board up on the wall - flip chart paper with state lanes hand drawn on it
Line 96: Line 95:


==Concrete Practice (90 Mins)==
==Concrete Practice (90 Mins)==
Once the Learning Objectives Product Backlog, Project Product Backlog, and team areas have been setup, then it is time to start the game.
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.
Start by drawing attention to the agile framework diagram indicating the flow of the work and the various ceremonies that are to be done.
Line 105: Line 104:


# 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
# 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
# Begin the first sprint / iteration and encourage the teams to start working on their selected PBIs for 8 minutes - using a big timer projected on the wall works well
# 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
# 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
# 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
# Hold a sprint review / showcase session with all attendees at the map with each team taking turns to show and deploy their creations, and present them to the Product Owner who determines if they have been satisfactorily completed and obtain feedback.
# Hold a sprint review / showcase session with all attendees at the map with each team taking turns to show and deploy their creations.
## 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.)
# If the creations are deemed "Done" then encourage the Product Owner to hit the desk bell with a resounding "Ding!"
# If the creations are deemed "Done" then encourage the Product Owner to hit the desk bell with a resounding "Ding!"
# If the creations are not deemed to be "Done, then encourage the Product Owner to provide the team with valuable feedback on how they can improve
# 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
# 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
# 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
# Finish the iteration with individual team retrospectives for 3 mins
# Finish the iteration with individual team retrospectives for 3 mins
# Repeat for the second, third and fourth sprints / iterations (N.B. For successive sprints / iterations blank system cards can also be used for the Product Owner to capture new ideas to improve the products that can then be introduced and ordered on the Project Product Backlog)
# Repeat for the second, third and fourth sprints / iterations  
## 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===
===In Game Coaching===
Line 125: Line 126:


==Conclusions (30 Mins)==
==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.
# Arrange the Learning Objective cards around the game map
# Ask all of the delegates to split into 2s and 3s
# Ask all of the delegates to split into 2s and 3s
# Provide each of the mini teams a sheet of flip chart paper
# Provide each of the mini teams a sheet of flip chart paper
# Ask the mini teams to pick off one of the prioritised learning objective system cards from the learning objective backlog
# Ask the mini teams to pick up one or two of the learning objective cards
# Give the mini teams 5 minutes to do a mind map / list of lessons learned that relate to their chosen learning objective (N.B. If time allows, more than one learning objective can be chosen.)
# 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:
# Ask each of the mini teams to present their lessons learned to the remainder of the group for observation and discussion
#* What did you observe?
# Finish off the session with any general questions and answers on the board
#* Why did it work that way?
#* How can you apply it in your work?
# Ask each of the mini teams to share back to the wider group what they observed and learned
# 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==
* [[Micro:bit Challenge]]
* [[Micro:bit Project Simulation]]
* [[Hotel Booking Website Project Sim (Scrum Edition - Electronic)]]
* [[Hotel Booking Website Project Sim (Scrum Edition - Paper)]]
* [[PO Conference Website Part 3]]


==References==
==References==
* (Bowman 2009) Training From The Back of The Room, Sharon L. Bowman, 2009
* (Bowman 2009) [https://www.amazon.com.au/Training-Back-Room-Aside-Learn/dp/0787996629 Training From The Back of The Room, Sharon L. Bowman], 2009
* (Krivitsky 2013) [http://www.lego4scrum.com/ Alexey Krivitsky's Lego 4 Scrum site, http://www.lego4scrum.com/], 2013
* (Krivitsky 2013) [http://www.lego4scrum.com/ Alexey Krivitsky's Lego 4 Scrum site, http://www.lego4scrum.com/], 2013
* (TED 2011) [http://www.ted.com/talks/john_hunter_on_the_world_peace_game.html John Hunter: Teaching The World Peace Game, http://www.ted.com/talks/john_hunter_on_the_world_peace_game.html], 2011
* (TED 2011) [http://www.ted.com/talks/john_hunter_on_the_world_peace_game.html John Hunter: Teaching The World Peace Game, http://www.ted.com/talks/john_hunter_on_the_world_peace_game.html], 2011

Latest revision as of 00:55, 17 July 2019

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