Developers declare function after function ‘ready’ and the customer still complains that “nothing ever gets ready” - unhappiness ensues.
This little exchange really happened…
Consultant: “Has the issue #whatever been resolved?”
Tester (customer): “Oh yes, that was the one where we couldn't do #some_important_thing”
Developer (supplier): “That's been handled for ages - you can do #that_important_thing"
Product manager (customer): “No, I still can't do #that_important_thing”
Manager (supplier): “It is possible to do #that_important_thing"
Tester (customer): “I wanted to try it this morning and it is still not possible to do #that_important_thing“
Developer (supplier): “I am sure! I have implemented that. You definitely CAN DO #that_important_thing”(in an aggravated tone)
[one or two more circles like that, voices getting louder]
Consultant: “Dear Tester: _In what way_ couldn't you do #that_important_thing?”
Tester: “I don't see any menu entry related to #that_important_thing in my main screen!”
Developer: “Oh - you're trying to do it with your own account! That won't work of course …"
Tester: “There is another account?!? What's the name? Where is it mentioned?”
Developer: “Oups … we might have to work this out a little more …”
And thus both the developer and the tester learned something new about the system and its interaction with the world.
The parties clearly communicate on different levels of abstraction – while the developer was referring to the theoretical capabilities of the system the tester was taking about the things he actually was able to do with the system at that point in time.
Abstraction differences like this oftentimes can take days or weeks to become visible, especially if the parties involved communicate intermittently and use media like e-mail or a ticketing-system for their conversations.
Go to the real enduser (or as close to the real enduser as possible) and watch her using the newly added system-capability.
Related lean/TPS concepts
Related values from the Agile Manifesto
Customer collaboration over contract negotiation
Responding to change over following a plan
Related Scrum Values