LEGO SCRUM (Tutorial 14)

anchored to [[191.00_anchor]]

I stole / copied this README from the official repository to have some remembrance / memories about it. Also to give context a given parts of this vault.

Repository overview

  • tasks are in ./tasks
  • presentation is in ./ as both PDF and Keynote files in both English and German
  • the cool Scrum video is here

Overview

Roles

  • Product Owner
    • owns what is desired
    • the tutor with a tie/hat
    • has a big vision to be shared
    • goal: illustrate how POs behave, what they typically expect and require
    • secondary goal: illustrate which team behaviours are appreciated and which aren’t
  • Scrum Master
    • owns the Scrum process; facilitator; “servant leader”
    • one of the students in each team – differentiated somehow (?)
    • helps to self-organize and manage work, but without assigning or distributing tasks
    • protects team, removes obstacles
    • promotes communication, moderates meetings
    • is NOT the leader of the team
    • is NOT a developer themselves
    • is NOT the manager of the team
    • does NOT give out instructions about who has to do what work and how
  • Scrum Team
    • owns how and how quickly work is delivered
    • the rest of the students
  • Stakeholders
    • the people with the money ;)
  • Users
    • the people who will use your product

Pre-game [35 minutes]

  1. Pitching the vision – PO communicates vision/big picture
  2. Forming the teams
  3. Users & needs
  4. Estimating and detailing

In-game [40 = 2 x 20 minutes]

3 sprints, each sprint contains:

based on playtesting: Only two sprints, but don’t tell the students ;)

  1. Sprint Planning (3 minutes) – what is to be developed?
  2. Building (7 minutes) – only this part is playing with Legos :)
  3. Sprint Review (5 minutes) – PO and team review work
  4. Sprint Retrospective (5 minutes) – team revises their way of work in the past to be more efficient in the future

Post-game [15 minutes]

  1. Clean-up (5 minutes)
  2. Lessons learned (10 minutes)

Pre-game: Defining the Product

Pitching the vision (5 minutes)

We are to build a model of a small, environmentally-friendly town in Southern Germany. The goal is to create a Lego city with houses, shops, recreation, streets…

  • get the participants motivated here, feel free to come up with more details to immerse them in the world :)

  • release goals:

    1. the residents feel good at home and at work
    2. we can make tourists from around the world happy by providing great leisure
    3. the city is an environmentally friendly industrial metropolis

  • note that we will focus on the first release goal

based on playtesting: Let them know that they are working on the same city, same product. -They are cooperating, not competing – there are no prizes, no bonuses. ;)

Forming the teams (5 minutes)

  • 4 - 7 people per team

    • each team chooses a Scrum Master (good orga skills)

  • mention again what a SM does (see Roles above)

Building the backlog (5 minutes)

On the LEFT SIDE of the board, build the task backlog based on the vision (pick out some tasks, don’t forget to add the glue to the back ;))

based on playtesting: If you can, prepare it on the board and hide it (put another blackboard over it or close the “sides” of the blackboard; depending on the room) and reveal it only at this stage.

based on playtesting: It might be very advantageous

  • approximately: each team can do at most 3 tasks per sprint ;)

Estimating and detailing (20 minutes)

Estimating (4 minutes)

  • swimlane sizing
backlog | 1    | 2   | 3    | 5   | 8    |
------------------------------------------
school  |      | ...
hospital|  ?   |house| ...  
...     |      | ...
  • agree that the basic house is 2 or 3 (doesn’t matter which)
  • two representatives from each team (that they trust the most)
  • SILENT SORTING for 2-3 minutes
    • the representatives cannot talk to each other!
  • everybody can move only one card
  • ask the rest of the participants:
    • what have you observed? (~80% of tickets didn’t move, the rest was constantly moving back and forth)

Parallel detailing (13 minutes)

  • each team 1 ticket per minute (apx?)

  • in parallel, the teams play a version of planning poker:

    • discussion facilitated by SM!
    • pick an some unrefined item
    • in a team, agree on its estimate
    • clarify open questions
    • write details on a yellow post-it and attach it to the task

hints:

  • ask teams to attach details to each story when they get clarifications from PO
    • (as it may be another team building the item)
  • actively encourage and appreciate team members asking clarifying questions which help define size
  • once estimated, the story needs to be put on the wall so that other teams can benefit from new information

Reprioritizing (3 minutes)

as a PO, reprioritize based on the following thinking:

  • landscape-specific items first to understand the plan of the city
  • do simple elements earlier
  • when we know how the city looks like schematically and we are solid at building simple elements, we can work on more complex yet important stuff (presentation hall, hotel, etc.)
  • and lastly (if we have time) let’s work on additional things (like a shop, a dining hall, etc.)

In-game: Building the Product

based on playtesting: Skip the third sprint. It’s sad, but at least they’ll do the second review and retro properly. It’s much more important to get to the “Lessons Learned” section!!! :)

  • Don’t tell them this in advance, just plan for three sprints and then cut it off early ;)

Sprint Planning (3 minutes)

...     | TODO | In progress | Done |
product | sprint backlog team 1     |
backlog | ------------------------- |
...     | sprint backlog team 2     |
  • product backlog on the left, priorities: top-bottom, right-to-left (implicit)
  • teams pull from shared product backlog to their sprint backlog
    • while coordinating with other teams
  • if there are only a few people, call everybody in
  • if there are too many, call two random representatives from each team
    • NOT THE SCRUM MASTERS!!!

