Though a slightly frustrating method at first, peer programming can take collaboration and productivity in your agile projects to an entirely new level.
Many of you have experienced pair programming, a technique made popular by the introduction of XP, Extreme Programming. While Scrum does not explicitly identify engineering practices such as pair programming, this has indeed proved a good practice in the highly collaborative environment of Scrum teams. Many have tried, some have failed to make it work, others have had success. It is a difficult technique that often seems to be in conflict with both individual and corporate notions on how to get things done. It also puts pressure on the individual programmers to share their work and collaborate at a higher than normal degree.
Myself, I have worked on some projects as a pair programmer, and later coached teams that utilized pair programming to some extent, both with reasonable success. My own experience says that it works best when not enforced, so I usually try to create an environment where pair programming is encouraged, but not mandatory.
But why stop at the programmer?
In many teams, we distinguish between those who write the code, and the “other members” of the team. In doing so, we effectively build sub teams within our team, encouraging walls between them. This in turn introduces handovers, which we know from Lean principles is bad practice for our efficiency. Instead of building the code with quality from the start, we let someone else check the quality for us, and our capability to predict release content and make accurate estimates decreases.
This is where I would like to introduce Peer Programming. In peer programming, we encourage programmers and other members of the development team to collaborate directly. This would enable constellations such as test engineer+programmer, technical writer+programmer and usability engineer+programmer to name a few possible combinations.
Consider for instance the test engineer+programmer combination. The programmer now has someone at hand who can help with immediate testing of concepts and solutions, even down to the object level. Ten minutes of implementation can be followed by a direct proof of concept in the test environment. The test engineer on the other hand gets a continuous explanation on how backlog items are being implemented, and why, which surely beats reading specifications as quality assurance parameters can be weighted into all design decisions as they are being made. Instead of taking the long journey via the bug database, many bugs will now be caught directly during implementation.
Or consider the usability engineer+programmer combination. Instead of working traditionally with mock-ups and prototypes, the usability engineer can now model user input and design ideas directly on the evolving system, with actual system response times and constraints at hand, allowing the user interface to evolve between user needs and technical constraints.
I have done this myself. And believe me, it’s frustrating at first. Just as with test-driven development, it feels like an impediment at first, slowing the natural urge to thunder down the coding highway. I suddenly found myself in the situation having to explain everything I did to someone who did not have the insights in my brilliant solutions, and even worse, I often found flaws in my reasoning when explaining them out loud! Slowly, reality crept in. It’s not bad to have someone (in my case it was a test engineer) at hand who can constantly provide expertise in a field in which you are not all that comfortable, and it is definitely a benefit to get continuous testing as a part of the hourly work. I can tell you, it was a lot easier to sleep at night knowing that my design flaws were found at such an early stage!
Peer programming sends the signal that everyone contributes, that everyone in a multi-talented, cross functional team is needed in order to deliver working software of good quality at a steady pace. I always call everyone on my teams “developer”, because that’s what they are. They develop a product, in incremental fashion, whether they are graphical artists, test engineers, architects or programmers. Everyone has their specialty, but the level of collaboration is always kept high.
Peer programming creates headroom for prestige-less collaboration and follow-up on quality and results, and allows your team members to enhance each others skills.
And a catchy name to go as well.