Picture this: two people working on one keyboard with one driver. The driver is a developer who could do the work on their own. The other person is a tester/customer – they can contribute and shape the work – but they couldn’t work solo.
Our experience shows this brings value: in focus, outcome, understanding and efficiency. It is, however, different to developer:developer or developer:tester pairing. There is a desired imbalance in development skills, and the aim isn’t to remove the imbalance but to benefit from it. The non-developer won’t own the code or develop it further. They are involved in creation, decisions, and gaining understanding (for tests, features, use, risk). The developer gains external focus, assumption-checks, instant feedback, reduced friction and support in thinking.
Alex and Tim have been working like this for a few years, and Tim works like this directly with his customers.
In this talk, we have two messages:
- How to work like this
- How and where to use it
To get there, we’ll describe our collaboration in develoPairing:
- What develoPairing is and what knowledge and activities it involves
- What steps to take to start and cultivate this collaboration
- Comparisons to strong- and weak-styled pairing
- How to identify and approach a developer you want to work with
- What it means for the developer
- Where it helps projects and how to convince your project lead
You’ll take away steps to start or improve your own journey in develoPairing, regardless of role.