Ci lamentiamo spesso che in Italia le metodologie agili non trovano spazio e non riscuotono la fiducia dovuta da parte dei committenti che vogliono tradurre in sofware il loro business.
Ma siamo sicuri che solo in Italia ci sia il problema di saper vendere XP? Recentemente sulla lista XP americana XP list un bel thread sull'argomento ha coinvolto persone di tutto il mondo:

Thread XP in Sales

Invito chiunque sia interessato a migliorare il proprio processo di sviluppo a leggere tutto il thread. Di seguito vorrei però riportare una mail del grande Ron Jeffries, che ha partecipato alla discussione.
Il mio messaggio non vuole essere "XP non è facile venderlo in America, figuriamoci in Italia, quindi lasciamo perdere", ma anzi vuole essere un motivo per aumentare la nostra "responsabilità" nel migliorare le nostre capacità di comunicazione nel proporre un modo di lavorare che sappiamo essere molto proficuo ed efficiente per il committente. Aggiungerei anche che è importante sapersi mettere in modo onesto nei panni del committente, per comprendere le sue paure e i suoi desideri.
Spero possa partire un confronto tra di noi.


On Sunday, March 5, 2006, at 4:43:35 AM, Dan Bunea wrote:

> It seems that Henrique has helped me a great deal here. Our competitors
> usually use waterfall, and they "guess" prices and lenght in time for
> development withought really analysing the product to be developed, assuming
> incredible risks.

> On the other hand, the customers like to have a price with as little
> involvment as possible, as fast as possible, and they are given this by our
> competitors, which usually are much bigger names then us. It has happened
> that someone has told our sales representative, that we're trying to hide
> the real cost and we will go for ever and ever with the project, and ask for
> more and more money, and he will be have to pay as the product won't be
> finished. My response was that he's actually in the control of what's being
> done, "steering" direction, and seeing progress all the time, and planning
> for a few month releases on which he'll have the cost up front, but he had
> already made his decision against us.

The story above makes me think that you are bidding an incremental X
money per iteration response to a customer who wants a fixed price.
It is not necessary to do that.

The reason I asked whether you know how to do an XP Release Plan is
that this can be done at the very beginning of the project. The best
way -- and it's a good sales approach as well, I'd think -- is to
have reps from the technical team sit down with the customer, draw
out the stories (requirements). Then the team estimates the stories,
asking the customer questions about them. When the estimates are
done, the team uses their experience and estimated velocity to say
how long the project will take.

During the process, if I were in a sales situation, I'd want the
sales person to be making note of each case where the technical team
asked questions of the customer and changed their estimate or
audibly changed their design view of the system. In a subsequent
sales meeting, or a later part of this one, the sales person would
then be in a position to summarize those situations something like
this:

Mr Customer, I noticed some interesting things in this session,
situations where our approach has extra value to you. For example,
when we were talking about the Flying Widget feature, the team had
at first thought that was a four-point story but conversation with
you told them it was only a two. Without that conversation, our
bid would have had to be higher, and we might not have provided
what you really need.

If you're talking with organizations who merely come in, do a
superficial look at what you want and then guess a price and a
solution, there's always uncertainty. Whether they raise their
price to cover those contingencies, or whether they make it up by
charging extra for changes, you can be sure you'll be paying the
price.

We work closely with you all through the project, to ensure that
there's clear understanding between us on what you really want,
and to keep your costs as low as possible. And remember, our
approach shows you a working program all the time. You'll know how
we're doing and will be in a position to guide the project to
success.

(Blah blah more sales stuff)

> Then we have the sales staff, somehow confused by the new
> approach, that need real guidance, step by step, in much detail.

Yes, no doubt they do. And to do the planning well, the technical
team need training and practice as well. Based on what Kent Beck had
the C3 team do a decade ago, and what we wrote in /XP Installed/,
and our experience since then, Chet and I have been teaching
planning and estimation tutorials at the Agile conferences for
years, and presenting the material for our clients. Perhaps you and
some of your gang could attend one of our conference sessions.
There's also good material in Mike Cohn's /Agile Estimating and
Planning/ book, and don't forget Beck and Fowler's /Planning XP/.

If I were going into the contract programming business, I'd work up
a sales approach around the ideas of XP and Agile planning. I'd
involve technical estimators early; I'd describe the burn charts
we'd provide; I'd explain our approach to change; and so on. I'd do
this with gentle comparisons to the way other companies work,
raising the customer's confidence in our way and their concerns
about how a company that just guesses could possibly do a decent job
for them.

I'd work with the staff to practice and hone our approach to
estimation and planning and sales, so that we'd continue to get
better and better. I'd get training for the people, and I'd work
with customers, to get feedback on how we're doing. I'd work with
prospects who didn't buy our service, to find out why they didn't,
what we could have said -- and to find out how satisfied they are
with what they got from the other company. And I'd do that all the
time.

That's what I'd do if I were a sales guy. I'm not -- it's hard work
that needs to be done well.

Ron Jeffries
www.XProgramming.com
Wisdom begins when we discover the difference between
"That makes no sense" and "I don't understand". --Mary Doria Russell