The 4th edition of the Agile Belgium games night was quite exciting! Thanks to all participants and special thanks to VRT for hosting the event.
Our games backlog:
- Simple sort
- Conflict resolution
- One chair left
- Plane prototyping
- Parallel sort
The purpose if to get to know your team mates and something specific about them. Sketch a teammate on a piece of paper and write a specific keyword on the back of the paper (something “curious” about the person). Put all papers up on the wall and let the group figure out who is who.
Everyone in a queue and sort the queue by a specific characteristic. A sort can only sequentially happen with the person before and after you.
One chair left
There’s one empty chair and the team must make sure how to prevent “the manager” from sitting down on that empty chair.
The purpose is to learn about some principles of agile teams (and for example Scrum as a framework). The “engineering” teams are asked to build paper “plane prototypes” in several iterations. The product manager (called “product owner” in Scrum) is calling the shots.
How we’ve played it: 3 iterations (of 4 minutes each). For the sake of the game flow and to keep the game short, there’s no retrospective after each iteration; but as the team moves to the next iteration they can think how to improve.
1st iteration: the product manager asks to build a plane that can fly 5 meters away. While the teams are building, the product manager intervenes saying how the plane should be built.
During the 1st review: the “test flight” of the plane, the product manager wants to put 2 passengers (Lego people) in the plane; obviously something he hadn’t told the teams before. The passengers don’t fit, or if they fit, the plane crashes terribly.
2nd iteration: same expectations: a plane that can fly 5 meters away, this time clearly with 2 passengers on board. During the building, the product managers comes and stresses the team with upcoming deadlines, customer complaints regarding the previous test flight, etc. The expectations are very high.
During the 2nd review, the product manager expects 2 passengers to get aboard, this time “paper” people (while everybody was working on figuring out how to make a plane fly with “heavy” Lego people).
3rd iteration: same expectations: a plane that can fly 5 meters away; but the product manager asks to start over from scratch; in order to deliver a “clean” prototype. During the building, the product managers announces that the CEO wants the brand “blue airlines” clearly visible on each plane.
During the 3rd review; the final test flight; the product managers inspects the work. Some planes have been built from scratch. Most of them have some sort of indication of “blue airlines”.
Each team needs to self-organise. With some materials at hand, they are ought to build planes. In most teams there’s no cooperation. Each person start to create a paper plane individually. Only in the subsequent iterations there’s more teamwork to build a plane together.
1st iteration: the product manager is intervening and telling the team how to do the work. A self-organising team in an agile context figures out for themselves how to build (in the best possible way), given what has to be built.
At the 1st review: arrival of the passengers. The teams were not informed beforehand. This illustrates the importance of agreeing upfront regarding the “confirmation” or “acceptance” of the product. In case the plane needs to travel with passengers (or with any other cargo), this can be taken as a product requirements for a next iteration (but should not impact the acceptance of the product in this 1st iteration)
2nd iteration: the product manager is pushing the team (annoying, and frequently happening in software/product development). Pushing the team will not lead to a better product, on the contrary. The team must react appropriately to agree with the product manager what can be done during the iteration and that the team needs its space without interruptions to be as productive as possible.
At the 2nd review: arrival of different ‘type’ of passengers. Again, the product manager is changing the requirements.
3rd iteration: a stakeholder (CEO) is influencing the team: if “blue airlines” is that important, the team must know this element upfront. To know a company vision or product vision is essential. It gives a team a guide, while the team can still own part of the “problem” and “solution” in order find the best-fit features that full-fills the vision. As well, the demand to build the plane from scratch, does not fit with the incremental product development approach. Some teams who had a decent prototype from the beginning did not start from scratch (and they shouldn’t).
Another sorting algorithm illustrated by physical moving; this one sorts “the numbers” from small to large in parallel.
Computer Science Unplugged (http://csunplugged.org) is the source of the two sorting algorithms. CSunplugged is a great resource for games, simulations to learn about computer science… without a computer.
Thanks to VRT for hosting this Agile Belgium session. See you at the next session!