I love working with my colleagues! Bouncing ideas off of each other, using my knowledge to supplement the knowledge of the person, or people, that I am working with, using our combined intellects and talents to solve a complex business or technical puzzle… basically, I love working in a close-knit team!
It's just a shame that it hasn't happened in my career as often as I would have liked it to...
After all, how many people reading this have teams where everyone is working on something either subtly different from each other (same project, different feature or each person claiming a story), or maybe something totally different from each other (an entirely different project maybe)?
Over the course of my career I can't remember how many times I have had to endure this situation. In theory you are in a team, but no one else knows what you are working on, no one could jump in to help at a moments notice, and nobody knows the status of anything other than their own work as a result.
In these situations, I tend not to think of it as a team, but a collection of individuals who just happen to be working at the same island of desks as each other. And if we are (sic: not) doing Scrum then you end up being forced to listen to others talk about something that you have no involvement in, and forced to tell others about something they have no involvement in. Which just means that the daily scrums become a mind numbing exercise. (Again, does that sound familiar to anyone)
These situations are just not fun.
But what, you ask, has this got to do with pairing?
Well...
One way to deal with this is to pair or mob with your teammates. Working together, really together, to solve a problem, at one machine, whilst also helping guard against finding coding issues too late in the game to easily deal with - late in the game because your PR is the first time someone else looks at your work.
When done right this can have a plethora of advantages. Starting with actually working with your team mates, and not just working in the same room as them. Solving problems together, rather than working in your own bubble. Having someone review your work as you produce it, and not at a later unconnected stage. And many more besides.
Only... How often does it actually work out that way for people?
Not often enough from my experience talking to people.
Starting point: Sleepy Pairing
When I talk to people about pairing I often get the same answer:
But that is wasting our time. Two developers at one machine. You are not going to produce twice as much. It's pointless.
Or words to that effect.
And you know what? Going by my personal experience, far too often they're right.
Because often what I have seen is what I call: sleepy pairing.
We've all seen it:
- Two or more people behind one computer
- One person at the keyboard feverishly working away
- One person maybe silently looking over their shoulder, making them really uncomfortable
- One person maybe sitting a meter or more away playing with their phone, occasionally glancing up at the screen and grunting 'yup' before returning to Facebook, Twitter, random website or shooting zombies
At the end of the pairing session you have:
- A driver who is exhausted and not had much help with the heavy lifting solving the problems of the day
- One person who is mentally exhausted, and feeling useless at the same time
- Maybe another with an awesome score on zombie killers, but also a gnawing feeling that maybe they could have been more use
Kind of like at the end of a long journey. The driver has been concentrating the whole day, watching the road and trying to keep everyone safe, trying to remember which way they need to go and looking for traffic problems as well.
And the passengers are either struggling to stay awake, making the driver really uncomfortable watching their every move, or, if they are lucky enough not to suffer from motion sickness, watching their phone the whole time.
And so the next day they go back to their own machines, put on their noise cancelling headphones, and go back to working individually. Everyone feeling that the previous day was a waste, as is pairing in general.
But maybe there is something that we can do to change this scenario to make it not only worthwhile to pair, but to actually produce something that is better than the sum of the parts.
Step 1: Have a driver and navigator(s)
Making this distinction immediately brings benefits to pairing!
The idea that one person has the keyboard (the driver), the other (the navigator) is solving the problem immediately fosters investment from both involved (with mobbing you may not yet have everyone on board, but you'll still see the improvement).
Now, neither the yupper nor the zombie killer can do either of those things.
They have to be actively involved in the solution or the driver can't drive.
Active involvement on both parties!
Working together to solve problems, the navigator(s) coming up with ideas, figuring out how to solve the problems, and the driver listening to what they need to create at the keyboard.
Sounds idyllic!
But wait... I've also seen this cause problems...
We now have the people around the typist being actively involved. No more yupping, no more zombies.
Only there is a zombie. Its the typist. Sitting banging in the words that the navigators tell them type. But not thinking about what they are typing into the computer.
Have you seen stories about drivers ending up at the wrong destination because they took everything their navigation systems told them without thinking. Drivers that have ended up in water, or fields, or just totally lost. The navigation system just says 'you have arrived' and the driver thinks, 'Well, maybe, but arrived where and how, and why are my feet wet?'
Now, at the end of the day we now have one exhausted person who has done the thinking, but they have also been held up having to wait for the other person to type.
And one person who has blindly bashed the keys to get the words into the machine who is also exhausted. Yesterday the typist was exhausted after working, now they are exhausted thinking that they did not become a software developer just to type words.
And so the next day they go back to their machines, put on their noise cancelling headphones and go back to working individually. At best pairing is something only for the most difficult problems, at worst the previous day was a waste, as is pairing so let's just ignore it.
So now we have better participation from all parties, and yet there is still a fundamental disconnect between them and the work that they are producing. Sure, we're better than we were, but we're still not working as a close-knit team!
So... What else can we do?
Step 2: Make the pairing strong!
The problem with the driver / navigator scenario is that too many people think that as long as you have those roles everything is going to suddenly fall into place, as with the example above. But if you are not bouncing ideas between each other then you are missing the main advantage of working this way!
Whilst having these roles does give more benefit than simply yupping, it's not the whole deal.
You see, when driving, your role is not to blindly follow navigations without thought. Your job is to listen to the navigation and then do what you need to do to safely arrive at your destination.
In strong pairing your role as driver is not to blindly type the words of the other into the computer, it's to take those thoughts and turn them into something useful!
No, to get the real benefit from pairing you need to take it to the next level. Let's revisit those definitions
- Navigator: Someone who comes up with ideas, solutions and explains them to the driver
- Driver: Someone who asks the questions needed to comprehend the solution offered by the navigator. Someone to play devils advocate even when you understand something, even when you agree with something, to ensure that you are not both blinkered in the same way
Most of us are not going to learn much, or find our work fulfilling, by someone telling us what classes to create, and where. What to put into that class, what properties to create.
No, what most people want, and need, to know in order to be a truly active member of a team is to know what someone is thinking. What solution do you have in your head? Why do you want this interface here? Why do you want to expose those properties to the outside world?
We want to question the other persons assumptions, question whether they have considered alternatives. Question whether or not we have gone down the rabbit hole and gotten lost, and what do we need to do to climb out again!
And, as a driver, you may get that moment of clarity and flash of inspiration - based on what you've been talking about you know exactly how to solve this problem!
This is where the practice gets hard...
You *DO NOT* simply start working.
You excitedly give the keyboard and mouse to the navigator, tell them you have a brilliant idea, and switch roles. This is maybe the most difficult part of the whole process! Really, you need to understand just how much you are going to want to just start typing. But without doing it you fall back into sleepy pairing really quickly, and without even noticing!
And don't think that the navigator has it any easier here. More than once I have had a navigator ask for the keyboard so that they can just quickly do something. And each time I say: No, but you can explain it to me so that I can do it.
Now we have two or more people who are actively working with each other, bouncing ideas off each other, and challenging solutions to make sure that we have the very best solution possible.
And we move from the 'just give me the keyboard' mind set, fighting over who gets to have the keyboard, and into a much more enjoyable place where we are fighting trying to give away the keyboard to move forwards!
And if we are doing that, then the PR should be ultra simple. Our entire session was a code review. As we created or altered code we are reviewing the ideas and architecture as we go. When we make commits we revalidate those ideas together, making sure that what we are going to put to master, is really what we want to put to master.
(So no context switching to get our PR completed, and no late feedback that says the solution is maybe not what you want to be putting to production!)
This is Strong Pairing as I experience it!
Now at the end of the day we have two people, maybe more, who are exhausted. But also excited! Because they have made something awesome. Got some amazing insights into what they are doing, how their team mates think and they have a story finished as a team. Together. And, even through the exhaustion, this gives them the energy to think: tomorrow is going to be another awesome day working with these folks!
Top comments (0)