Pair Chain Exercise

When I facilitate a kata session with a group of developers, sometimes I like to mix it up a little. If the room feels like it’s getting a little bored with a format, or if it’s a sunny Friday afternoon and everyone’s anticipating the weekend, I like to raise the energy level up a little.

In my experience, this exercise works well with 5-15 participants.

Timeframe: 60m total - 45-50m exercise, 10-15m retrospective Group Size: 5-15 participants Room Setup: Single computer on projector at front of room, IDE loaded and ready with empty or template project

Choose a moderate code kata like Bowling or Gilded Rose. FizzBuzz is too simple, we want to stress both solving the problem as well as the approach to solving the problem.

Start with a pair, pilot and co-pilot on the projector beginning the problem.

Every 2 minutes, the pilot leaves the computer, the co-pilot takes over the pilot chair, and a new co-pilot goes up to the front. Rotate through the room in the same order so that every person spends some time at the keyboard, many times.

As the facilitator, you should focus more on room dynamics than prompting constraints or hinting at a solution path (the room chaos should be constraint enough). Call out when someone could look something up, when the pair has 10 seconds left, when a whiteboard diagram might be helpful (the room might do it while the pair codes, or the pair can do it if it’s an impediment).

This should make for a fast-paced and fun session! Hopefully you’re going to see some laughing, lots of unfinished thoughts, the room directing novice developers what to type, some disagreements on approach, and a generally messy room for the duration of the session.

I’ve seen a few interesting dynamics surface during these sessions:

• sometimes a pair may choose not to code, and use a whiteboard instead to work out a problem, or sketch a path
• sometimes performance anxiety takes hold and folks who feel like they fumble at the keyboard sometimes get to watch their mentors fumble too, use this opportunity to raise the visibility of feelings like safety, forgiveness, humility
• the time that any “code heros” have at the keyboard is extremely limited, so this should minimize their dominance over the solution, encourage them to support the team
• try and keep the room focused on what’s going on at the front, gently discourage side conversations and try to bring them out to the room
• sometimes someone will open their laptop and do a bit of “research” on solving the problem, encourage a pair to spend a cycle pulling up that page and discussing what’s there (like a micro-spike), or encourage room discussion around the item
• depending on the mix of folks in the room, see if you can identify the folks that zone in alone on a problem, the folks that pair up or group-think a problem
• watch for developers getting up and “undoing” a bunch of previous work, try to encourage “one way flow” along a path towards a solution

Take note of the patterns you see and any notable aspects of the room dynamics for the retrospective.