December 04, 2004
Pair Programming Workshop at XPDay 2004
From my own perspective and from the feedback I received from the participants after the workshop, I was really happy with how the session unfolded. In short, the 90 minute workshop consisted of:
- A quick 20 minute spurt of the theory around the role of Agile Coach as Change Agent, introducing XP into an organization or development team inexperienced in XP
- A 60 minute pair programming competition undertaken by the audience, working to complete a set of supplied acceptance tests for a written specification and a set of skeleton implementation and utility classes.
- A quick retrospective/summary at the end.
The biggest fear I had coming into the competition was that the set problem would be too big to finish completely within the allocated time and, as it turned out, the fear was well founded. Unfortunately, none of the five pairs in the competition successfully implemented all 5 acceptance tests, but the conclusion did see an exciting dead heat with three of the pairs having implemented the same number of tests at the end of the 60 minutes. The winner was decided by my co-presenter Joe Walnes, who did a quick inspection of each of the solutions.
The quality of the pairing was extremely high. Although most of the pair were formed on the day, they exhibited many of the signs of successful pairs from the outset. With each member equally unaware of the requirements until the beginning of the competition, there was an immediate need for the pairs to rapidly digest the specification which helped get the intra-pair communication flowing rapidly.
Joe and I, in our duel roles as on-site customer and coach, were very impressed with the ongoing communication, frequent driver/nagivator rotation and mix of tactical/operational thinking exhibited by the pairs.
The main points I took away from this exercise as Coach, based on observation of how the pairs tackled the exercise, were:
- You cannot overstate of the importance of incremental design enough. The acceptance tests were ordered in such a way as to promote a naturally evolving solution, yet a couple of the pairs still adopted a Big Design Up Front approach to get to the complete solution in one foul swoop.
- Knowledge of the available API can make a vital difference in developing quality working code to aggressive schedules. Several pairs lost quite an amount of time implementing functionality that had already been provided in the supplied code base. This was probably my biggest regret as we could have saved a lot of this time with a quick "make sure you look at the supplied code" type announcement up front.
The other mistake I made in planning the session was to underestimate the effort required to context-shift from being in a highly interactive, highly communicative mode back to a more passive one. For this reason, I basically gave up on the retrospective aspect of the workshop as it was obvious the audience was getting far more benefit from continuing to discuss the exercise amongst themselves rather than listen to me lead a more structured wrap up.
Ideally, I would have loved to conduct this workshop over a 3-hour period instead of 90 minutes, allowing sufficient time for a (slightly) juicier exercise and a fuller retrospective at the end.
Again, thanks to everyone who participated (especially Kent and Riaz, our VB developers who ended up winning the competition - sorry for the blurry photo guys) - I hope y'all got as much out of the exercise as I.
Posted by Andy Marks at December 4, 2004 06:21 PM
Post a comment
Thanks for signing in, . Now you can comment. (sign out)(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)