TDD Coaches Should Not Pair with their Coachees
This entry was posted on 11/25/2007 5:02 PM and is filed under Agile Development,Coaching.
This summer I had the opportunity to work coaching some C++ developers in how to do Test-Driven Development (TDD). The workspace assigned to these developers made pair programming an almost impossibility. Rather than fight the physical limitations I decided to coach them without using the keyboard. To my surprise, coaching this way was both easier and more effective then I thought it would be. Coaching TDD is about form: is the coachee following the methodology; where are they having difficulties; how is their rhythm; are they partitioning the problem as fine grained as they need to; are they refactoring; and so. When you don't pair, when you don't have the ability to just grab the keyboard, you are free to focus entirely on the coachee's form.
I also notice that the coachee sets the pace of the work. The coachee is doing it all and so they learn it at their own pace. There is also no expert magic involved in the outcomes. Every person that I coached extensively - there were some who due to scheduling I only had one session with - reached a point of puzzle/amazement. During a review of their work, they would look at their code and their tests in a form of disbelief, coupled with knowing that they had written all of it and that the coach had not made the code magically appear. When this happened, they now knew the value of TDD.
I also discussed this coaching style with a number of the coachees and the majority stated that they preferred it and found it more effective then the pairing approach. So the next time you find yourself coaching someone in TDD consider not grabbing the keyboard and focus on the coachee's form and letting them learned TDD directly and at their own pace.