Lego For Extended Scrum Simulation

www.scrumguides.com LEGO for extended SCRUM simulation Alexey Krivitsky, Feb 2009 alexey@scrumguides.com

Scrum simulation: looking for better games Over the last couple of years I’ve participated in and facilitated several CSM classes run by different trainers. All of those classes had different simulation sessions but I always felt like there should be better ones. Problems with some of the known games that I saw are: 1. Pre-prepared backlogs? To me, backlog is an excellent tool for collecting and discussing ideas that foster creativity. The backlogs are usually prepared by the trainer, printed on paper and handed out to the teams. Where were the creativity part of it? Do this, then to that. It is like a commanding. A mixed message to the Scrum newbies who have just (maybe) started to get why command and control is not always good? 2. What were we trying to build? In the backlog sometimes I see tasks to accomplish, not parts that make up a product. What will those tasks result in (when are accomplished)? Usually a big mess in the class room (smile). A mixed message to product development team? 3. Competing teams? Usually there were like 20 people in the class. So we help split the crowd into smaller teams so they had more fun playing the game. And of course each team in the end was competing to earn more score than the others. Aren’t we all talking a lot about building cooperative environment. A mixed message? 4. The metrics? During the planning cycles of the game, the teams were asked to estimate the backlog items. So they did. We asked them to keep track of their planned and observed velocity. So they did. But it seems to me the only thing they cared about was the score. They apparently didn’t apply velocity to plan releases nor they used it to double check their sprint plan. So they did it just because we asked them to keep track of the velocity. Not because they felt any need in it. Sounds like useless reporting to upper management (trainer in this case). A mixed message? There are probably more things to be pointed out. And of course those games have lots of great points! I just think there should be other games that illustrate better the things we try to teach. Hence I started to think of better simulations and have come across the idea of using LEGO bricks (thanks to William Wake, Jurgen De Smet, Yves Hanoulle, Mykola Gurov and other folks for opening my eyes!) The LEGO Scrum simulation Now after I’ve tried the LEGO Scrum simulation with different people and different cultures for several times I can say it seems to be more consistent with what I actually try to teach. Debriefing (you play games to debrief, right?) opens up a lot (and I mean really a lot) of nice discussions and brings bright insights to the folks. 2

How we play the game The Backlog I tried with the following backlog and it worked fine, though it will depend on your LEGO kits and imagination. Explain any details of the items only if you’re asked, otherwise don’t accept the item until properly (re)done. One-story building You can have as many as you want in the backlog. Two-story building Church A building made from bricks of one color that is a little higher than a one-story building and with a white cross on the top. Kiosk A small building with a shop assistant inside where you can buy small stuff like chewing gum. Kindergarten A building with a fence so that kids don’t run away. Lorry You will find instructions on how to build this and other machines in your LEGO manuals. Loader Tower crane Tractor Garage for lorry A simple garage where a lorry can fit it – acceptance criteria. I usually prioritize garages higher than the machines they should hold and will gently lead the folks to convince their PO that in order to demonstrate this item they need to build a machine first, hence helping the PO adjust priorities to get better products. Garage for tractor A simple garage where a tractor can fit in – acceptance criteria. Bus stop “As I a bus passenger I can wait for my bus for quite a long time and in bad weather”. This implies having a bench and a roof. Some of the items can be found in the LEGO instructions, some cannot. Which I believe is quite OK. For some features you can have detailed requirements from external parties, for some you don’t. So folks just have to ask questions to the PO (isn’t it what we want to teach them in the end?). If they don’t ask questions they can never get stuff like a bus stop accepted. The game is structured as a normal Scrum project according to the following cycle: 1. discussing project vision and the initial backlog 2. backlog estimation 3. backlog (re)prioritization 4. release planning 5. sprint planning 3

6. sprinting (so far we needed 3 sprints each time we played) 7. demonstration 8. retrospective 9. (the cycle repeats until you run out of bricks, time or the backlog) Visioning During this discussion I (as a PO) bring in a context: they all work for a big company with multiple teams involved and they are to build a city (a single product!). It is up to them to decide how to split into teams. Estimations They all act as one team (20 people can do that) and they need to estimate the backlog. They have their decks of planning poker cards and they have already practiced story point estimation by this time. What we want them to do is to estimate as fast as they can, but all the backlog items should be estimated in the same units so that we can have an integrated release planning. After some discussion they pick up a unit (a one-story building sounds like a good unit, say 2 points) and start by estimating the first 3-5 items together. After they all have the idea of the size and some estimated items for future triangulation we ask them to split into sub-teams and estimate the rest in parallel. Once a team gets a new item estimated they stick it to the wall into a corresponding column (by points) so that other teams have more data for triangulatios. So far this worked just nice. They can also prototype as much as they want (within the timeframe), but before the sprint starts all prototypes have to be disassembled (we discuss the value of throw-away prototypes). Re-prioritization After estimations are done as a PO I usually make small changes in the priorities (estimates can affect business decisions, otherwise why to estimate?). Release planning The goal is to have a big visible release burn-down chart so that all people understand where they are in the release and what the overall progress is. After the estimation session we put a first dot on the chart and start a sprint planning session. Sprint planning 4

