Downloaded 22 times
Uploaded byCurtis Palmer
Ball point game
The document outlines rules for a game where a team must pass objects around in a circle according to several constraints: each person must touch each object within a set time period, objects cannot be passed directly left or right, and the starting point must equal the ending point. It also notes the game will be played over multiple iterations to chart estimates of throughput against actual results, with defects not counting until reworked.
More Related Content
![The fault in our [agile] Metaphors](https://cdn.slidesharecdn.com/ss_thumbnails/thefaultinourmetaphors-160928203612-thumbnail.jpg?width=640&height=640&fit=bounds)
Ball point game
- 1.
- 2. 1. Everyone ison the same team 2. Each person must contact each object during each round 3. Each object must independently have “air time” 4. No passes to your direct neighbor (to your left or right) 5. Start point = End point Estimate throughput (#objects) prior to each sprint AND measure Actuals achieved Several iterations/sprints Duration = 60 seconds 3 minute retrospectives Chart estimates vs. actuals Defects (objects dropped or that violate the rules) do not count towards DONE unless reworked 5 RULES OF THE GAME… Start in this formation: ©2012-2015 Genexodus Consulting
Editor's Notes
- #2 While the game is often played with whiffle balls, tennis balls, etc. you can choose whatever is handy. During Halloween or Valentines Day periods, you can pick up individually wrapped bags of candy – buy extra because the team members will almost certainly consume some during the retrospectives. Even sheets of paper individually crumpled into balls make for good objects, although their lack of mass mean that they don’t “pass” very far.
- #3 Run the system for 1 minute periods after estimating how effective the system will be and follow up with a retrospective about the results / consider ways to improve or change and replay over and over again as time allows (at least 3 or 4 should be sufficient with 1 more ‘imagined’, as if, as a way of wrapping up the understanding gained). RECOMMENDATION – although not a ‘rule’, start in the formation shown which complicates greatly the required passing pattern ... If someone objects, just tell them to try it this way first / by the 2nd iteration the team should object strenuously and you can point out that it’s just a good starting structure, not one of the “5 Rules”. Questions to ask after the iterations and retrospectives are complete: How much combined time was spent PLANNING vs. DOING and what was the combined COUNT?? – if you had used up that much time *in the beginning* to do BIG UP FRONT PLANNING and then used all the time spent *doing* using the master plan, how would your total COUNT be different? Why or why not? How did understanding/interpretation of the rules change from the first reading until the way you understand them now?? – note that the rules *never* change, but your ability to interpret them does How did the distance between team members change over time? How about the noise level and communication? How did the number of objects “in use” change from iteration to iteration? What happened to the results/defects when/if the team made too many changes from sprint to sprint? What would the results have been if an ‘expert’ in this game or a small group who had played it before tried to unduly influence the design early in the game play? Would the team learn? Variations to ‘complicate’ the game… Around the 3rd iteration when the team is making progress figuring things out – yell “STOP” halfway through and watch balls fall. This is like cancelling a Sprint – should only happen in the most extraordinary circumstances and even then the Scrum Master should interrup the person asking the work to stop and do some investigation about the validity of the work stoppage, protecting the team while they continue unabated until deeper understanding of the reason for the demand is achieved Introduce an irregular object (non-breakable!!) into the mix, swapping out an existing object out of someone’s hands – does the team self-correct to process the object or reject it as not allowed since the iteration had already started? Pull someone out expectedly mid-sprint (or announce during retrospective that one named person will be out for the final 30 seconds of the iteration) and see how the team adjusts the the planned/surprise change of resources – discuss how we deal with this during a 2 week iteration (planned vacation days, holiday, unplanned sickness, etc.) Introduce someone NEW to the team near the end of the planning between the 2nd and 3rd sprints and see how the team handles the new resources – the best solution is to sit the person aside to observe the next iteration and then figure out how to interleave the new person into the process (which will cause more disruption in earlier sprints than later) Play this game with large groups (12+) and the request will probably be made to break the group into smaller teams / this is NOT allowed in this particular game once started, but is worth discussing at the final retrospective because we value smaller highly functional teams and large groups usually require too much “passing” and higher level of communication.