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 .

"Wow, this is so cool; we can really use this, what a neat job, atta boy," and so on.
"Yes, but, hmmmmm, now that I see it, what about this . . . ? Wouldn't it be nice if . . . ? Whatever happened to . . . ?"

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 "Yes, But" syndrome is simply human nature.

By analogy, let's compare this software process to the development of mechanical devices whose technology and development process predate software by a mere few hundred years or so. Mechanical systems have a reasonably well-defined discipline of proof-of-principle models, sketches , mockups , models, incremental prototyping, pilot production devices, and so on, all of which have tangible aspects and most of which look, feel, and act somewhat like the device under development.

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 "Yes, But" syndrome is human nature and is an integral part of application development. We should plan for it.
We can drastically reduce this syndrome by applying techniques that get the "Buts" out early. In so doing, we elicit the "Yes, But" response early, and we then can begin to invest the majority of our development efforts in software that has already passed the "Yes, But" test.

The "Undiscovered Ruins" Syndrome

One of our friends was once a tour bus guide in the Four Corners area of the western United States, an area defined by the common borders of Colorado, New Mexico, Utah, and Arizona. The tour bus route included the majestic peaks of the La Plata mountain range and the sprawling ancient Anasazi ruins of Mesa Verde and the surrounding area. Tourists' questions are a constant source of amusement among the tour guide crew and create a certain folklore of the tour business. During one summer season , our friend's favorite silliest-question-ever-posed-by-a-stupid-tourist was, "So, ummm, how many undiscovered ruins are there?"

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.

The third syndrome arises from the communication gap between the user and the developer. We call this syndrome the "User and the Developer" syndrome. Users and developers are typically from different worlds , may even speak different languages, and have different backgrounds, motivations, and objectives.

Somehow, we must learn to communicate more effectively with these "users from the other tribe." In an article on this subject, Scharer [1981] 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

Problem	Solution
Users do not know what they want, or they know what they want but cannot articulate it.	Recognize and appreciate the user as domain expert; try alternative communication and elicitation techniques.
Users think they know what they want until developers give them what they said they wanted.	Provide alternative elicitation techniques earlier: storyboarding, role playing, throwaway prototypes , and so on.
Analysts think they understand user problems better than users do.	Put the analyst in the user's place. Try role playing for an hour or a day.
Everybody believes everybody else is politically motivated.	Yes, its part of human nature, so let's get on with the program.

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.