Code katas such as the classic bowling game kata by uncle bob are a good way of fostering TDD best practice in your team. Here, in no particular order, are a few hints for running them I have picked up over the last few months.

Start with a subject that everyone knows. For example with the bowling game don’t assume that everyone knows how to play and how to score the game. In my experience most people cannot score a strike properly so make sure you explain the rules and any intricacies or pick a well known topic. Ideally get this done before the kata so you don’t lose time explaining.

Guard against over engineering. You want to encourage participants to only make the test pass and not to build a perfect solution in one go. Being guided by the tests does not come naturally and many people will resist it with encouragement.

Red green refactoring. Explain what it means and step through an example following the pattern. avoid premature refactoring and don’t forget to refactor the tests as well as the code.

Smaller might be better. It’s useful to start with a big group as you introduce the idea of a kata and give an example, but I found you get quicker results if you then spilt into pairs, or threes if needed. Smaller groups produce more code because there is less discussion on every little detail.

The group should decide. Letting the group pick the kata by means of a vote is a fairest way to ensure you work on something that interests the most people. A pick list of three works well.

Be regular. Try and host a Kata every 1-2 weeks to keep up momentum. We found 60-75min was a good duration.

Swap the driver. Following pair programming from XP is good, but it helps to rotate the “driver” and the “coder” every 10 minutes. This stops any one person taking over and keeps the pace fast.

Leave time at the end. Save a window to compare notes from each pair and don’t eat into it. 15mins is about right. The discussion at the end can be as valuable as the Kata.

Not just the hardcore. Try and invite those who are not confident programmers too and pair them up with more experienced folks. Threes work well in this scenario and helps “level up” everyone quickly.

Competition can help. Depending on the group a bit of competitive “how many tests have you done” can encourage speed and fun but works best if the group are all at a similar level. Watch out it does not exclude people though - some people may find it off-putting and make them feel inadequate.

And most importantly keep it fun otherwise people just will not come back.