The answer is “Pairing”​; What was the question?

Promiscuous pairing — not just between developers — is cheaper, more effective and produces higher quality product than not pairing. In this post I discuss my real-life experiences of pairing to help demonstate this.

Anybody who knows me knows that I’m a big fan of pairing; not just XP pair programming, but pairing in a wider sense. Indeed, I have been known to use the phrase in the title on more than one occasion. The reason I believe in pairing is not just a philosophical one, however; I have experienced a lot of succesful pairing over the years, both pairing myself, and seeing others doing and benefiting from it.

So, here’s what I’ve experienced and seen…

I used to work — many years ago — for a TV company whose name is a colour. I was offered an interview to join a development team as front-end dev, was offered the post, and promptly turned it down. Pairing? Seriously? I didn’t want someone peering over my shoulder while I was coding! There’s nothing wrong with my coding skills; I’m a complete expert! How very dare they? Well, the Scrum Master for the team phoned me up and convinced me that this was the future. XP was all the rage and if you didn’t have “XP, agile, HTML5 and CSS3” on your CV (I didn’t, at the time), you were a dinosaur. I was convinced, and joined the team.

It was absolutely nothing like I expected…

We did mandatory, promiscuous pairing, swapping one of the pair every half day. And yes, it was mandatory — we paired on everything. If there were an odd number of people, one pair became a three! So, on day one, I was rather scarily pairing with (someone who would now be called) the DevOps guru and was building VMs for running tests and configuring F5 firewall rules. Day two, and I’m up to my armpits in something I’d never heard of before called Groovy on Grails and Hudson CI (I said it was a while back!…). We also strictly worked from the top of our (physical — only, on a whiteboard) backlog, so sometimes the next card to be started fell to a pair who knew nothing about the card! Scary times! However, within a couple of months, I could hold my own in the Groovy world, and nagios and mongo held no fears. I even knew what the “spaceship” and “Elvis” operators were in Java; yes — a front-end dev writing Java code! This is what pairing really gives you…

Knowledge had been shared. Hugely.

It was probably the best team I ever worked on. Everyone knew enough to have a go at any task; there was no “I’ll wait for a front-end card to jump on” or “I need a Java expert to pair with on this”; everybody would have a go at anything. We didn’t realise it, but we had psychological safety (I don’t think the phrase had been invented back then…); we failed — and learned — a lot! More importantly, we all knew how everything in the “system” worked, and worked together; servers, infrastructure, code, tests, SEO, security, logging — everything. Work didn’t stop just because there wasn’t a front-ender available. Support issues didn’t remain open just because the person who built something was off sick.

Also, there were no bottlenecks; whatever the next thing that needed doing was, whoever was available could do it. No cards backed up in QA waiting to be tested, no tasks stalled because DevOps (or whatever we called them back then…) hadn’t built the VM.

Exciting times.

So, it’s few years later, I’ve left behind the dev world, and become a Scrum Master. I’m looking for ways to improve the efficiency of the team. I realised that web pages, or features, are built by the team like this:

1. The UX/UI/Designer comes up with a wireframe/design/concept.
2. The devs build it; complaining all the time that the design isn’t “complete” — there’s a missing px width on a button, and some of the colurs aren’t in HEX, etc., etc.
3. It goes on to a test environment, and the PO has a look. He doesn’t like it (particularly that shade of blue on the button, and the wording’s wrong on the form…).
4. Go back to step 1

Slightly painful, but we were “agile”, so as long as we went round this cycle a few times and delivered something within a 2 week sprint, the team, and the business were pretty happy. I decided to ask the team if they were satisfied with this way of working, and if there might be a better way? Many discussions and suggestions, but the upshot was this — how about the UX/UI just pairs with a dev, and they co-create the pages/features together? Even better, why not have a pair of 3 (?) and have the PO there as well? No design sign-off, no PO review, no mini-waterfall! The first time they tried, it took 2 hours to get the feature built and released to live! They never looked back. Building stuff this quickly meant they could carry out many, many experiments with the customers, and apopt a truly agile/Lean UX approach to their work; they could get feedback from real customers within hours, not weeks.

It was not just quicker, though; the business saw rapid improvements in the leading metrics they were tracking towards their OKRs. This was because revenue-generating features were live and generating revenue quicker, and detrimental ideas were quickly quashed.

One final one. I worked as a Scrum Master for a large clothing and food chain, working mainly with the team developing mobile apps. They paired all the time — just seemed natural to them — and the PO sat with them and discussed things all day, every day. Unfortunately, the company decided to do an “agile maturity” assessment, and the team came out bottom; the worst team in the company! I, as scapegoat, was hauled over the coals and told the team never had standups or retros, their velocity was all over the place, and they wasted all that time because they were always pairing! Pull your socks up Scrum Master! I, of course, merely pointed out that they released at least once a day, had a 5 star rating in the app store, never had to rollback a release as they never released bugs and had increased their user base threefold in a small number of months. Unlike any of the “good” teams who’d released nothing, but had standups every day! But, once again, pairing was what gave them the edge; constant PO and dev collaboration meant everyone knew what they were doing and why, and they could make their best decisions based on that. No constant battle between “new features” (PO) and “tech debt” (devs), as everyone could relatively prioritise everything easily.