The team should believe this about the sprint plan:

  • “Based on what we know this Sprint Backlog represents the scope of work that we think that best helps to achieve the Sprint Goal”.
  • “We believe we can achieve it the given time-box of a Sprint with the agreed Definition of Done in mind”.
  • “As soon as we figure out that this plans is no longer feasible, we call to re-adjust the plan with whoever is affected”.

TLDR: Sprint plan = forecast, NOT commitment!

Confidence voting

based on playtesting: we skipped this, but you can do it ;)

  • Scrum Masters facilitate this in their team.
  • Each team member raises either a fist (= confidence 0 = no confidence) or some number of fingers (confidence 5 = absolute)
  • If team members show twos and threes, replanning needs to happen.
  • Facilitating question: “What needs to change so that you’re able to give higher confidence vote?”

Building (7 minutes)

They finally get to play with LEGO for a few minutes!

What does the PO do during the sprint?

  • Either stay in room and be ready for clarification
  • or leave the room (go for a business trip) to aplify learning.

First sprint, the PO leaves the room => turn it into a point in the retro: “Does your PO know what teams expect from them during a sprint? Let’s discuss it and make an explicit agreement from now on.”

Sprint Review (5 minutes)

  • All teams and PO together.
  • After first sprint, jump on a table in the middle of the room and shout: “Where is my city?!!“.
  • Gοοd questions to ask as a PO:
    • What do you guys see here?
    • How do you like the product we are building?
    • This is what I come to think while looking at this …
    • Will you agree that this looks …?
    • What is missing and misaligned?
    • Imagine, you are a user X entering this building …
    • How comfortable will it be for our users?
  • Then derive concrete TODO’s to be taken to the backlog (and hopefully to the next sprints)

Sprint Retrospective (5 = 3 + 2 minutes)

To help create a positive habit of constant process improvements driven by the teams.

  • give the teams few minutes for a quick internal team’s retrospectives
  • once they are done, merge for a blitz overall all-in retrospective

Team Retrospective (3 minutes)

  • tutor asks teams to go back to their working areas and spend a few minutes reflecting on the process
  • SM leads the conversation
  • questions SM asks:
    • what went well? (👍)
    • what didn’t go well? (👎)
    • what can be improved? (➕)

chart:

sprint | thumbs up | thumbs down | plus 
-------------------------------------
1      |           |             |  
2      |           |             |
...

more detailed questions:

  • what worked well?
  • what needs to be changed in the next sprint to make sure more items get to ‘done’ by the end of the Sprint?
  • and how can we make the flow more continuous so that items get inspected, improved and deployed one by one?
  • what else need to be adjusted in the process?

Visualising the product progress

While Team Retro is happening, draw a release burndown / velocity / … chart. Summarize:

  • how much work is in the product backlog? (sum of estimates)
  • how much work has been accepted cumulatively in the sprint?
  • what is the trend?

Overall Retrospective (2 minutes)

  • merge the discussion back
  • ask:
    • “Please share one key thing that you’re planning to do differently next time. Which issue is it adressing?”
  • then focus on overall organization:
    • How can you improve team’s coordination and collaboration?
    • What do you want to ask the Product Owner to start doing, keep doing or stop doing?
    • How else can we improve the overall throughput?
    • How can we make sure more work is of acceptable quality by the end of the next Sprint?

Post-game: Debrief

Clean-up (5 minutes)

They should:

  • split the lego apart and put it back
  • put the cheatsheets back
  • put the tasks back

If you can over the noise, review the game chronologically. Let them breathe though ;)

Lessons learned (10 minutes)

to amplify lessons learned and help participants see what helped them achieve the results despite of the inherent complexity of the problem

Each team on a flip-chart paper:

  • WHAT did you notice?
  • WHY did it work that way?
  • HOW can you apply it in the Teamprojekt?

Then ask the teams to share (a few answers is enough)

Note This is the most important part of the whole exercise. They need to explicitly think about what they learned! Rather skip other parts than this, please 😇

Jirka’s observations from WS22

With respect to the tutorial, here are my observations:

  • it took us about 100 minutes (1 hour 40 minutes)
    • we did only 2 sprints
  • the most important part is the “Lessons Learned”, feel free to rush a little just so they have the general retrospective
  • they of course forgot the integration table for the city in the first sprint review, but that’s expected
  • I didn’t accept anything in the very first sprint since the river was made out of blocks and there were no roads – make that a Learning Moment :tm:
    • they really need to ask the PO
  • after the first sprint, I moved some tickets to the second release to show them that not everything needs to be done in the same release (and that as a PO, I can change my mind about the importance of tickets)
  • during detailing, explicitly tell them to ask the PO questions (the people in the tutorial today did not think of that themselves!)
  • there were 8 people in the tutorial which went well, but the game might be more difficult with fewer people – let the students know what’s going on in advance, maybe even ask them how many are arriving to the tutorial
  • it’s a stressful role even for the facilitator (that’s you 🫣), make sure to read through the guidelines beforehand and ask questions if it’s unclear
  • still pretend like there are going to be three sprints even though you’ll only do two – that way they will actually do the retrospective correctly! :)