Timing:

Prep: Printing out the handouts

Activity: 45 – 60 minutes, depending on the size of the group

Materials:

Handouts, pads of paper (# attendees / 2), pens (same as pads of paper)

Instructions:

This activity will occur in two rounds. The first round involves each person in the audience working along. You will ask them to write a story about something interesting that happened to them at work recently. Give them five minutes to write. At the end of the five minutes, ask for volunteers to share their stories. Two or three should be sufficient. Expect that generally they will be somewhat mundane/pedestrian, and also be prepared that someone might be very funny or fascinating.

The second round involves pairing. Each pair will write a short story (fiction), based on “requirements” (see The Requirements below). The pair will take turns working on the story, alternating as indicated below.

Activity will be broken into two minute turns.

During each turn, one member of the pair will write, while the other will watch and ensure that the constraints are met (see The Rules below).

At the end of each turn, you will have them switch roles.

There will be seven turns.

At the end of the time (all seven turns), you will give them two more minutes to “refactor” their stories.  Then you will give as many pairs as possible an opportunity to read their stories aloud to the rest of the class. Expect a mix of boring/mundane (john said and then mary said) and incredibly creative/funny.

1. Introduce the setting: work, geography, industry, weather, time of day,…
2. Introduce character one: gender, name, age, education, single/married/paired/whatever
3. Introduce character two: gender, name, age, education, pet(s), hobbies
4. Introduce character one’s job
5. Conversation between One and Two about a problem at work
6. Manager appears and participates in conversation
7. All three go out for lunch: where, what kind of food, how do they get there

The Rules

• No sentences longer than twenty words – shoot for ten or less.
• Character names no more than two syllables.
• No paragraphs longer than five sentences.
• No “he said” and “she said” – must use names.
• No sentence may begin with “So” or “And” or “But”.
• Use adjectives judiciously.
• Locale must be a real place.

Gomez Goobers was a happy place to work. GG, as it is known in the industry, is in the heart of Chicago’s South Loop. In September, the weather was cooling off and people were walking the streets for pleasure.

GG’s lead programmer, Tim Thomas, loved living in Chicago. After college, he met Mary, whom he married two years later. Tim and Mary have been married for three years now. Tim and Mary live in a small, two-bedroom house in a nearby suburb of Chicago.

Tim’s counterpart was Billie Bliss, the lead QA. Billie, who is an avid dog lover, lives in town in an apartment overlooking the lake with her Beagle named Bugle. Everyone wonders where Billie got the money to afford a place like that. At twenty-five, she’s too young to have accumulated much. Her co-workers speculate, and her family and friends aren’t telling.

After completing both a bachelor’s and master’s degree in computer science, Tim came to work at GG. He loves technology, loves programming, and has progressed rapidly in the year and a half he’s been at GG. He has already worked in several programming languages and on several operating systems. These days, he’s focused on Ruby on Rails on a Linux platform.

Tim and Billie have been struggling with getting their teams to work together more effectively. Unfortunately, they are plagued by…

Decide who is going to write, and who is going to observe for the first turn.

Learning Points:

• Working in pairs produces results that we would never produce on our own
• Creativity is increased by pairing
• Pairing can be fun
• Pairing produces more effective results than working alone

Timing:

• Prep time: 30 – 60 minutes
• Execution time: 45 – 60 minutes

Materials:

One set of LEGO per team. Each set should include the necessary pieces to build a cube (see images in ZIP file) plus some random pieces. You can include base pieces or not. I don’t, because it adds to the challenge and the fun, having them figure out how to make the pieces stick together. Include at least a few flat pieces in each set, though, because it’s almost impossible without.

Instructions:

The participants should be divided into project teams that have between 4 and 8 people (smaller teams are preferable). Each project team should have two halves, call them left half and right half. Each half will have between 2 and 4 people. There should be as many project teams as necessary to include all participants.

Room = 15 people
Project Team = 5 people (3 project teams in room)
Left Half: 3 people
Right Half = 2 people

Here’s another way to split 15 people:

Project Team: 7 or 8 people (2 project teams)
Left Half: 4 people
Right Half: 3 or 4 people

With a group of 10 people:

This exercise will be done in two rounds. In round one (The Waterfall Way), the halves of each project team will build a specific object, using LEGO, based on a set of “specs” – three pictures of their finished “subsystem.”

In round two (Continuous Integration), the halves of each project team will build the same object, but in iterations, performing integration at the end of each iteration.

Both rounds lead to the same goal: at the end of the round, the two subsystems fit together cleanly to create the final “system.”

The pictures below reflect the finished “system.”

Each half of each project team (left and right) receives their specs, and is given 3 minutes to look over their LEGO and to discuss what they’re going to build.

Left Half builds the object specified in the set of specs named left-finished-xxx.pdf.

Right Half builds the object specified in the set of specs named right-finished-xxx.pdf.

• Neither pair gets to see the other pair’s specs
• Neither pair gets to see the other pair’s work in progress
• Both pairs first get to see the other pair’s “subsystem” when both pairs are done
• When both pairs are done, they will try to fit their subsystems together
• They will make modifications until they are successful
• Record the time when both pairs first say they’re done, and then record the time it takes to get the two subsystems to fit together (build time, integration time, total time)
• You will probably need to get the pairs or project teams to track their own times, depending on the size of your group
• Expect that the teams will not finish simultaneously, so track the time per team for build
• Expect that the two subsystems will not fit together properly – let them struggle with deciding which team should make which modifications
• Encourage them to talk about the “specs” and figure out how to get the subsystems to fit together properly
• Hopefully, this will be somewhat painful and frustrating for them

As with the Waterfall examples, the project teams will be divided into two halves.

This exercise will be conducted in five iterations.

Before starting this second half, give the following instructions:

For each iteration, there is a set of specs that incrementally add to the previous iteration’s results.

Iteration one is very simple – just a flat rectangle – in order to get them accustomed to building and working together in pairs, plus giving them their first experience of continuous integration with an easy one that can’t fail.

Before starting this exercise, have the pairs switch – that is, Pair Left becomes Pair Right and vice versa.

Each Iteration follows the same pattern:

1. Receive specs
2. 2 minutes to review and discuss specs
3. Build (they will record the time to build)
4. Integrate (they will record the time to integrate)

Instructions are the same as for the first exercise:

• Neither pair gets to see the other pair’s specs for each iteration
• Neither pair gets to see the other pair’s work in progress during an iteration
• Both pairs first get to see the other pair’s “subsystem” when both pairs are done in each iteration
• When both pairs are done, they will try to fit their subsystems together at the end of the iteration

At the end, they will total their build and integration times.

Learning Points: 

There is a bug in the specs. In the waterfall first round, the two halves cannot come together without a couple of tweaks. The same is true in round two, but they should get there more quickly.

• While it is expected that each Integration stage will take a bit longer than the last in round two, each should still be pretty quick
• One or more teams will not complete their cubes during round one. This is an opportunity for learning.
• Some may not finish in round two, but that’s less likely.
• Learning questions for the final debrief:
  • Did your team feel more confident in the product you were delivering each iteration?
  • How long was the integration phase in Waterfall compared to the total time spent in integration over the several XP iterations? (When overall time is roughly equal, this could be a key insight: XP teams have an easier time integrating even when the overall project timeline appears roughly identical to a waterfall Gantt chart)
  • Were there any features that could not be delivered in Waterfall because integration was too difficult/costly, whereas in XP the same features were delivered successfully?

Handouts and the slide deck I use are here: 

http://www.stevenlist.com/files/ciwithlego/continuous-integration-with-lego.zip