Xp On Site Customer Pitfalls

XpPitfalls

Problem: Full-time on-site customer often is not available

Solution: Take what you can get; fill in the gaps with more Communication and documentation

Problem: One customer is not sufficient

Solution: Customer team (analysts / product managers)

Problem: One customer is a terribly stressful job

Solution: Customer team

Solution: Several part-time customers

Problem: If the customer is a team, this reduces communication, and increases crosstalk, or worse, inconsistency: when one customer says one thing and another says another.

Solution: Write more things down. [But beware, since written documentation can rapidly go stale.]

Solution: Question the team customers more than you would a single customer. (On our project, the reponse is often "I hadn't thought of that; let me talk to the others and get back to you".)

Solution: Designate one customer as the "point customer" to whom all questions are directed if s/he is around. If s/he isn't around, ask another customer.

Solution: Make sure people realize that some customers aren't to be talked to at all. (On our project, I'm on both the development team and the customer team, but I have abdicated my role as question-answerer because I don't understand the business as well as some of the other customers do.-- ErikHanson)

Problem: Customer changes his mind

Solution: Realize that this is the entire point of XP and realize that if you weren't doing XP, you'd be screwed. But since you are doing XP, it's no problem at all and you're happy to do it.

Solution: Make sure you're doing all the XP practices so that you can handle changes.

Solution: Make sure the development team realizes that the customers are in charge of both the stories and the schedule. Changing stories might mean that fewer features are getting implemented, but it's not the developers' fault. (On my project, our coach feels that any schedule slippage is his fault, so he's not happy at all when changes are requested.)

Solution: Remove the word "no" from your vocabulary. Replace it with "No problem, and it will cost X".

Solution: This is a fact of life. Expect it. -- JimKingdon?

Solution: Make the system configurable/flexible. As feasible, do so to the point where the customer can configure/customize the system for themselves. Letting the customer experiment and see the results of their changes in real-time is a great way to help the customer clarify their wants. -- JimKingdon?

Problem: Customer is an important "single point of failure" -- Truck number=1. If he gets sick or goes on vacation or is pulled to another project the XP project can founder looking for direction (features/priorities).

Solution: A planning game should produce a tentative priority for all upcoming iterations in the current release. Keep moving in the same direction and try not to run aground.

Solution: Customer team

Solution: If you have one single customer, perhaps try to have a "backup customer" who attends all release planning meetings so s/he has some idea of what's going on. [Has anyone tried this?]

Solution: Cancel the project. Often lack of customer engagement is a symptom that the project isn't very important after all. Cancellation of a project early on should be seen as a routine event rather than a failure. -- JimKingdon?

Problem: Customers must write automated tests. Even in teams which provide technical help for writing them, this is still a major hurdle. Depending on the skill and mindset of your customer, he may not even be able to conceive a systematic test, or understand a test once it has been written, or understand how the written code conforms to the idea he has in mind.

Solution: Assign developers to assist on tests

Solution: Make a rule that developers cannot move on to a new story until the old one passes all its customer tests. Thus, if a story has no tests, the developer must immediately write customer tests for it (hopefully in concert with the customer)

Solution: The previous solution is backwards. We emphasize Story Test-Driven Development in Industrial XP and Evolutionary Design because we're finding that the better approach is to first introduce a failing Storytest (i.e. scenario test, customer test, acceptance test, etc.) and use that to drive your unit/programmer tests which in turn drive the design/code. -- RussRufer

Solution: Bring some experienced QA people into the customer team.

Solution: Use a testing framework that is more customer-friendly. Ward's FIT Framework could be a godsend here; see http://fit.c2.com/.

CategoryExtremeProgramming