views:

177

answers:

6

What type of client is likely to support XP (Extreme Programming) practices?

+2  A: 

If your team achieves great results with a proven track-record, then companies desiring a successful result. If the converse is true, only companies who are wandering blindly will be interested.

There is the odd case where the client will want a certain practices followed. Like a experienced dev manager outsourcing a project to an external firm, or potentially a client who has heard that XP is good in passing but has no real knowledge or experience with it. In the former the experienced consumer will know what he wants and if you do not provide those services they will go elsewhere. If you try to fake it, they will know and be most displeased. The later, it doesn't matter so much as long as they get good results and think it was their own wisdom that brought them forth from the ground.

Either way, it is results that matter.

Now begins my diatribe which so far has inspired much ire:

Would you jeopardize your good practices just to suit a client? If you are staunchly in favour of XP, sell it! If they want you to use a methodology that you strongly disagree with. Tell them that. If you can't come to a consensus, there should be no deal.

Do I tell a baker what grain to use? How hot to have the ovens? Hell no. If I say I want poppy seeds on the buns I don't care how they are put there so long as they are there. Dp I select a baker based on his methods, or on how damn tasty the bread is? Letting a non programmer tell you how to do your craft is just plain bad.

If you are trying to extol the virtues of XP then be upfront, pitch the cost-benefits and ROI. Show them why it is better for them in terms of developer efficiency and defect reduction. If you are working for non-programmers, you are the expert, take the reigns and give advice.

If your team excels at XP and has great results you will have no problem selling any potential client on your practices. Results matter to clients; if you can prove that you consistently produce high quality products within consistent timelines you should have no problem selling your methodology. (with some exceptions that absolutely require waterfall).

vfilby
The customer could reasonably expect that certain development practices are followed to protect their investment. Customers may or may not be able to dictate methods, but they can take their business elsewhere if your methods are not satisfactory to them.
tvanfosson
Would you jeopardize your good practices just to suit a client? If you are staunchly in favour of XP, sell it! If they want you to use a methodolgy that you strongly disagree with. Tell them that. If you can't come to a consensus, there should be no deal.
vfilby
Edited, to explain my position more clearly.
vfilby
That wasn't the question. The question was who would be likely to use it. I agree that there are incompatibilities that make make it not possible to work with a customer. In that case walk away, if you can afford to. Or maybe compromise where you can and work with them.
tvanfosson
Why would the client dictate? He is expected to be **involved** and **responsible** during the development process, and would be required to allocate human resources he might be unwilling to.
emkay
*involved* and *responsible* yes, but he isn't pulling up a chair and completed that new feature he wanted. What the client really cares about is results, a good product with minimum defects. Essentially they just want it to work, the rest is up to you.
vfilby
@tvanfosson, I agree with you. But I think the premise here is flawed. Clients who want to work with XP will have to know about XP, better yet they will have to have a good knowledge of it not just a lobster lunch mention. Results in quality, cost and time is what clients want.
vfilby
Client says I have some regulatory needs that require you to produce XYZ documentation, which you ordinarily wouldn't do. Or maybe they just want all of their stories documented in Word instead of using note cards. Why be a zealot and give up business over something either reasonable or trivial?
tvanfosson
Changing documentation practices is not the same as changing a development methodology (in most cases!). Requiring a development methodology that is different from your core capabilities is probably not going to end up with a happy client.
vfilby
I'm not saying you should compromise your core values. Sometimes you just can't do business with someone. That's ok. I'm just saying that the customer may have legitimate reasons to ask for certain practices -- maybe they need certain auditing practices for SOX. That's ok, too.
tvanfosson
+4  A: 

I'm working for a company which is doing Agile (not strictly XP, but still applicable), and our client base is exclusively government organizations. Once they saw the results of the agile process at work, even those who had requirements to provide documentation in a Waterfall like manner were more than happy to continue to reap the benefits of the agile process.

And, yes, I agree with vfilby. Your customers should care about the results, not how you achieve them.

ckramer
I am touched, I never knew you cared so much :)
vfilby
A: 

I think it probably takes less convincing than it used to for customers to accept agile development practices, particularly XP, since they are now much more mainstream. Customers who have had positive experiences with agile teams in the past are more likely to buy into these methods. It's probably easier for a smaller customer, or a customer with a smaller problem to accept XP if they have concerns about it. With a skeptical customer, I would suggest starting small and building confidence. And make sure you deliver on your promises!

tvanfosson
+1  A: 
  • Either clients who've already had good results on XP projects.
  • Or clients who've swallowed the Kool-Aid.

Which arguably makes these clients few and far between :-)

RoadWarrior
Couldn't agree more.
vfilby
A: 

Almost everyone else seems to be interpreting your question in the context that you are or work for an ISV writing custom software for a client. Is that the situation?

If your question had been something along the lines of what kind of company is likely to adopt XP, then I would say a company who has been burned in the past spending too much time writing developer documentation and designing for reuse only to have to throw it all away as a big waste of time and effort.

Glenn
A: 

The customer has to accept iterative delivery with fixed time, fixed resources, fixed quality (it's working to 100%), and a slightly variable scope, per iteration.

However, it is much more usual that they want to fix time, resources, quality AND scope.

The type of client that is likely to support XP practices, is one that already understands the benefits and drawbacks of the software production system that XP provides.