Archive for the ‘Agile and SCRUM’ Category

A Nice Pair

So lately we’ve been fetching around for a way to take advantage of Pair Programming that would work for us.  Some of our projects involve building relatively simple web sites.  Often times, we’re building on top of a platform like Joomla, WordPress, Drupal, or Elgg, or we’re using pre-existing patterns and/or classes.  In these cases, when we were pair programming, there were long periods where one of the programmers would be staring off into space while the other was installing a plug-in, fidgeting with a CSS file, or some other pedestrian bit of work.  On the other hand, when we weren’t pair programming, we’d see programmers get stuck on a particularly thorny bit of code, architect themselves into a box, or miss a critical shortcut.

.

What to do?  Pair programming seemed like overkill but without it, we were often spinning our wheels.  Enter the “Agave Lab Method”.  Here’s how it works:

1. Programmers work in pairs.
2. Each pair is given two projects.
3. Every morning, the pair spends 3 hours together, with 1.5 hours dedicated to each project
4. After the 3 hours in the morning, each programmer works on a project solo for the rest of the day
5. The next day, the same thing happens EXCEPT, after the three hours working together, the programmers switch projects.
6. So, for example, on Monday programmer 1 works on project A while programmer 2 works on project B.  On Tuesday programmer 1 works on project B and programmer 2 works on project A. On Wednesday, we switch back.

Okay, I know that this sounds weird and complicated but stay with me here.  Every morning, programmer A has to explain to programmer B what he/she did the day before so that he/she can pick up from where things were left off.  In addition, each programmer needs to plan out, with the help of his/her partner, what he/she intends to accomplish that day.  This forces the right things to happen:

• It forces the code into intelligible form.  If you know that someone else is going to pick up where you left off, your code has to be clean, logical, and well-documented
• Two heads are better than one.  Solutions are first architected (and later reviewed) with input from two people - this leads to more elegant code.
• A set of fresh eyes can spot potential bugs, and offer suggestions on how to re-factor cumbersome elements
• Knowledge transfer is maximized
• Boredom / burnout is diminished
• Programmers get better at verbally communicating what they’re doing, why, and where they’re having problems
• If there is a particularly thorny bit of code, the pair can co-program during the 1.5 hours of shared time, leaving the more understood programming tasks for solo time in the afternoon.

Of course all of these benefits flow from standard pair programming and, for more complicated projects, we’ll still do full-time pair programming.  However, by using this modified approach, we get more throughput (progress on 2 projects rather than 1) and less staring-at-the-wall time for those projects that involve a lot of straight-forward implementation.