In true Toyota style we’re extending our Agile Practices to our suppliers. During a recent meeting with one of our data and calculation suppliers our management team were “waxing lyrical” about Agile. We’ve been told before about the passion and enthusiasm that comes across from members of our team when talking about how we work, and following the meeting, our MD was asked if members of our supplier’s development team could spend a day with us.

We spent the morning talking about Agile Adoption, pairing, TDD, Kanban and all the other things we do here to help us to quickly deliver high quality software .

As TDD and pairing were one of the changes we recommended we rearranged our coding dojo to give our visitors the chance to pair with our team on a kata.

The Roman Numerals Kata is well known and features a domain language that anyone can easily understand, so we opted to do this in two 45 minute sessions. We wanted to focus on how to test drive an object from scratch, how pairing worked and how we used ping-pong pairing to ensure knowledge was shared and developers were kept engaged in the problem.

Considering that we had paired one guest developer with one more experienced (in TDD at least) Codeweavers’ developer, the throughput was quite high. I was observing the pairs and noticed that they got through the first few translations in the same amount of time. I then came back 10 minutes later and all pairs had refactored to use a dictionary that held edge cases. This was a similar progression of the code (in terms of time) to when both developers in the pair were from Codeweavers. Hopefully this illustrates that pairing with a developer new to this process does not slow down the development. I heard some triumphant exclaimations from our guests as they realised that they were being an effective pair partner by spotting mistakes and helping drive the design of the finished solution.

At the end of the first 45 minute sessions I made everyone swap pairs and throw away their code. There was some resistance to this as pairs were reaching the end of the task and almost had a complete solution. I explained that the practise and knowledge from the first attempt would mean that this second attempt at the solution may get further, possibly to completion. Pairs had the option of tackling the problem with a different partner, which led to some “best of breed” solutions and a mixture of approach to tests. For example, only one pair jumped to higher numbers quite early on last time, but this time the approach was used in half of the pairs – presumably from the knowledge garnered in the first run.

One of the questions raised earlier in the day about pairing was, “how do you stay engaged?” I said that the role of the two developers in the pair meant that the person driving was mainly just the writer of the code and the other person making descisions, keeping the bigger picture in mind and driving the design – as well as spotting mistakes. This ensured both developers remained engaged. Initially this was a surprise to our guests who thought that the person not driving would find it hard to stay engaged. I conducted a little test by walking around the office behind the pairs and noticed that both were so engaged they took some time to notice my presence – when approaching a developer who was working on his own at the time I was noticed straight away.

Feedback from the group after the kata was great. I think every one of our guests got value from the experience and they are even thinking of running their own dojos with their team. Some choice comments:

“I really was sceptical about pairing until I tried it”

“Does this always get really competative? By the way, we won!”