Each Friday for the past couple of weeks I’ve been pair programming with one of the UI developers on the team at Hooroo. It’s not uncommon for development & test teams to partake in pair programming but it is certainly new for me in my product management role. The benefits have been clear and I would certainly recommend it.
Pair programming is an agile software development technique in which two developers work together at one workstation. One writes the code (referred to as the “driver“) while the other observes (known as the “navigator“). The roles switch frequently which increases knowledge sharing and the number of opportunities to review the current task.
I’ve found product manager & developer pairing requires a slightly different role for the “driver”. Instead of mainly writing code while being the “driver”, the product manager is able to “drive” by spending time with the developer clarifying desired feature or functionality detail. This allows the developer to observe, provide feedback, and continue to ask questions in the role of the “navigator”.
That opportunity to ask questions, clarify requirements, and provide direct feedback is special because it isn’t something developers always get the chance to do with their product manager.
For the product manager and developer, the role of the “navigator” is quite similar to regular pair programming as code is being written by the developer and the impact to the UI of the feature being developed is still reviewed constantly. The conversation isn’t as technical as it would be with two developers pairing but it’s important for product managers to have at least a minor technical understanding of various programming languages and pairing is a great way to progress that.
After spending a couple of days over the last few weeks pair programming with a developer, I’ve found the main benefits to be:
- Higher levels of focus on the feature/functionality being delivered
- Fewer interruptions and distractions
- When interrupted, the “navigator” (quite often the product manager) can deal with the problem while the “driver” (more often the developer) continues on
- Higher levels of satisfaction finishing up at the end of a day
- Closer working relationships with teammates
- Greater knowledge amongst the team on objectives and product development plans