Too Tough for the On-site Customer


As if schedule overrun wasn t bad enough, another key problem that afflicted C3 was the project s overreliance on the on-site customer. This is something that can affect any XP project, because the on-site customer is often a single person over whom the developers have no control, but whose consistently high-quality contribution to the project is a vital factor in its success.

start example

We discuss the on-site customer in Chapter 5.

end example
 

Later in the project, there were problems with their new, very bright and dedicated customer not communicating very much with the so-called gold owner (the people at Chrysler who held the purse strings), which leads us neatly to the next problem.

Too Many Cooks

The C3 project had two customers: the goal donor (the on-site customer who contributed the requirements) and the gold owner [36] (the project sponsor, who wasn t directly involved in the project). This is probably true of most, if not all, projects: The team has more than one master. This also highlights a classic problem with XP: The customer speaks with more than one voice.

It s likely, and somewhat ironic given XP s emphasis on having an on-site customer, that the project sponsor can normally be thought of as the real customer, the one who must be kept happy at all costs. If the project is going in a direction that the real customer isn t happy with, the project stands a heavy risk of being cancelled. This is exactly what happened to C3.

We suggest some ways to get around the too many cooks problem in Chapter 7.

Not Incremental Enough

A point made by Ron Jeffries concerning C3 was this:

One of C3 s possibly-not-minor problems was that we did NOT release the payroll incrementally because no one could see how to do half a population. That was IMO a mistake. [37]

It s generally accepted that small, frequent releases are one of XP s strengths ”in fact, they re a vital part of an XP project s success, because without early user feedback, the project s functionality might deviate considerably from what the end user really needs the system to do.

The problem mentioned by Jeffries highlights the fact that real-world circumstances often get in the way of the process s ideals. The C3 team would have liked to keep the releases small and frequent, as recommended by XP, but it couldn t, because in reality it was too difficult.

Developers Strayed from the Path

On the Wiki site, Ron Jeffries wrote:

Don is right to have confidence in the C3 folks, whom he knows . However, as I mentioned elsewhere, we have recently found it necessary to have a revival meeting to recommit to our beliefs, because we had strayed fairly far from them. I m quite concerned ”the whole team is ”about what let us get off track so far with no alarms going off. And in this case, I was actually here. So much for the theory that I m indispensible [sic]. [38]

The argument surrounds the question, is XP a high-discipline methodology? The answer seems to be that it is, because if you stray even a little bit from the XP practices, your project is more likely to fail. This is borne out by numerous newsgroup postings by the Extremos.

[36] See the definitions of GoldOwner and GoalDonor at http://c2.com/cgi/wiki?GoldOwner. Notably, this page states that when the GoldOwner and GoalDonor do not have consensus, the project is usually doomed.

[37] Ron Jeffries posting to OTUG ( http://www.rational.com ), subject: Schedule is the customer s problem! October 23, 2000.

[38] Ron Jeffries posting to the C2 Wiki page High Discipline Methodology, http://www.c2.com/cgi/wiki?HighDisciplineMethodology .




Extreme Programming Refactored
Extreme Programming Refactored: The Case Against XP
ISBN: 1590590961
EAN: 2147483647
Year: 2003
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net