The problem with most TDD trainings is…
… they are too short.
Mark Levison has posted an interesting article, Making TDD Stick, on InfoQ that covers some of my observations about how to sustain test-driven development (TDD) in an organization. I have found the best way to teach TDD is to mentor\pair with an individual one-on-one until they “get it” (about 4 to 6 weeks).
Unfortunately, one-on-one mentoring is not feasible or economic as bigger organizations try to improve their quality with TDD. There are just not that many self-proclaimed TDD experts out there. To solve this scarcity issue, often times big companies bring in a TDD expert to provide classroom training for the 40 or so developers deficient in this skill. Once the trainer has been scheduled, the participants are rounded up, sit in a one or two day class, the consultant gets their check and then nothing happens!
I have not seen the model of flying in a training for a one or two day training ever work. Why? People do not know what to do after the trainer leaves. TDD is hard and makes highly skilled (and highly paid) professionals feel like morons. After a day of flailing about in their IDE, most developers jettison the whole thing and walk away with the idea that TDD only works on “toy projects”. Not surprising since that is all they saw in their training – an easy-to-understand and easy-to-teach example that fits within the confines of a day. Little guidance or no guidance is provided on how to apply the TDD concepts back at your desk.
What is my alternative? Make the class longer – about two to three weeks.
- Week One – Basic TDD training (up to 1 day) followed by 4 days of practical application.
- Week Two – Advanced TDD concepts (up to 1 day) followed by 4 days of practical application.
- Week Three (optional) – Five days of practical application and mentoring.
At the end of each day, I gather all the team members together for an afternoon show-and-tell of all the tests they wrote. Everyone is required to show at least one test. The purpose of the discussion is to learn where people are having trouble, who needs help from the trainer, what is working for the developers and allow people to express their frustrations. The daily retrospective amplifies the learning and allows the teams members (or the trainer) to make mentoring connections among themselves. At least you now have a fighting chance to make TDD succeed instead of people suffering alone at their desk hating life.
