Scaling through Pairing – Menlo #3

[This post is part of a series about Menlo Innovations, the company described in “Joy, Inc.“]

Cover of Joy, Inc. It’s quite common for my colleagues and me to pair. Not just developers, but also UX & dev, PO & UX, Customer Support & PO, … There are many combinations and I usually feel quite smug about our level of pair programming. Until I’ve read how rigorously they do it at Menlo Innovations:

Everyone pairs and they reshuffle the combinations Every Monday. Who pairs with whom is one of their most thought out processes and is assigned by project managers. You only work in your pair. You must not write code while your pair partner is away.

Frankly, to me that feels odd. That some project manager prescribes pairs; that I’m bound to that person and that it will be someone else every week. At sipgate we have stable teams so we always pair with the same few people. And we decide when to pair program and with whom.

Still, what Menlo gains with their rigorous practice is very attractive: The ability to scale. Fast. Up AND down. If they need to bring in more people into a project the existing members are “seeds”. They can all be paired with someone new to the project and effectively double (or half) the (wo)manpower within 1 week. That’s a huge advantage! Plus you avoid the dreaded towers of knowledge that are prevalent nowadays.

We don’t need to be able to scale that quickly because we’re not an agency, but if we were, I’d be reconsidering our pairing approach right about now.