#3 - TDD, Pair Programming, and Katas: How to overcome communication flaws.
If you find yourself trying to apply Pair Programming but failing to do so, it is probably because of a flaw in communication. A solution to this problem is to have a technique that helps you identify and correct any flaws in communication. This article will explain our approach, an example we encountered during our sessions, and how we resolved it.
The Retrospective Technique
A retrospective technique consists of analyzing each session to detect areas of improvement. There are many ways to apply retrospective techniques. Because we believe people either win or learn, we analyzed our sessions using three sections: what we did “Excellent,” what we did “Well,” and what areas we should “Improve”.
These sessions took around 10 min to finish. We also discovered that retrospectives are more effective if we do them just after each session.
Analyzing the recorded session at our own pace during the week was also helpful to get more insights we didn’t catch during our retrospectives.
Once we gather the information from the retrospective, we annotate clearly and concisely what area could be improved. We would focus on one area to be improved, research the theory to overcome the issue and apply it in the following week’s session.
Note: Each session is done weekly and lasts 1 hour.
If you want to know more about our process, please click the button below.
Retrospectives Applied.
In one of our sessions, when applying the ”things to improve” phase of our retrospective, we discovered we took too much time talking and giving ideas simultaneously but didn’t progress much. We detected that I needed to listen more, while Peter required me to talk more. To address this, we needed some Pair Programming rules to help us resolve this.
After some research by Peter, we found a PDF by Dave Farley ( ContinuosDelivery ) named Pair Programming Patterns - Continuous Delivery Advice Note. This short PDF gave us the definition of a driver and Navigator, their difference, how long the roles should be assigned, and when to switch roles.
Defining the Driver and Navigator while switching roles every 25 min is what is working for us now. In short, The Driver (who should be focused on the code) is the guy who’s typing, sharing the approach he takes about the code as he goes, and the Navigator (who should be focused on strategy ) should review each line, catching bugs and sharing thoughts when needed.
This approach improved our communication immensely! In the next article will dive deep into the differences between Driver and Navigator and other techniques you could use while doing Pair Programming.
Conclusion
In this article, we talked about retrospectives and how this technique is helping us detect flaws in our Pair Programming development process. We defined why we use retrospectives, how we use this technique, and an example of using the technique to improve our communication while applying Pair Programming.
We will share Pair Programming insights weekly as we continue our journey in Pair programming.
Stay tuned in the link below. In the meantime, stay safe!
