Dear Customer, Write It Down

chromatic on 2002-06-29T05:25:19

I'm an XP practitioner. This means that, in my world, customers devise specifications by writing stories. Developers break those stories into the tasks required to implement them and base their time estimates upon those (adjusting for the actual time the previous estimates have taken). The customers order the tasks based on business value and risk. Software is delivered every n weeks, where n is a small number (two or three are fairly popular).

This has several advantages. First, it makes the actual work for each feature apparent to the customer. Second, it pushes the responsibility for technical risk on to the programmers. Third, it pushes the responsibility for scheduling and business risk to the customers.

Until tonight, I would have argued that another benefit is that it forces the customers to think about their requirements. After all, if something's not written on a story card, it won't be included in a task, will not be estimated, and will not be programmed. It effectively does not exist.

My current project has been moderately high on the risk scale, with the potential for big payoffs. I wasn't keen on it from a scheduling point of view, because there was also potential for failure. (The schedule was way too tight, and the business people have the nasty habit of claiming that nearly everything is of "highest priority".) We took it on anyway, because the reward would be amazing good will within an entire industry.

The schedule was and is tight, so that the first iteration doubled in size (already a bad sign), and the lowest-priority "emergency" feature will be delayed to the next iteration. Yeah, we're not even in the second iteration. We did hit the first iteration deadline just fine, and the customers have had the software for a while. Of the bug reports I've received, they've all been setup errors, easily fixed.

The problem is, I was celebrating the christening of the new wgz.org web server tonight, when I got a call at 8:30. Apparently, the customer's failure to give us an accurate specification several weeks ago has escalated into a crisis that means I "must" go into the office tomorrow to add a feature that never appeared on a story card. I do have plans for tomorrow.

My current plan is to go into work (and they are being "generous" in "allowing" me to come in at 9 am instead of 8:15, as is my usual habit). Because this feature was not on the story card, I feel perfectly justified in saying, "This is not an emergency. This is not my responsibility." I'm a nice guy, though, so I'll make the (small) database and code changes to store the data they want to collect. They'll have to wait until the next iteration (one week) to run reports.

To all of the customers reading this: If you ask me to build the software equivalent of a bicycle path, do not come up to me at the ribbon cutting and expect me to work overtime because you just remembered that elephants wander across it twice a year.


how i work

gav on 2002-06-29T05:58:52

  1. The client thinks up some project
  2. My boss writes a spec (usually without showing me) and the client agrees
  3. The client agrees to a budget that is too tight to include such luxuries as "testing"
  4. The client imagines that they are getting something that is 10 times better and includes features that aren't technically feasible
  5. I work really hard on the project and my boss smoothes things out with the client and it works out where everyone is happy
  6. I am proud of the end result
  7. I worry that we haven't tested anything and it might all break and disasters may occur

Seems naive

jordan on 2002-06-29T12:22:59

  • Until tonight, I would have argued that another benefit is that it forces the customers to think about their requirements. After all, if something's not written on a story card, it won't be included in a task, will not be estimated, and will not be programmed. It effectively does not exist.

Non XP practitioners could say exactly the same thing except "on a story card" would be replaced by "in the functional specification".

I think the XP practice of getting everyone together and putting requirements into a "story" is more informal than a functional specification, and more likely to be read and understood by all, but it doesn't completely eliminate customer inattention to detail and changing requirements.

Really, it's all about power. Just because you've agreed to a methodology doesn't mean that you have the power to enforce that agreement. The customer is always right, you know.

In a non-XP scenario, this missed requirement could have been a cataclismic event. The customer would still be waiting on a release 6 months off with no idea whatsoever if the new requirement could be included. Typically, management tries to charge heavily for these kinds of changes if the customer wants to be assured that the new requirement is there and often, this involves schedule slip which is another heavy cost.

Something to think about in future projects. Get customer buy-in for heavy additional charges for such changes. That's the thing that will really get their attention with regard to getting all the details right up front.

Don't be surprised if some future manager waives the heavy additional charges for reasons of customer relations, however. They are, after all, the customer, and they do need to be satisfied.