The Pairing Workshop v0.1

by sebsonconferences

The guys at jimdo were the first ones to invite me over for a workshop. We agreed on a training about Pair programming, a practice known from Extreme Programming. Jimdo really is drinking the agile cool aid (Kanban, Visual Management etc.) and the team seemed to be fond of a training on this very specific topic.

Preparations

The time-table

The time-table

The workshop had to be created from scratch. I have some experience with XP and the practices coming with it, but I never did a training on pairing. Some research on Amazon brought up Laurie Williams’s Book “Pair Programming Illuminated” that covers the topic in whole, contains all the needed references and lots of hints to further reading.

It took about 4 working days to come up with a concept based on the “Training from back of the room” technique, convert the theory part into activities and plan for practice as well. The two workshop days contained 6 hours of training per day, split into 12 units of 25 minutes.

Workshop materials

  • 11 Post-It blocks
  • 11 Edding markers
  • A Set of Stabilo pens
  • Index cards
  • 11 chairs
  • Tables
  • 5 Computers
  • 5-10 displays
  • 5-10 keyboards and mice
  • 2 Packs of Statys

More details of the contents and activities can be found in the “Waltz Wiki

Remark: There is a section with a training in the book, but I felt the theory part was a little underrepresented and the whole training seemed not to be suited for a group of 10 people.

Running the workshop

Pair drawing results

Pair drawing results

TFBR (Training from Back of the Room) proved it’s qualities again. But I had the Idea, given the relative small amount of TFBR activities, we could only do “brainstorming” ones. I was wrong about this. Very early on there was a comment about “Just writing Ideas with Post-Its agin?!?” the led me to change one or another activity later on.

The basic schedule was as follows

  • Day 1: Theory
    • Opener/Welcome/Rules/Goals
    • Intro to Pair Programming
    • Pair Draw
    • Combination of different skill levels
    • Intro- and extroverts
    • Good habits of pairing
    • Myth vs. fact game
    • Build the pairing workspaces
    • Pairing I – Fast switches
    • Pairing I – Fast switches
    • closing of Day 1
  • Day 2:Practice
    • Pairing II – Normal switch times
    • Pairing II – Normal switch times
    • Pairing II – Normal switch times
    • Recap
    • Pairing III – More pairing
    • Pairing III – More pairing
    • Pairing III – More pairing
    • Retro of the pairing activities
    • Dojo
    • Dojo
    • Dojo
    • Closing – Retro and Closing of the workshop
Pair-Programming

Pair-Programming

Especially Day 1 turned out to be very exhausting for the participants and when we had set up the workspaces there was first feedback that it was “enough”. I think this is a good thing and it seemed everyone had a a good idea of the theory at the end. Day 2 seems to be very dependent on the skill level and maturity of the developers attending the workshop. The team that attended this workshop had absolutely no needs for an explanation on the effects of test-driven development for example, they simply did this for a while already.

Results

I got a lot of feedback over the two days that will help me with that little tweaks the workshop still needs

The Good

I did a “Fist of five” rating on about half of the goals the participants had set (1 Bad – 5 Great). There was no score below 3 and most 4 or 5-ish. I deem that a success for a workshop that I ran the first time. The very mature development team helped me run the workshop and every section seemed to help people grasp the contents.

The Bad

Just a list of stuff I need to improve

  • I did not know the hardware setups well enough. There were no docking-stations for the notebooks, so we had no chance to setup a 2 screen pairing station
  • More variations on the “brainstorming part” needed
  • Day 2 needs a clearer goal from the beginning
  • The “Myth vs. Fact Game” needs to be more challenging and the contents more fun layout.
  • Opening the practice phase needs a time where participants can collect
  • Every developer needs 2 full days time to attend. This should be made more clear from my side before the workshop starts.

The Ugly

  • Going out for drinks after day 1 is a bad idea. Thanks to the team I could recover in the beginning of day 2. That set us a little behind schedule but there was a chance to catch up.
  • I am way behind in test-first development practice. Preaching wine and drinking water is not a good thing. Doing Katas now to fix that.
  • As trainer never switch to developer role in the dojo part.

Final Note

Looks like we had a lot of fun and the contents appealed to the participants. We will see how everyone is doing with the personal goals set in the closing. 2 days for the workshop was a very good guess and it is possible to hold a energetic workshop that sticks. I am pretty confident with little improvement here and there this will be a state of the art workshop.

Thanks go to all the Jimdo Team (lots of nice people), with special mentions of the CEO and @s0ehnke because they liked the idea of the waltz, trusted and invited the guy with the crazy idea over with little idea of the results. The participants really made this two days to remember. Guys the shouts for that workshop need to go out to you as well. You rocked.

This slideshow requires JavaScript.