Transcripted Summary
A lot of the downsides of asynchronous work can be mitigated by working in pairs. You can reduce knowledge silos by actively sharing knowledge, different skills, expertise we have, and lots of implicit knowledge too. The things we were not aware that the other one won't know them but will help get more knowledgeable or efficient.
Also, you don't have to wait for the other one if you pair on the same task. Pairing is very useful for getting things done, including everything needed. You always have the other one keeping you focused and disciplined.
It can also be very intense, so frequent breaks are good and can be used for socializing as well.
There are different styles of pairing.
A more traditional style versus a so-called strong style. It can be very formal or informal.
Teams might have different setups. For example, both sitting in front of the same computer with one keyboard. Or both sitting in front of a pairing station with two keyboards. Some might even use two computers.
Some pairs work collocated, locally, some pair up remotely. Remote pairing is no problem anymore as nowadays we have tools that allow screen control sharing.
For this course let me elaborate a bit on the traditional versus the strong style of pairing. Check out the linked resources in case you'd like to read more.
The rather traditional idea of pairing is to have one at the keyboard — finding the way and doing the implementation—and the other one observing, reviewing, maybe taking notes. So, if you have an idea, you'd request the keyboard to implement it. This approach can work well.
The downside of it can be that the one observing can easily get disengaged or just lost. It requires a lot of energy to keep up with whatever the other one is doing, especially in case they don't share their intentions out loud.
In the strong-style way of pairing the dynamics are different. Here you have a navigator planning the next steps ahead and instructing the driver at the keyboard who takes care of implementation details. So, if you have an idea what to implement you would hand the keyboard over to the other one.
The golden rule for this style is the following — "for an idea to go from your hand into the computer it must go through someone else's hands".
The downside of this approach is that it takes some while until you find out how to guide the other one only with your voice, on the level of abstraction they need without taking control over the keyboard.
The benefit shows in the long run. Even if the driver might not understand what they're doing in the beginning, they will quickly learn as they get instructions and explanations. They will pick up all the details and learn by hands-on doing.
The key for any pairing style is to rotate frequently, while timeframes depend on your agreements and can be experimented with.
Pairing is a great way to combine your skills and knowledge and have both persons benefit from that, especially when you pair in different consolations, knowledge will spread across the team.
Pairing up is one preferred way of how to solve automation challenges in my current team where we don't have any automation expert.
We combine programming and testing expertise by having a developer and me as a tester to pair up. For example, we pair on writing automated integration tests. We have built up legacy and anti-patterns in our end-to-end tests through the UI, so we paired to iteratively revise them. Or we pair up on exploratory testing for our stories together where any found bugs can be fixed instantly.
Pairing will also teach both of you whatever you're doing. This is a bidirectional way of learning where implicit knowledge becomes obvious.
Pairing helps to generate more ideas and faster. For example, when you're exploring, or when you debug your code, or to come up with innovative solutions, pairs can really nicely complement each other. You can build upon each other's ideas and, you know, you will never get stuck.
Having a pair also makes you think. This way you can include different thoughts and viewpoints. Diversity challenges our own understanding and this way you can create a shared one.
Now, a word of warning, pairing can be great for learning, but for that to happen it has to feel safe.
Pairing should not be there to enforce any power dynamics, but rather to decrease them. More senior ones can help more junior ones grow and at the same time learn a lot from them as well.
If you share your vulnerabilities or fears in the beginning of a pairing session, this makes it safe to do the same for your pair.
To establish and maintain a culture where people can freely pair, learn from each other and speed things up with better quality, it takes constant effort.
Some people might not want to pair up with you. For example, in case developers do not want to test or manual testers don't want to learn automation, it takes time to change the mindset of the whole team.
What you can do is to look for allies and start a movement with them. Make the benefits transparent and obvious. More often than not this convinces others to give it a try themselves.
If your team constellation is changing and you get new people onboard, pairing might just be the way for getting them quickly onboarded and also showing them the benefits of close collaboration.
Pairing across teams can help on your automation journey (or basically any endeavor) as well.
You can pair up with other people of the same role and other teams of your company. For example, in your testing community, or you pair with other roles to learn from their side as well. This way you can learn new approaches and domains, provide a fresh perspective on another product, while still maintaining your cross-functional teams. A win-win situation for everybody!
Or you pair up with other people around the globe from the global community.
You might consider a testing tour or any other learning experiment you can come up with.
This is great in case you'd like to become a better skilled tester in general, or learn about certain tools, or dive deeper into special topics, or simply practice. This might be especially interesting in case you don't have anyone willing or available at your own company.
Collocation is not a requirement but an excuse here. Remote pair testing sessions can go very smoothly. You can even benefit from geographical dispersal because you get a more diverse perspective this way.
