Client Presence

I got into a bit of a disagreement this morning with another developer about XP and the minimal requirements documents it advocates, and I don't think I really convinced him. If anyone could provide some more background on why ClientPresence? is superior to a BloatedRequirementsProcess?? I, and probably others, would find that very helpful. -- DavidRosenstrauch

You have a large system to do. You're working on some part of it. You want to know what some requirement really means. Which would you rather do, ask someone who knows, or read a document that drones on and on about everything in the entire project?

Let's face it. On a project with a bloated requirements process and document (BRPD), the first recourse every developer really takes is to ask someone who might know. Your best strategy is to have someone there who actually does know.

Same large system. Some requirement doesn't make sense: it's impossible as phrased or given a priority much above what it deserves or conflicts with some other requirement. Which would you rather do, prepare a document about the problem and get a document back (no one will actually update the bloated requirements document, you know), or sit down with a few clients and a few developers and hash out what is really to be done?

On a BRPD project many issues never get resolved; many get resolved multiple times; few ever make it into the actual documents. Many are resolved by individual developers making unilateral decisions and never informing or asking anyone.

Time is moving on, as time does. The true requirements are changing. Which would you rather do, implement a system that's out of date (or rewrite your bloated document), or have a customer on site who actually knows how things are changing in his world?

On a BRPD project, the spec is out of date before you get it. And the project's response to the need for change is to institute "change control" so that you can be sure there won't be any. The result is that the system, as delivered, never meets needs, even on day one.

Schedule is tight. Your only hope is to be late or drop some requirements. Which would you rather do, kill yourself and be late anyway, probably with reduced quality, or have the clients right there with you, doing their part, adjusting requirements, to get the project out on time?

On a BRPD project, there is no one anywhere who can adjust requirements in view of reality. The people who actually know the requirements are somewhere far away. They have no true insight into the project, and they adamantly insist that everything be done.

If the project is sufficiently large, the document may be the only way to communicate. If the project is sufficiently small (and 20 people is sufficiently small), human-to-human communication dominates written on every important dimension. You might want to back it up with some writing (we write a UserStory on a card, for example). But the writing is backup, not primary. --RonJeffries

Does email presence count? What about Wiki or a derivative? Can better technology help us segue from verbal conversations to written conversations to communual documents? -- DaveHarris

I honestly wish those things could substitute, Dave, because I really don't like having (at least certain) customers around all the time. I like the remoteness and pace of email and writing. Too many years of doing it that way, I guess. But experience on C3 has taught me that as much as I hate asking, and hate being answered, it beats the h*ll out of anything electronic. We have a question, we ask, we're unstuck in minutes. It can't be beat. --RonJeffries

Immediacy of ClientPresence does count. An analogy may help here. When learning a new idea, what is more useful,

For me, talking works best. Yes, it is nice to ReadTheBookFirst?, but that implies that someone has to WriteTheBook?. (Un)fortunately, for most projects, we do not have time to write the book, so we ask for ClientPresence.

For a real life example of this, think of how we are all learning about XP. We have managed to generate enough misunderstandings to all realize that the WikiWay, while fantastic, has limitations. The talks that Kent and Ron give on XP give a much better sense of XP, and the books are eagerly awaited (hint hint), but right now, the best way to get a real understanding of XP is to talk to Kent, Ron, Ward or the C3 team.

So back to the question about ClientPresence. You requirement is to implement a system that conforms to the SmalltalkBestPracticePatterns, so you can either read the requirements spec (the book) or you can have an ExtremeProgrammingMaster coach you (interpret the requirements). ClientPresence wins hands down. --PeteMcBreen

I'm not surprised, but I thought the question worth asking anyway.

Typing is much slower than speaking or listening. I'm not sure how it compares to reading: I suspect I get more out of reading a book than hearing a lecture, but I know that people differ in how they best soak up info.

A face to face meeting is (or rather, should be) tuned, on the fly, to the requirements of its participents. This maximises its value. On the other hand, that value turns immediately into unrecorded ProjectLore that exists only in people's heads. Wiki gives you the interactivity of a conversation but in a recorded medium. Although typing is laborious, the value created is longer lasting and can be absorbed by more people.

(Now I'm just musing on the general subject of capturing ProjectLore and mining conversations for documents.) -- DaveHarris

I avoid the EmphermeralProjectLoreProblem? by turning the decisions from a ClientQuickie? into TestCase's. "What if both numbers are negative? The spec doesn't say." "Well, then, the answer should be 6." --KentBeck

A document is a dumb immutable data object. A client has state, rich behavior, collaborators and responsibility. -- MichaelFeathers

Of course, you need to speak with client who has authority in that area. Otherwise is just another case of implemented because of janitor Tom said so and wouldn't get acceptance even if it is correct - just because you didn't ask the person that is in charge.

CategoryExtremeProgramming

EditText of this page (last edited November 2, 2007) or FindPage with title or text search