Recently, I’ve done a management workshop on TDD. The audience was developmenet managers and team leads. Most of them did not know TDD. (Actually, most thought they knew what TDD was. But that’s a completely unrelated story.)

During my session, I’ve walked them through an example (from Star Wars) and showed the thinking behind it, applying the steps to “real” software development. They were quite engaged, and there was quite a discussion (including if Darth Maul’s dual-lightsaber is considered an actual lightsaber).

At the end, one of the managers asked: Do the programmers believe TDD works?

My answer was: They believe, without a shadow of a doubt, it will be the first thing that will be dropped when pressure rises.

(Yes, I actually ask people about that, so I was prepared).

A Question of Faith

Here’s a question for you: Do you believe agile works?

Because there are no real independent, objective, comparative experiments that show that it does.

My experience tells me that agile works in some contexts. I believe the values make sense, and I’ve seen what happens when they clash with other values. I understand humans enough to understand limiting WIP works. And I have seen time and again how making things visible, discussing them and commiting to improvement – how all those help teams become better and make people happier.

But after all is said and done, what I believe doesn’t matter – how I act on it does.

I try to convince people to use TDD because I believe it will help them create better code. I think visibility and transparancy are better than the alternatives, even at the price of losing the comfortable opaqueness. I teach that safer experiments lead to better products, even if it’s really hard for people to grasp this and put aside their big roadmaps.

My behavior is based on what I believe. This is what people see on the outside.

So see we all

The programmers we talked about base their beliefs on what they see.

They’ve seen their managers tell them time and again, in the face of looming deadlines, to write more code, not less. To skip testing (of all kinds) because they need to complete the story (read: the coding). They have seen it too many times to believe that their managers will act differently the next time.

They may believe that TDD will work for them. They are “playing” with TDD now becauase they have time. They are sure it’s a limited-time offer that will expire soon.

So here’s a better question to ask yourself: What does your team really believe about how they work?

Go ask them. You may be surprised.