TDD: A Minority Report

Tim, a modern urbane developer (i.e., he willingly practices TDD), talks about the reality of living in his team, circa 2008, where his organization was attempting to grow TDD.

The Minority Report LexusI am not gonna lie, this place is crazy with buzz words and terms.  They use words like Agile and Scrum as adjectives as opposed to ways of thinking and common sense still.  I hear, “Well, we are doing Agile, so we don’t have time for design.”  My jaw hits the floor… and then I start drinking heavily.

The team I am on currently, is a “center of excellence,” so to speak. We consult development teams within the organization (along with owning development projects, components, and standards). I feel pretty confident in my abilities to help teams out. I have no problem saying that I do not think of myself as an expert or perfect (yet). I have always been of the opinion that this should be a constant learning experience. I find it difficult to relay my thoughts, though, to the rest of the guys on my team. It is basically the three of them attacking me. It’s not totally me vs. the world, but it turns into a joke. I hear:

“…so basically you want me to double my development…”
“…there is no design in TDD…”
“…there is no empirical evidence that says TDD improves code…”
“…I have beens in shops before where the test cases were bogus…”

So…I think I know how you must feel sometimes 🙂 I never once say that it is a silver bullet. What I tell them is I didn’t realize how little I knew until I started using it as an approach. Primarily from a design and coding point of view. Don’t get me wrong, I have some smart-ass retorts, but I am just outnumbered 🙂 It’s a tad difficult for me to try and persuade them, because we all are strong developers (I think) on the same hierarchy, and everyone has their own opinions.

Fortunately or unfortunately, they will have to come on board though, because this is coming from the top down. The quality of code, and overall abilities of the development teams here is borderline atrocious for most projects. At least the ones we see on a regular basis. The good teams obviously don’t need our help. To put it bluntly, I have seen one too many 5000 line classes than I care to ever see again.

I think they (my teammates) have just had either bad personal experiences with TDD/Agile/etc., or bad education on it.

A commenter on last week’s post indicated that he viewed being the minority as an opportunity to show how much better things can go with TDD–fewer defects and getting code done sooner. That’s true, and it can feel gratifying, but you’re not likely to gain new converts by effectively showing them up–at least not immediately.

In a den of dogs with old tricks, some of the smart ones eventually come around, but in the short term they’re unlikely to admit that the new tricks might be better. Tim himself was sure his old way of coding (no TDD) was better until well after I’d left his scene.

In any case, from Tim we once again hear how bad experiences with TDD and agile can sour people. (Remember, this is four years ago.) What can we do to help? Here are a couple thoughts:

  1. Don’t do agile or TDD unless you’re willing to invest in its core notion of continual, honest retrospection and adaptation. You will not succeed with it over time otherwise.
  2. Relay more stories. Is your company succeeding with TDD, or do you know of one that is? Please tell your success story, or help your buddy write a blog post telling theirs. (And hope they’re not at a place where they view TDD as a competitive advantage to be kept hush-hush.)

Related posts:



Iterations are the heartbeat of agile–a consistent pulse, something that can be measured. If iterations are the heartbeat, the heart is retrospectives, representing the core and true spirit of agile: How do we adapt, how do we continually improve?

Too many teams don’t run retrospectives, and many of those that do fall off quickly. Often they fell into the trap of running a consistently boring meeting: What things did we do well, what things do we want to improve upon? Worse, they treated the outcome of the retrospective as a bunch of vague promises. I’d certainly stop attending them if that’s all they were.

A solution to the first is the Esther Derby/Diana Larsen book, Agile Retrospectives. The biggest value of this book is that it provides a number of activities to help you run your retrospectives. It provides a great starting point to devising your own activities–being creative is an important way of keeping people interested in attending retrospectives. There are a number of areas that remain to be explored with respect to retrospectives. For example, I’m currently continuing to explore distributed retrospectives.

With respect to the second challenge–lack of commitment–I like treating the retrospective items as stories, or experiments, that are introduced for the upcoming iteration (but these are not project stories). Thus acceptance criteria are required, and the stories must be specific, concrete things that people will (or won’t) do. During the subsequent retrospective, the team can’t consider the experiment complete if the acceptance criteria has not been met, and thus shouldn’t base subsequent actions on that experiment.

There’s always someone who wants an agile litmus test. “You aren’t agile if…” I feel comfortable in saying that “you aren’t agile if you aren’t consistently doing retrospectives and adapting the process based on them.”

Distributed Project Retrospectives

Recently I’ve done three distributed project retrospectives. I’ve heavily used the ideas in the Esther Derby/Diana Larsen book Agile Retrospectives to provide a foundation for these online meetings. Here’s their general flow with a few comments and one addition:

  • Establish base rules They need to “own” the rules but you should expect to kick off with a few of your own.
  • Safety exercise “I am planning on being very open and vocal during this retrospective.” – strongly agree, agree, neutral, disagree, strongly disagree. Answers to this will help you hold at least some people to their promises to talk. It may suggest the need to do even more anonymous polling during the meeting.
  • Gather data For project retrospectives, the Time Line activity has been especially useful. I simply share my desktop, put Excel up and start filling in events, with some dates, from left to right.
  • Generate insights, locate strengths
  • Commit to improvements I solicit as many variant solutions as possible for a given challenge, and then let them vote on what they think the best one is to carry forward on a new project.
  • Close

Here are some brief suppositions and observations:

  • Use “online only.” Everyone on the line should be at a separate station, not meeting together in a room. While this can increase phone line costs, it prevents “phone vs. live” dominance issues. Everyone sees the same thing.
  • Use some sort of communication software with polling capability. I used WebEx for each of these three sessions. It’s flaky but works. Make sure you try creating some questions ahead of time and understand both ends: How are questions defined, and what does the end user see?
  • Some of the problems with WebEx polling:
    • No scaling/ranking question type available
    • Easy to create a screwed-up poll and not know until answers are submitted
    • Crummy interface overall. Too many opportunities for “user error”
    • Can’t easily share anonymous answers to “free form” questions
    • Lame file-based save/load interface
    • I didn’t see how to change the amount of time a poll was open
    • No way to limit the number of “votes” on a multiple-choice answer
  • Come prepared with some good poll questions, but also look to create them on the fly. For example, after soliciting things that went poorly, it’s useful to find out the top three or so to concentrate on. You might normally do this with dot voting and cards. Here, you can create a poll and ask people to select a certain number of items from the list.
  • No matter how hard you try, many people will choose to not talk in a larger (> 15) meeting. With a meeting of ~15 or less, the idea (Derby’s?) of starting the retrospective by asking everyone to express their hopes for the meeting is a very good one; it gets people talking.
  • Get an assistant to take notes, type questions, monitor chat, etc. They will allow you to focus on listening and steering the retrospective.

It’s never the same as everyone being there! I view online retrospectives as a microcosm of doing the whole of agile in a highly distributed fashion. Effective communication becomes very difficult.