Barriers to Elicitation
The "Yes, But" Syndrome
One of the most frustrating, pervasive, and seemingly downright sinister problems in all of application development is what we have come to call the "Yes, But" syndrome. We have observed it in the users' reactions to every piece of software we have ever developed. For whatever reason, we always see two immediate, distinct, and separate reactions when the users see the system implementation for the first time .
The roots of the "Yes, But" syndrome appear to lie deep in the nature of software as an intangible intellectual process. To make matters worse , our development teams typically compound the problem by rarely providing anything earlier than production code for the users to interact with and to evaluate.
The users' reactions are simply human nature, and they occur in various other day-to-day circumstances. The users haven't seen your new system or anything like it before; they didn't understand what you meant when you described it earlier, and now that it's in front of them ”now, for the first time after months or years of waiting ”they have the opportunity to interact with the system. And guess what: it's not exactly what they expected!
The users can see the early devices, touch them, reason about them, and even interact with them well before detailed implementation is complete. Indeed, specific technologies, such as stereo lithography, wherein a rapid prototype is constructed overnight out of a vat of goo, have been developed exclusively for the purpose of providing early and immediate feedback on the conceptual definition of the product. Yet in software, with its enormous complexity, we are expected to get it right the first time!
As frustrating as it is, accepting the "Yes, But" syndrome as reality may lead to real insights that will help team members mitigate this syndrome in future projects.
The "Undiscovered Ruins" Syndrome
In many ways, the search for requirements is like a search for undiscovered ruins: the more you find, the more you know remain . You never really feel as though you have found them all, and perhaps you never will. Indeed, software development teams everywhere continually struggle to determine when they are done with requirements elicitation, that is, when have they found all the requirements that are material or when have they found at least enough?
In order to help the team address this problem, we'll provide a variety of techniques, both in the Team Skill 2 chapters and in later ones. Of course, as we described in Chapter 5, taking the time in problem analysis to identify all the stakeholders of the system is of tremendous value because many of these nonuser stakeholders are often holders of otherwise undiscovered requirements. However, as with finding all the undiscovered ruins, we must acknowledge that we are on a mission that can never be completed. But we also understand that at some point we will be able to say with confidence, "We have discovered enough for now; we'll find the rest later."
The " User and the Developer" Syndrome
Techniques for requirements elicitation are not new. Application developers have strived for more than 40 years to do a better job. What could possibly account for the fact that understanding user needs remains one of our largest problems? Well, considering the fact that few application developers have any training in any elicitation techniques, it's perhaps not all that surprising.
Somehow, we must learn to communicate more effectively with these "users from the other tribe." In an article on this subject, Scharer  describes this syndrome and provides some guidelines to help mitigate the problem. Combining her words with our own experiences, Table 8-1 both summarizes the reasons for this problem and suggests some solutions.
Table 8-1. The "User and the Developer" Syndrome
The hope is that with a better understanding of both the nature of these problems and some approaches to mitigate them, developers will be better prepared for the interesting work ahead.