4×4 Dojo Technique
Introduction
A very common issue with teams struggling to perform better in an agile way is how to efficient pair program (efficient meaning productive and diverse – no pair marriages). Different team members have different pairing skills and personalities. Efficient pairing requires practice, though. That’s why our team started doing this type of dojo, even though we acknowledge that other types might work as well or even better. In the best scientific spirit we decided to try something new and learn with the experience.
Acknowledgements
This kind of dojo is pretty similar to Kake Dojo[1], which was our reference when we started. We just added some house rules.
The form of pairing we used is MicroPairing[2], which really worked for us with some minor changes.
The katas we solved were from the Kata Catalogue[3], which is a VERY cool place to look for simple, yet interesting problems for your dojos.
How many people, computers and katas?
Well the first thing was to get a hang of how many people would come. We got confirmation from 8 people. In this 4×4 (named after 8 people) we have two computers. The rule of thumb here is to have the same amount of people coding as there are people idle (not really idle as I’ll explain later). So in this scenario you just divide the number of participants by 2 (8 / 2 = 4) and then by 2 again (for pairs, so 4 / 2 = 2 pairs). That’s the number of computers and pairs.
Rule #1 – The number of problems and computers is equal to the number of participants divided by 4.
This is so we can have two pairs at a time working in two different katas. The exciting thing about having more than one kata to work on is that you also practice context switching and ramp-up time when working in a new story (when you change the kata you were previously working on).
The other half (The Crowd)
So, what does the crowd do while the two pairs work on the problems?
Well, they discuss the katas and *DO NOT* pay attention to the pairs solving the katas. The killer thing here is that these people are practicing different skills than the ones coding. They are practicing design, discussing points-of-view and most of all listening. We got a really positive feedback about this. People loved to hang around the other side of the table talking about how they would like the design of one kata or the other to go and learning from their peers different ways of thinking.
Another effect of this technique is that people trained boarding a story that has evolved since your last time in it. As developers who love our craft, we also love our code. So it’s hard to let the code evolve in different ways than what you would do. Since you cannot pay attention or interfere with the current pair you have no option other then letting it go.
Rule #2 – The crowd may not pay attention or interfere with the other half.
Pair Cups
One of the issues we face in the team is people with different skills working together, since every team member has their “favorite” pair. We had to work a way on how to get everyone to pair with everyone. We borrowed the concept of token from lean and created the pair cup.
Basically what the pair cup does is make sure you can only pair with people you haven’t paired yet. This is more of a tool to remind us that we need to pair with other people then it is a strict rule of pairing. The cup works like this:
- Everyone writes N-1 papers with their name on it (where N is the number of people involved);
- Everyone gets a plastic cup (coffee cups work well for this) and puts one paper inside;
- Everyone pass the cup to the person to their right;
- Repeat #2 until you have no more papers;
You should end up with a cup with papers with the names of everyone in the dojo (or the team) other than yourself. The sensei then draws from one of the cups (adding the missing name of course), two names. The first one is the navigator for the first pair and the other one is the navigator for the other pair.
When a pair needs changing (more on that in the Pair Switching topic), only the navigator goes. Someone who has the token with the name of the observer steps up and says they want to pair with the observer (who is now the navigator) on the given problem. That person then removes that token from their cup and the the current navigator removes the name of his new pair. What this means is that eventually you’ll get to pair with everyone.
Let’s see a sample just in case:
Pair – John (Navigator) and Paul (Observer)
Not Pairing – George and Ringo
After ten minutes John leaves the pair and Paul becomes the Navigator. George (who has Paul’s name in his cup) claims the pair with Paul. Paul then removes George’s name from his cup and George removes Paul’s name from his cup. This means that the next time Paul or George are the navigator in need of a pair they can’t pair with each other (unless they paired with everyone already).
This technique has proven very effective at helping people to choose people to pair with that wouldn’t be their first choices.
Switching Navigator and Observer
As mentioned above we used MicroPairing[2] for switching the navigator and the observer. We did change the rules a little bit, though as illustrated here:
Rule #3 – Every time one of the following conditions happen during the time one member of the pair is navigating, the observer becomes the navigator and vice-versa.
- A test passes and a failing test is written;
- A major refactoring occurs;
- A passing test is written (this is an anomaly as explained in [2] and should not happen);
The only exception to this rule is that the first navigator can’t write a failing test and then make it pass. The first time around the navigator just writes a failing test and switches.
This rule concerns switching between the navigator and the observer. This does not concern the actual pair switching.
Switching Pairs
In order to switch pairs, we used the TimeBox[4] approach, except we did it with 10 minutes. We defined each pair switching as an iteration. We did 8 iterations (1h 20 mins) of pairing in the whole session.
Rule #4 – Every X minutes, the person who started the pair as navigator gets out of the pair, the observer becomes the navigator and someone from the crowd claims the navigator using a token from the cup.
The main goal with this approach is to stimulate knowledge-sharing (since the observer stays with the story). It has proven very effective as a way to quickly ramp-up the new developer.
Every X (10 in our scenario) minutes, this dynamic is repeated. Some people felt that 10 minutes was too long (when they were waiting) and others felt that it was too little. After the retrospective people seemed to agree that it was enough. The kata discussions when they were not pairing in the katas seemed to alleviate a lot the anxiety of hopping in a pair.
The Katas
We decided on two very simple katas: FizzBuzz[5] and Roman Numerals[6]. Even though they are very simple, they served their purpose of getting people involved.
One of the cool things Danilo Sato[7] has proposed in Kake Dojo[1] is using different languages to solve each problem. More than that, using different programming paradigms. Since everyone in our team is already acquainted with both Python and JavaScript, we went with these two languages.
How do we assign a kata to a language to a pair? The navigator whose name was drawn by the sensei first gets to choose a kata and a language to solve it in. The other navigator then gets the remaining kata to be solved in the remaining language. In our setting we got FizzBuzz in Python and RomanNumerals in JavaScript.
Retrospective
After the eight iterations of pairing we held a retrospective (with pizza of couse, lol).
The retrospective was divided in two phases: problem retrospective and dojo retrospective.
The problem retrospective was a 10 minute insight on 5 different dimensions of the problems: Final Solution, Design, TDD, Pairing and Coping with Change. The first four are self-explanatory, but the last one means that after people got to the “final” solution, the sensei threw scope changes (new rules) that needed to be implemented and that often required design changes.
In the second phase of the retrospective everyone got to say what they would like to do more, what they felt could be done less, what we needed to start doing and what we should not be doing at all. This lasted for 20 minutes.
The experience as a Sensei
Being the sensei of this dojo helped me to train listening. I had to listen to what the pairs were doing and not interfere. I had to listen to the crowd discussing the katas and the best design for each and not interfere.
The key thing here for me is that I had a lot of fun, and I firmly believe that our work environment HAS to be fun.
The only issue I had being a first-time sensei was controlling the time. We’ll try a more automated way of controlling the time (a buzz or something like that) in the next dojo.
Conclusion
The first thing is that I’m not trying to claim that any of this is new or revolutionary. This is more like telling a story of how we did it. The second thing is that if I forgot ANY reference, please let me know and I’ll happily add it. I tried to get all the references I used right. If I missed any I’m sorry.
Given that no-one pointed anything we could do less and SEVERAL of the do more, I personally considered the dojo a success. That’s when I decided to post this information.
The most important thing with this dojo is that EVERYONE had a blast. We had fun from the very start until we closed it with pizza, coke and laughs.
As always, HAPPY HACKING!
References
- http://www.dtsato.com/blog/2008/10/29/uberdojo-sao-paulo-coding-dojo/
- http://www.codingdojo.org/cgi-bin/wiki.pl?MicroPairing
- http://www.codingdojo.org/cgi-bin/wiki.pl?KataCatalogue
- http://www.codingdojo.org/cgi-bin/wiki.pl?TimeBox
- http://www.codingdojo.org/cgi-bin/wiki.pl?KataFizzBuzz
- http://www.codingdojo.org/cgi-bin/wiki.pl?KataRomanNumerals
- http://www.dtsato.com/blog/
Recent Comments