[...] it's about getting up in front of a whiteboard with your experts and saying, "let's talk about some examples of your domain. Let's look at what goes on." Whenever I've done this with customers, there's been this great "ah ha" of "oh my goodness, we didn't realize that we misunderstood each other so much." And this always happens before we start talking about Fit. This happens while we're actually at the whiteboard talking about examples. Fit is actually secondary to this process.
(Nowadays I describe Fit as providing a way of automating your examples. But you know what, you don't need Fit to do that. You get the power without using Fit. But if you use Fit without examples, it won't be that useful.)
So, to answer these questions: does it work, are we done, is it right, and minimize waste, I think we can use TDD, perhaps with exploratory testing to tell us if it works; involved customers to tell us if it's done; concrete examples to tell us if its right, and we might automate those examples.
Thus it seems to me that there's no need for [functional] testing; we can eliminate waste and keep it light.
"Automated Acceptance Tests are absolutely crucial to make sure that we know, we get the feedback right away, if we have violated an expectation that the customer had [...]. Furthermore, Customers don't want to have to repeat their expectations: [...] 'I have these expectations of the system, now it's the programmers problem to figure out how to automate those expectations to get that feedback.'"