Ingredients:

• IDE + Unit Testing tool
• Timer

Directions:

Programmer 1 writes a test and challenges Programmer 2 to make it pass. Programmer 2 attempts to make it pass in as short of time as possible and then writes another test to try to stump Programmer 1. This test could be to fill any gaps that were exploited in the previous test, or to test another part of the system. This continues until all features have been implemented. A winner can be chosen based on total time taken to make tests pass. After each test passes, both programmers collaborate to refactor the solution. This time does not count towards the final score.

Learning Points:

• This game highlights the essence of Test-Driven Development, by only writing code for failing tests.
• Programmers end up producing the simplest solution that works. They then must have the discipline to refactor the solution when code-smells emerge.

Posted by Mike

Ingredients:

• 20-30 balloons per team
• Supplies for each team: construction paper, rulers, scissors, markers

Directions:

Start by showing the teams a balloon that you would like created. The balloon has a face made up of two round eyes, a triangular nose, and a semi circle mouth. Without any further instructions, tell the teams that they have 2 minutes to create as many of the balloons as possible, then have them bring the balloons up to be ‘accepted’. Eliminate any balloons that do not meet your criteria of ~10 inches wide, ~2 inch eyes, ~1 inch gap between eyes, ~1.5 inch high nose, and ~4.5 inch wide mouth. Very few teams will have balloons that meet the criteria. As you reject their work (waste), ask the teams if they’ve ever had a similar experience in software development. Before the second round, give the teams 2 minutes to discuss how they can improve for the next iteration. They should start asking more questions about the acceptance criteria, which you will happily offer. When round 2 starts, the teams will now apply the acceptance criteria to their work and some will even start building ‘test harnesses’ (e.g. paper templates for face, quick ways to measure balloon width, etc.) . The results should be better in round 2. Discuss how they changed the way they worked and what improvements they would make the next time. If needed, play one more round. This time, every team should be using a test harness and should therefore be producing balloons with much more efficiency and quality.

Learning Points:

• Defining acceptance criteria is not the same as writing tests, only to be applied after something is produced. They can be used as requirements, as tests, and as a target for developers.
• Automating acceptance tests (or executable requirements) can be very useful, as demonstrated by the test harnesses produced during the game.
• The investment in creating and automating acceptance tests is worthwhile and has a high return.

Posted by Mike