Watering Things Down Is Not Good For The Plants
Extreme Programming used to have a very specific meaning. It still has a fairly specific meaning. Scrum still has a fairly specific meaning. It, too, has drifted a bit over time. It is natural that terms drift a bit as we learn.
TDD, Test-Driven Development, has started out with a very specific meaning, concerning a programmer or pair writing a single test at a time, and making it run, on a very short cycle, as short as ten minutes or less.
Part of the value of TDD is that it makes the programmer’s intentions clear to her–and to her colleagues who may read the tests and code later. Clear intentions are great, and there are other places where teams may really need them. One of these is in the relationship between Customer (Product Owner) and developers.
On struggling or learning teams, we often see the Customer come in with a vague story, talk about it for a while and set the developers to doing it. When they come back, the Customer says “That’s not what I said,” and the developers say “It bloody well is what you said,” and trouble ensues. It really doesn’t matter whether the Customer said it right and the developers got it wrong, or whether the Customer said it wrong, or whether the Customer has changed his mind. It’s irritating and wasteful in any case.
The standard corrective action for this situation is to express requirements in part with examples. See, for example, the Card, Conversation, Confirmation article from ever so long ago. The Confirmation part is about examples showing how the system should work. It works best, by far, if these examples are executable.
This is clearly the same basic idea as TDD, only written larger. It’s a good thing to apply this kind of thinking at all levels. I’m all for it.
However, let’s not call every **ing occurance of calling our shot and then executing it TDD.
We did that with Agile. The term “Agile” was vague at the beginning, as an umbrella term covering many methods. It is now watered down to the point where to people who care, a project calling itself “Agile” is assumed to be messed up, and it usually is.
Let’s not water down yet another term. It’s not good for us.