It occurs to me with these experiences, and others I’ve seen or discussed with people, that pairing is not just about code quality; the most important aspect, for me, is the knowedge sharing/transfer aspect. There are many reasons why this is a very good thing:

1. Avoiding silos and single points of failure. Work doesn’t need to stop if no-one is available in a particular role, and if someone falls ill, or leaves the team/company, everything can continue as normal. Also, documentation is often out of date as soon as you’ve written it, so relying on it can be risky. In a team where everyone knows everything, there is less need for documentation as there’s always someone who has the requisite knowledge.
2. Making better decisions. Increased knowledge leads to better decision making. As an example, if a dev has worked on the front end code that consumes an API, he can make better decisions when updating the API code as he knows the intent of the data being consumed. Both front and back end code can be co-created to be the most efficient.
3. Increasing consistency. If everyone pairs on all parts of the codebase, all automation scripts, all test definitions, all designs, etc. things end up consistent. This makes them more understandable and mantainable, without the need for highly prescriptive coding standards.
4. Moving it left. Pairing avoids the problems inherent in a “build then review” development paradigm. Instead of presenting someone with a fait accompli and asking them to review it, just pair with them at the start and agree how best to accomplish the task. This is far better than building something, then having someone review it — and sign it off! — when they know nothing about how or why it was built like it was.
5. Having the same vision/mission. The more far-reaching the pairing, the more the knowledge is spread, and the more likely it is that everyone understands the overall mission or vision of what is being built.
6. Nothing falls through the cracks. And, finally, if anybody in a team can do anything, nothing gets missed. If you only have front-end and back-end devs, who’s going to pick tasks around security? SEO? Who’s going to go down to Maplin’s to buy a cable? Who’s going to build that monitor to show the logs? In a proper pairing environment, stuff just always gets done…

Pairing does not need to be limited to a single team, of course; pairing outside the team is also highly beneficial. There will always be dependencies between teams — however much we try to remove them — and there will be occasions where one team need another team to do some work for them. What better way to make sure the other team fully understand what is required and why than by pairing with the developer in the other team doing the work and co-creating the solution? This, of course, doesn’t just apply to other dev teams; pairing with other teams — the SEO team, the security team, marketing, other stakeholders — can help build the right thing, in the right, secure, SEO-friendly way, first time. This avoids any mini-waterfall sign-off (tick-box reviewing) at the end. What is the best way to ensure some code is secure? Co-create it with a security expert, or present the expert with some code he’s never seen at the end? Which is the least risk?…

And, to re-iterate, the scope of pairing does not, and should not, be limited to developers or inside a team. As seen above, anybody pairing with anybody — devs, QA, POs, UX, marketing, security, SEO etc. etc. — can be beneficial. The more people know, the better decisions they can make, and the more they have a common understanding of the intent behind what they are doing.

The ultimate pairing, of course would be with the customer; what better way to find out what they actually want than by sitting down with them and co-creating what they want. This is rarely practical, of course — you usually can’t speak to all your customers at once — but any interaction can be valuable. Beta programs, customer workshops, interviews — all these help, and don’t limit them to just marketing and the PO; get everyone involved. And I leave you with a great example of this from a mobile network company I used to work with. People requested SIM cards, and we sent out thousands of them. A very small percentage, however, actually put them in their phones, however much we “improved” the registration journey on the web site. So, we got some customers in and the whole team sat down and went through the journey with them. The first thing they saw — it was difficult to get the old SIM out unless you had a pin handy! So people gave up at that point. Nobody had thought of this until we paired (collaborated) directly with the customers, and started putting pins in the packs we sent out.

Pairing — it’s not just for devs. T-shirts with this slogan available at the usual place… :-)

One final, final thought — if pairing is to work, it must be done all the time. I’ve worked in environments where the policy is “we pair when we need to” or “we pair when it’s a complex problem”, or some other caveat. This is a smell, and is not really pairing at all, IMHO. How do you know when you should pair? What if you do something on your own, and someone needs to change it when you’re on holiday? What if a simple probem ends up more complex than you thought it was? What if what you thought was the “obvious way of doing it” was, in fact, deprecated or otherwise wrong? You’re creating an uneccesary silo, and losing all the benefits of pairing. Pairing is a mindset, a way of life, “the norm”. If you don’t do it on everything, in my experience, you’ll avoid doing it more often than you do it, and those who avoid it are usually the ones who either need to do it, or would benefit from it the most.