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:

• Icebreaker
• Simple sort
• Conflict resolution
• One chair left
• Plane prototyping
• Parallel sort

Icebreaker

The purpose is to get to know your teammates and something specific about them. Sketch a teammate on a piece of paper and write a particular 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.

Simple sort

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 ensure how to prevent “the manager” from sitting down on that empty chair.

Plane prototyping

The purpose is to learn about some principles of agile teams (and, for example, Scrum as a framework). In several iterations, the “engineering” teams are asked to build paper “plane prototypes”. The product manager (called “product owner” in Scrum) calls 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 about how to improve.

1st iteration: the product manager asks to build a plane that can fly 5 meters away. The product manager intervenes while the teams are making, saying how to build the aircraft.

During the 1st review: the “test flight” of the plane, the product manager wanted to put two passengers (Lego people) in the plane; obviously, something he hadn’t told the teams before. The passengers don’t fit, or the plane crashes terribly if they fit.

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 come and stress 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 two 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; to deliver a “clean” prototype. The product managers announce that the CEO wants the brand “blue airlines” clearly visible on each plane during the building.

During the 3rd review, the final test flight, the product managers inspect the work. Some planes have been built from scratch. Most of them have some indication of “blue airlines”.

Observations:

Each team needs to self-organise. With some materials at hand, they ought to build planes. In most teams, there’s no cooperation. Each person starts 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 agile context figures out how to build (in the best possible way), given what has to be made.

At the 1st review: the arrival of the passengers. The teams were not informed beforehand. This illustrates the importance of agreeing upfront regarding the “confirmation” or “acceptance”. In case the plane needs to travel with passengers (or with any other cargo), this can be taken as product requirements for a subsequent iteration (but should not impact the acceptance of the product in this 1st iteration)

2nd iteration: the product manager pushes 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 on what can be done during the iteration. The team needs its space without interruptions to be as productive as possible.

At the 2nd review: the arrival of different ‘types’ of passengers. Again, the product manager is changing the requirements.

3rd iteration: a stakeholder (CEO) influences 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” to find the best-fit features that full-fills the vision. The demand for building the plane from scratch also does not fit the incremental product development approach. Some teams who had a decent prototype from the beginning did not start from scratch (and they shouldn’t).

Parallel sort

Another sorting algorithm is 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 an excellent 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!