We’d like to coach people working in multi-team environments on how to plan sprints. So we place a single product backlog on the wall (one sticky per item) and flip-chart sheets for sprint backlogs (one per sub-team). A timer starts (we set it for 5 minutes) and the sub-teams need to parse the product backlog by moving items onto their team’s sprint backlog. This goes until teams cannot commit to any more items (we learn commitment-based planning) One trick to mention here is that we have two sets of LEGO and each set can produce different machines (lorries, tractors, tower cranes, etc.). Which simply means that neither team that can build everything. This basically affects their sprint planning and, say, a lorry will show up on one team’s sprint backlog, while a tractor on the other’s. They are not allowed to exchange LEGO bricks during the game so they need to identify such constraints and dependencies during planning (which I believe is a good skill to learn). Sprint planning is the right time to discuss acceptance criteria, so when they choose to build a garage we ask them how would they go about demonstrating it. Probably they will have to build the machine first (this might make the PO move the machine higher on the backlog). For the first sprint they will most likely not discuss done criteria for the whole product increment (it should actually look like a city with streets and contain items built by all team!). We let them fail by not accepting the built items. (I believe failing and learning how to fix the issue is an extremely valuable exercise). 5

Outcomes of the sprint planning are: 1. expected velocity (we put a sticky on each team’s sprint backlog with the figure) 2. and team commitment (I ask the teams if they can commit to the selected stories, they usually can because planning was a team effort) 3. tasking (up to the teams if they want to do that, usually they have no time for that) Sprinting They sprint for 5 minutes (I usually project a stopwatch application on the wall or run it on my laptop). Playing back rock music in the class room might add some expressiveness. Demonstration & Retrospection We have 5 minutes for these two activities so they kind of flow into each other. When the sprint timer stops I loudly ask “So, where is my city?!” and they start to integrate their results… it usually takes time (to be discussed and fixed during next releases). Eventually they manage to demonstrate the city increment, of course with some bugs since they usually over-commit during the first sprint. I usually play bad here and don’t accept lots of features. They are asked to calculate their observed velocity. And of course they will try to convince me that a half-done thing gives them half points for the velocity. I don’t accept this unless the item really kind of works but has some missing unimportant details (lorry has a body, wheels and a cabin, but doesn’t have lights and other small stuff). This opens up nice discussions on calculating actual velocity. 6

One team was trying to prove to me their half-done building was almost ready (2 story points out of 3) and during the discussions it just fell apart. What a nice illustration! So during the next sprint they rebuilt it from scratch and earned their full 3 points (if I had agreed to give them 2 points out of 3, they would not have had the time to rebuild it from scratch and the quality would have suffered). The teams stick their observed velocity on the sprint backlogs. We also draw a velocity bar chart for each team. Unfinished items return from sprint backlogs onto the product backlog, we calculate total remaining points in the backlog and update our release burn-down chart. Here I start predicting their release completion (“Seems, in 3 sprints, you guys can release the whole city, we’ll know better soon after you finish your next sprint”). We discuss the value of being predictive rather than trying to do too much. And the cycle continues… Additional discussions Refactoring During one LEGO session a team built quite big buildings during the first sprint so they started to realize they would not have enough bricks to finish other items. They had to refactor (simplify!) the built buildings to be able to build more stuff. I didn’t want to have any refactoring card in the product backlog, so refactoring affected their velocity. If I had put the refactoring card in the backlog and let them estimate it, their velocity would have remained the same (!) though they would have built less stuff. You build less -> your velocity goes down. This was a nice insight for everyone Inter-team dependencies During another session a team could not accomplish their tower crane because some of its parts were on the other team’s table (oops, technical dependencies). The other team refused to spend some time on the tower crane, so the team failed to deliver it in the sprint. Later we debriefed this in detail and it appeared that the other team refused because they didn’t want their velocity to fall because of unplanned stuff coming from another team. Now what would have happened if we would have had individual velocities per each team member? The final words (for now) I’d highly recommend people teaching Scrum to go to the nearest LEGO shop and get some of the boxes. And yes, it is quite expensive stuff. But the sooner you get it the more ROI you and your trainees get in time. Good luck! And please send me feedback (alexey@scrumguides.com) - any comments, criticism, ideas, and debriefing details from the sessions are appreciated and welcomed. We all are learning here, right? 7

Links: LEGO information radiators http://www.infoq.com/news/2008/09/lego-information-radiators LEGO games by paircoaching http://www.paircoaching.net/games_en.php Discussion of LEGO as a Scrum simulation at scrumdevelopment group http://groups.yahoo.com/group/scrumdevelopment/message/36367 SCRUMguides’ web album with the photos from the LEGO workshops http://picasaweb.google.com/scrumguides/ScrumSimulationWithLEGO# Have fun! 8

http://www.scrumalliance.org	1584
http://www.scrum.com.ua	201
http://www.softwaretesten.net	136
http://www.scrumguides.com	92
http://www.lego4scrum.com	76
http://www.michaelhuebl.de	59
http://translate.googleusercontent.com	12
http://scrumalliance.org	5
http://www.lmodules.com	2
http://feeds2.feedburner.com	2
http://74.125.159.132	1
http://static.slidesharecdn.com	1
http://www.fachak.com	1

Lego For Extended Scrum Simulation

by krivitsky on Feb 22, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

13 Embeds 2,172

Statistics

Lego For Extended Scrum Simulation — Document Transcript