MyPairingPal: An Occasional Gift to Our Clients
Sometime ago Rysiek—one of our developers—had some time between a couple engagements for clients. While typically we talk about slack time triggered by WIP limits, at Lunar Logic we refer to it in a broader context too: when someone is between projects and not only between tasks. The only guidance we have when it comes to utilizing slack time is we can do whatever the heck we want. So what did Rysiek do? He moved his chair to Mat’s desk and started pair-programming with him.
What’s so special about that? Well, not that much unless you take into account that Mat was on a billed project for one of our clients and there has been no budget whatsoever to pay for yet another developer in that gig.
The thing was that Rysiek didn’t try to make himself billed. He made an attempt to make himself useful and learn something new. He had never worked with Mat before. Rysiek figured that he can learn a trick or two from a colleague, even if that colleague was a bit less experienced. What’s more Rysiek developed an opinion about Mat and his skills (and vice versa). Finally, Rysiek made some valuable contributions for a client.
That’s how the MyPairingPal Program was born.
The outcome of this ad-hoc experiment was all positive. Rysiek and Mat got immersed in the project instantaneously. Both were happy with how the collaboration went and how much they learned from each other and about each other. The pace of progress went up, too.
Of course, one can quickly uncover potential risks. While the whole arrangement was transparent for the client, they would bear no financial responsibility for having Rysiek involved in the work. As a result, it might have triggered expectation to sustain similar pace while Rysiek was gone to take care of his next gig. However, transparency itself was a pretty good mitigation strategy in the first place.
Long story short, we decided to make such arrangement an explicit option. It has always been an implicit option—after all we can do whatever the heck we want when on slack—but it doesn’t mean that everyone always would explicitly consider it. Not until now, that is.
The other reason is that formalizing the idea gives a nice explanation for our clients. This way they know what to expect.
So what is the MyPairingPal?
Our engineers, when they are in between projects, are free to join any other developer to pair-program. This isn’t a commitment of any sort. It may last as long as the engineer—pairing pal—decides. While it is highly likely that it will take at least a week, there are all sorts of things that may cut it short. It may be the pairing engineer’s decision. There may be another task that requires the attention of a developer (slacking people are our primary force to take care of such things). The start of an unexpected gig may also cut it short for the pairing pal.
From the client’s perspective, there’s no downside, though. We don’t attempt to have the pairing developer get into the whole context of a project. They will pair program, thus all the required context would be available. In our experience, pair-programming provides higher quality and more effective work. And our developers learn from each other.
The only word of advice is: enjoy while it lasts. By its definition a pairing pal’s help is temporary. Nevertheless, it is still a classic example of a win-win scenario.