Xp Customer Quotes

[Quotes to support (or rebut) the arguments of the TheMythicalXpCustomer page, here.]

"One of the things that is unsaid in the XP literature is how to be a customer (analyst)."

You will have to learn how to write UserStories. This may seem like an impossible task at first, but the team will give you the gift of copious feedback on the first few you write, and you will rapidly learn how much ground to cover in each story, and what information to include and exclude. --ExtremeProgrammingExplainedEmbraceChange pg 143

"The XP books only talk about the technical coach, not much about customers and how to be a good XP customer. Maybe someone needs to write a XP book with customers' prospective."

-- AdamLi

"The literature I've seen on XP is essentially silent on the customer experience prior to interacting with a developer. This is the arena of the Customer Coach and an area that deserves more attention."

-- BarbaraWilkie

"I think expecting external customers (and even a lot of internal customers) to understand how to work in an XP world is unrealistic. Certainly we can do a job of education, and hopefully in a few years many more people will be familiar with XP."

-- AnnieGriffin?

"[...] the fundamental principle of XP is the separation of business decisions and technical decisions, reflected in the roles of 'Customer' and 'Programmer'. [...]In XP, we place the responsibility for 'what' under the Customer role, and 'How' under the Programmer role."

-- RonJeffries

"In [XP], we identify two principal roles. For better or worse, they are called Customer and Programmer. Customers are typically BUSINESS PEOPLE and Programmers are, we hope, TECHNICAL PEOPLE. It's what they are called. The names of the roles are Customer and Programmer. It's too late to change the books now. Get used to it. ;->"

-- RonJeffries

"XP is not a programming discipline; it is the rules for the relationship between developers and business people. [...] XP defines the demarcation between developers and business people. [...] Kent doesn't call this XA, he calls it "Extreme Business". The values and principles of XP {Short cycles, intense feedback, lots of communication} are employed in a set of business practices to ensure that documentation, deployment, sales, marketting, etc are all coordinated and managed. This is something we are trying out at Object Mentor. Preliminary results are very positive."

-- RobertMartin (C.)

"It is always the case that business decisions and technical decisions can be separated. Business people specify feature content and priority. Technical people specify feature cost and implementation. However, these decisions must be made in concert! A decision of business priority cannot be made without knowing the cost of the feature. An estimate of cost cannot be made without knowing what the business expects from the feature. Thus, the development plan is assembled from the detailed decisions made by the business and technical people."

-- RobertMartin (C.)

"Specialization is not by choice. When things get too complicate, and no single person can master all, then some of us become a specialist for something."

-- JinLi?

"Now for the conundrum. How does one effectively deal with a supremely dysfunctional set of stakeholders that sometimes appear to be fundamentally at odds and geographically dispersed? This is what my team and I have been dealing with. It seems problematic to sit one of them down with a developer(s) when this stakeholder can be contradicted, overruled or otherwise swayed in their perspective by the opinions of other stakeholders."

-- JohnGreene?

"In rare cases, the immediate customer may be spending his own money, but reality is almost always more complicated than that. Usually, there are numerous sponsors, stakeholders, process gatekeepers, and others, all of whom have legitimate interests in influencing the project. Dealing directly with that complexity is hard, slow, and error prone. XP's approach is to borrow the "proxy" pattern and call for one customer delegate. Whether the "XP customer" is the sponsor, the sponsor's delegate, or a consultant reporting to multiple people and committees, the XP Customer's role is to create the illusion of a single customer with whom the XP team can work as though that's all there were. The point is to insulate the engineering team from this messy reality and keep the business problems on the business side of the solution. The main requirement for this to work is for the XP Customer to be so completely in command of the multiple (often conflicting) demands that the other stakeholders can safely let the XP Customer "drive". If the business side cannot get their act together to that extent, either the "driver" needs to call home for directions at each intersection or the coordination and prioritization problems fall by default to the engineering team. Either way, XP becomes impractical. When you add all this up, XP Customers can seldom get away with being merely domain experts; they also need to be skilled diplomats or politicians to manage and balance the expectations of multiple constituencies. What of Extreme Analysis? I'm sure there's an analysis component to XP, but I think it's limited in several ways. First, since XP largely eschews specialization, analysis will be a part of what everybody does, not a separate job. Second, within the team, there will be *systems* analysis - coordinating the requirements the customer provides into a coherent solution. That is, it will look a lot more like design. Third, the functions of the business analyst in traditional methods are not up to the engineers at all. If that's what you want to do, we still need you, but you won't be working with the customer, you will BE the customer."

-- LanceZant?

XP substitutes for this a "collaborative" conception of requirements: you, and Bob (the customer), and Fred and Ethel and so on, who are the developers, form a single team. You win points for delivering software worth more money than was invested in making it - in the judgement of those investing that money. You lose points when you spend time that doesn't directly or indirectly contribute to delivering such software.

Say it shorter.

 "The. Customer. Steers."

You give them the steering wheel, and they point the project and steer it towards its destination. You provide a gas pedal, an odometer, and (of course) an engine.

-- PhlIp

["Nice set of quotes. Thank you for collecting them all in one place." -- JeffGrigg]