In the past few days, I've seen several people express the idea that Agile => TDD/Pairing (or possibly TDD/Pairing => Agile). I'm guessing that XP (Extreme Programming) is the root of this misconception. I'm going attempt to clear it up here:
Agile is not a programming practice; it is a management attitude.
TDD and Pairing are (distinct) development practices.
But first, let me say that you should not take this as a lesson in any of these topics. Reading this will give you at most a flavor of these topics, and hopefully pique your interest in them.
Let's tackle the simple half first. TDD and Pairing are straight-forward and well served by their names
Pairing is simply two developers sitting at one computer working out a solution together. I won't get into the cost/benefit analysis here, but I will state that pairing has been wonderful for my productivity and my knowledge.
TDD is slightly more complex. There are three steps: write a test, write some code, and clean up the code. This process is often called 'red, green, refactor', and you end up with a nice cadence of writing short tests, writing small amounts of code, and cleaning up. There are books written about TDD, so clearly there's more than meets the eye here. However, it's still a very simple process once you get the hang of it.
You will notice a distinct lack of any prerequisites in either of the above paragraphs. You don't need anything other than someone to pair with to do pairing, or an test framework to do TDD. Pairing helps you get more work at a higher quality done, but it doesn't fundamentally change how you manage the project. Similarly, TDD helps improve your code quality, and it increases visibility into your code quality. However, TDD doesn't change how you manage your project.
Let's tackle the harder half now: Agile. Agile is not a process, and it's barely a paradigm. Agile is an umbrella which covers (to a greater or lesser extent) several development methodologies (including Extreme Programming, Scrum, etc).
When someone asks if you are Agile, what they should be asking is, "Do you recognize that your clients' needs change, and can you respond to those changes with working software quickly?" This is (according to some of my PMP friends) pretty standard project management stuff, so you wonder why we need to give it a special name. Well, I wonder why we have to give it a special name... That is, in a nutshell, the primary concern of Agile. There are secondary concerns, of course.
The Agile mindset is based around your relationship with your client. But, that relationship informs nearly everything you do as a producer. It pressures you to have greater visibility into your processes, and to abide by shorter release cycles, and a number of other things, too. But, you can increase your visibility and shorten your release cycles and achieve a host of other goals without TDD and without Pairing.
That said, I really think that TDD and Pairing help a bunch.
