Ron,

I appreciate you stating your needs and fears clearly. What I heard was:
* You need to have people use the ideas in XP
* You are afraid that if they knew their chances of benefiting, the
wouldn't even try to use the ideas in XP

I suspect that the actual percentage of people who invest in trying XP and
who actually achieve noticeable improvement is much less than half. There
are more than 100K copies of XP Explained out there (which I suppose is
considerably less than 1% of programmers). That many people invested $30-$50
(depending on where they bought it) plus whatever time they took reading it
and trying things. I have yet to see the kind of changes I would expect if
50K programmers started working responsibly and accountably.

There are some substantial changes ushered in by XP--continuous integration
and, to a lesser extent, developer testing. However, these haven't created
any kind of sea change in software development. I'm still shooting for the
kind of change that Japanese manufacturing went through between 1960 and
1980, from a byword for cheap and shoddy good to an exemplar of quality and
value.

I'd like to examine the fear about people not even trying XP if they knew
the risks. I think they already know the risks, programmers and executives
alike. They've been through CASE, RUP, CMM, and any number of lesser "game
changing" movements with their fundamental problems still intact. That they
are willing to consider XP, Scrum, model-driven development, etc. shows that
they haven't given up hope. However, they are (understandably) jaded.

I've heard several expressions of frustrations on this list that Scrum is
eating our lunch. If we want to make a comeback, and comeback it certainly
would be at this point, I don't think we can play their game. They have
stories about how all you have to do is deliver every month, how teams
manage themselves, how two days of training make one a master. They aren't
telling the whole story. If we try to convince people to use XP using the
same tactic, not telling the whole story, people will ignore us. The Scrum
partial story is much more attractive than the XP partial story we've been
using to date.

Absolute openness about the costs, pains, risks, and rewards of XP is the
right thing to do. It's a leadership position and it has a chance of
working. I'm afraid that continuing to try to tell an attractive story will
lead this community to become a cult of irrelevant technical competence. I
would be satisfied to see a wiki full of stories about how people spent $N,
got nothing for it, and here's what they would do differently. XP would be
better for it. Then we could go to people with big checkbooks and say, "Big
risk, big reward, here's what we've learned, here's how you manage it."
Since there aren't big commercial players, crowdsourcing is the only way I
can see to gather the information we need.

Once again, I invite everyone here to record their organization's experience
with XP, good or bad, at http://xpprojects.wikispaces.com. It's a chance for
you to contribute to the community and reflect on your experience. Given the
number of people on this list, we could, should we choose to, quickly have
hundreds of stories from which to learn. This learning is a prerequisite to
being able to say, twenty years from now, that software development is an
exemplar of quality and value.

Best regards,

Kent Beck
Three Rivers Institute

_____

From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of Ron Jeffries
Sent: Wednesday, March 26, 2008 7:15 AM
To: extremeprogramming@yahoogroups.com
Subject: Re: [XP] Success rates of Agile Transitions



Hello, Niraj. On Monday, March 24, 2008, at 10:02:17 AM, you
wrote:

>> Suppose the results were that half of all attempts do not do well.
>> (I suspect that's the case.)
>> ...
>> Meanwhile, what would the executives we're talking to do and decide?

> Wouldn't what they do be influenced by data and the consultants or
> internal pro-agilists they are talking to?

The point is, if the data said that half of all attempts do not do
well, without some clear indication of why, people might well not
undertake to try the new thing. Which would mean that 100 percent
would not benefit, whereas now, half do.

> I'm pretty sure you do this already, but you would probably need to
> spend some time observing the organization during the procurement
> phase. During this time, with experience and data in hand, you would
> hope to be able to identify which practices need to be implemented,
> changed or encouraged to help the organization increase code quality,
> customer satisfaction, speed, save costs or increase profits (any or
> all. The order would most likely be determined by the customer with
> your help).

Of course. I always like to start an engagement with an assessment.
I think that James Grenning and I were the first people ever to
start that way, quite some years ago, and it is quite valuable.

But if we had published data ... so what?

> With industry-specific data, we could, in earnest, provide an idea of
> total cost estimates and total time required to achieve the benefits.
> Mixed with the consultant's experience level the following estimates
> could be submitted:
> - A time range for how long the right practice mix would take to set.
> - A time range of when the organization would begin to see improvement
> in the areas mentioned above would be provided.

I don't believe that such data would provide any useful
information. I could be wrong, but imagine that you knew the
industry data on the cost of building a car. Guess what ... it's
all over the map. It doesn't tell anyone what to do.

> What they decide is their own prerogative. We can only hope to give
> them a better picture of what needs to happen, how long it would take
> to happen and what benefits they could expect.

Yes. And I'd be willing to answer at least some of Kent's
questions, for a specific customer whom I had assessed. (Others, I
can't answer honestly, and frankly don't think anyone else can
either.)

But I do not see how industry numbers would help me answer that
question.

>> Still, I'd like to know, mostly because I don't really care whether
>> "agile" goes forward or not. I'm not sure we all feel that way.

> How does one mostly want to know something for something they don't
> care about? Were you trying to tell me that you're interested in the
> numbers for nothing more than curiosity's own sake?

I don't care about "agile". I care about the natural laws of good
software development; I care about having a good time; I care about
helping interesting people do interesting things.

And I think the numbers would be interesting. Since I don't care
whether "agile" goes forward, I'm not opposed to hearing the
numbers, even though I suspect they would be damaging to the
movement, because they would sound bad and be hard to use wisely.

>>> As for what constitutes agile, I don't really think one would
>>> need to do that to determine an industry wide success rate. I
>>> think the high level question is simple: Was the cost of
>>> attempting to adopt or transition to agile worth the benefit?

>> Do you mean "Was the cost of attempting to adopt or transition to
>> //whatever you call// agile worth the benefit?
>> If not, the question really does seem to me to call for a
>> definition of its terms.

> I want to say that "whatever you call agile" would apply, but then
> other could argue that the data could become rather soiled.

Rather.

> Instead of "agile" could we state practices instead? I know that
> leads to the argument "Which practices?", but that seems to be
> easier discussion as opposed to defining agile in a way that would
> ensure reliability in our data. Do you think that would be an
> easier definition to prepare for respondents & users of the data
> to understand as opposed to providing a definition for agile?

There have been some studies of the effect of some practices, such
as pair programming and something somewhat like TDD. I've not seen
anything very striking come out but there may be indications that
these are good things.

However, even those much more narrow studies tell a given company
essentially nothing about the benefits they might obtain. Much more
so a study on "agile".

Ron Jeffries
www.XProgramming.com
You do ill if you praise, but worse if you censure,
what you do not understand. --Leonardo da Vinci






[Non-text portions of this message have been removed]