We are a small team (3 developers) and one of our main clients is about to submit a bunch of new feature requests and a follow on project to us to get estimates on cost and delivery times. Our last project with them was a 'success' in that they are coming back to us but I know we could have done a much better job (we used waterfall... testing was an after thought and as a result unit-testing code coverage is significantly lower than we feel comfortable with, not to mention the never-ending 'we are ALMOST done' problem).
I have just finished reading 'Art of Unit Testing' and 'Working Effectively with Legacy Code' and I have used TDD on a pet project of mine outside of work and now I can never go back to waterfall and testing after the fact.
What I want to know is are there are good 'easy to digest' videos for non-developers that clearly show the benefits of TDD along with Agile practices in a business sense? I'd be super happy if there are any sub 10 minutes videos but I'm also OK with longer videos (and I will reference them to a time index in it). If there are no good videos then a written source is next best thing.
I want nothing more than for them to be on board and really excited with the transition.
For me it is not an option to 'just do it' as there will definitely be a learning curve for the other two developers and without doubt the first number of iterations may be stressful and bumpy and that needs to be communicated to our client.
[I have answered my own question below with a number of videos I found since asking the question... they are not perfect for my use but definately my plan B if no-one else knows of a better one]
Technical debt kills velocity. Thus, I like to include "No increased technical debt" in the Definition of Done. Without this, you can't achieve sustainable pace. This is illustrated by the picture below (borrowed from the Technical Debt - How not to ignore it presentation from Henrik Kniberg):
alt text http://img27.imageshack.us/img27/329/screenshotkq.png
To me, all these things are obvious and you can even prove it with numbers (by measuring the velocity over time). Explain these concepts to your client, explain him that TDD is one of the techniques allowing to control technical debt. Then, let him choose (or choose for him).
