I was cleaning up my old files and came across an old whiteboard shot, which reminded me an old small technique on measuring the amount of done Test Driven Development (TDD) work.
In case of a less advance agile team, a usual discussion topic during a retrospective is TDD. Team members are talking about whether they shall do it, how well are they doing it, how much are they doing it and the list goes on. In most of the cases the discussion is based on memories, and the longer the iteration is, less accurate these memories are. I introduced a very easy way of TDD measurement, which helped my team handling the problems related to the TDD discussions. Have a small part on the whiteboard, with two columns:
How to use it:
TDD : draw one strike into this column, if your task was implemented using TDD
NO TDD: draw one strike into this column, if your task wasn’t implemented using TDD
At the end of the iteration or implementation cycle, the team had a clear picture on how much TDD they did. For the example let’s have 10 done implementation tasks, 4 strikes in the TDD and 5 strikes in the NO TDD column. One task was not categorized, let’s count it to the NO TDD column. 4 against 6 means that almost half of the tasks ware implemented by TDD. It is not bad at all.
Based on my experience a less advance team cannot do 100% of the implementation in TDD. Having it as a goal will make the team less productive and more frustrated. It is much healthier to pick a goal, which is realistic, but isn’t easy to achieve. If the team decides that they will use TDD in 75% of the implementation tasks, they can easily measure their progress with the way described above. If the measurement shows different result than the goal was - in this case 75% against 40% -, it is easier to talk about it when some data is available. For example they can discuss those tasks, which were supposed to implemented using TDD, but finally no TDD was involved.
From the psychological perspective, people feel better when they can accomplish a hard task, and this feeling is even better when they can show it to others - in this case drawing a strike into the TDD column.