Bringing Down the Hammer to Nail TDD
acceptence testing, software development, test driven development
Back a few weeks ago at SD West 2006 during a tutorial session on rSpec with Dave Astels a TDD discussion cropped up. It centered on how you introduce TDD to a development organization. Dave went on to relate a story with at least one client who took the top down management approach. Dave described him as a great technical manager for having the courage to force TDD on the developers. His approach was:
- Move the whole team out to a new collocated team room.
- Outfit the team with brand new equipment.
- Brought in Dave to mentor/coach the team on TDD by doing a lot of pairing.
- Mandated that all code was unit tested.
- Mandated user stories and acceptance tests written into Fitnesse.
At the end of the project the whole team was doing TDD. Sounds like a great approach, and developers generally get the idea of TDD better if you can pair a guru like Dave up with everyone.
I tend to be a bit more of an incrementalist, but it definitely gives me some ideas.
Ed Gibbs @ April 1, 2006
seems to me it would be easier than all this mandating just to hire some programmers with TDD experience, who had taught it to themselves and were already with the program. no hammering required.
A couple of things:
Objectively it might be easier, but it isn’t my present reality anyway. One big advantage of building up a team into better development practices is everyone benefits. Our organization gets better and more productive and those developers can pass on practices like TDD down the road. It may be personal style as well, but I prefer to grow people on hand as long as they’re willing to learn.
The other item would be that we went through a hirining exercise for a few open spots about 9 months ago, and it turned out to be nearly impossible to find anyone in the local area or who was willing to move who had any TDD experience. That was one of the items that began to shape my idea that TDD adoption isn’t very deep at this point.
It almost sounds as if ndh is recommending canning your old staff and bringing in a new team that already has TDD experience. I’m not sure that’s a very good business practice in general.
The way you went about it sounds pretty practical to me. Placing the team in a new physical environment can be very helpful in breaking old habits. Bringing in a mentor to get them up to speed on the methodology is a great way to go.
At our company, we hired ThoughtWorks to come in and pair with our people on several real projects. We had about a 1:1 ratio of Thoughtworkers to employees for our first few projects. That turned out to be a very effective way to bring staff up to speed on XP practices.
I like the 1:1 ratio ThoughtWorks approach, but given current budget realities I’m filling in as the TDD mentor as imperfect as that scheme is.
Dealing with an imperfect world in an adaptive way sounds pretty agile to me, Ed. As far as I can tell from reading your blog, you’re doing great.