TDD (Test Driven Development) is a highly disciplined technique for producing high quality software, but it's possible to get benefit from its basic principles without following the practise to the Nth degree.

In pure form TDD  is like miniature sub-iterations where a pair (or small team) consisting of developer and tester work together often on daily cycles to create tests against requirements, build software to pass those tests and so on until the requirements are delivered. It can be very difficult to implement a transition to working in this way - trying to move to a TDD model for QA in place of a more traditional build everything then test everything model. It also isn't entirely appropriate to all situations - TDD focuses on the quality of the software as paramount from day 1. There are often scenarios where the customer or product owner would prefer to see something working in principle to prove concept or refine requirements. In such a scenario this milestone could be considerably delayed if TDD is applied to the letter.

The value of TDD cannot be denied though:

1. There isn't any scope for gold plating - the developer doesn't get an opportunity to add detail that isn't directly related to requirements because he is so focused on passing the next test.

2. Requirements are scrutinised independently on a daily cycle as the software develops - the detail of the requirements and their solution is discussed regularly in the context of the software being developed today - there is no need to analyse in detail before starting and there is a reduced likely-hood of requirements being forgotten until the last minute.

3. Peripheral supporting functionality is captured and incorporated earlier - this is particularly apparent in the case of exception handling - such detail is often missing from requirements because the author is focused on what should happen rather than what should not - TDD captures what should not happen.

4. Delays normally caused by late discovery of a bug are mitigated - bugs are ironed out as build progresses this means the burn-down chart is a more accurate reflection of progress - burn-down can often hide late delays for fixing bugs.

In order to really realise these benefits in the sprint its necessary to rigorously enforce the TDD Cycle and that takes a lot of effort and a big transition from current practise for most teams. The benefit is there for the taking though without the rigour, and once the benefit is realised the temptation to enforce the rigour grows and its reality gets closer and closer.

So here is some simple advice for gradually getting into TDD and reaping the benefits:

a. Once the requirements for a sprint are understood the first thing to do is get the build underway.

b. Testing is 3 weeks away perhaps and normally the tester won't engage on this work in any detail for another 2 weeks. Change that approach and get the tester working on the sprint from day 1.

c. Define some sub iterations - suppose the sprint is 4 weeks - sub iterations could be every 3 days for the first 3 weeks and daily for the final week.

d. Decide what will happen between developer an tester in those sub-iterations - maybe the first 2 or 3 all they do is align the development with the satisfaction criteria and test scenarios without actually executing any tests - later when there is something to test there will be some more tangible feedback.

e. Based on the goals be practical about the detail - recall earlier point - are we producing or prototyping?

That's it you're doing basic Test Driven Development and the benefits will be apparent and measurable. Teams quickly become accustomed to this - it isn't evasive and it actually provides them with new securities about what they are doing. It also helps the customer because they are less likely to see bugs in their review. Once accustomed to this the team will develop TDD enthusiasts and before you know it they will be "adding a test" before even touching the programmer's keyboard.