Hi David,

Thanks for the further reply.

I find discussions like this often help me to clarify my thoughts, glad to hear/read I am not alone in this.

Dan North has a point when he talks about how 'transfers' between process steps have a great potential to create waste.

A 'trick' that helps to see this waste (being created) is looking from the point of view of the 'unit of work' moving (flowing) through the process, e.g. through a Value Stream Mapping exercise or similar. Look for units flowing backwards, units getting piled up between steps, units disappearing, ...

But that's only part of the challenge. Units flowing as efficiently as possible still do not create value when they do not meet the expectations...

Testing surely helps in this, the whole objective of testing being to validate a unit produced is meeting (all of) the expectations.

But there is a big assumption there, namely that everyone involved is clear on and agrees on what the expectations to be met are. I think we can all agree that is not always the case (for a variety of reasons).

Indeed, 'communication breakdown' might be one of the reasons. 'Customers' do not understand the technical speak, but equally 'producers' do not understand the 'business speak'.

But it is not the only one (I think), e.g. expectations can change over time

I agree that using 'examples' can greatly help to creating a common understanding. So can working with 'small' units of work and frequently demoing progress, demos serve as sync points where all parties can check if 'we are all still on the same page?' and to quickly 'realign' when it turns out we're not...

But above (and other) practices are nothing new, they are being used for quite some time (and not only within IT).

So the question remains... What does TDD bring to the table that was not on the table previously?