My scenarios alarmed and frustrated the team and my initial reaction was that the team was once again resisting design processes and I needed to engage in “pushing” the team to “do it right.”
But they wouldn’t budge. Something was wrong and it took a while for me to figure out that what they wanted to do was some form of integration testing, or as the QA lead called it “exploratory testing.” They didn’t actually want to test the “flow,” “workflow,” and “navigation.” They wanted to test the product of development by utilizing “workflow” and “navigation.” Heretofore, we had called this process “design validation” because of my misunderstanding.
Once the confusion was resolved I said, “Oh, you want to do some integration testing.” To which the response was, “I don’t care what you call it…” I heartily agreed that we didn’t need to quibble over terms and to move on with productive tasks.
However, having time to think about this and the implications of what happened, I realized that the problem is the result of differing vocabularies. We are saying the same words, but speaking different languages. My presence is the introduction of a new vocabulary and getting this vocabulary right will help everyone understand things better.
Certainly, arguing about the meaning of words is pointless, but when different vocabularies lead to confusion, it is time to define words explicitly in order to avoid confusion. I believe that we should be careful to define our terms and be explicit and forthright about the meanings we intend. This is the foundation of “communication” which is often to blame for struggling projects.