I don't think the question of the success rate of XP is all that
complicated. No, we don't have the data, but a data-oriented person (or
community) could get it.

If a CIO asked, "What are the costs, benefits, timeline and risks of Six
Sigma?" someone from a Six Sigma consultancy could provide an answer. Same
for Scrum. Lean Manufacturing. TQM. Whatever. If our community doesn't have
an answer it's because we choose not to have an answer.

What I object to in the discussion so far is the disrespect in the
responses--"You are stupid for asking the question, that's not the right
question to ask, an answer wouldn't mean anything." The people asking the
question, both here and the audience for which they are a proxy, aren't
stupid. They just have a different perspective. Will we answer the question?

In the spirit of data over speculation and the spirit of crowd-sourcing over
heroic action, I've created a wiki to gather information about transitions:
http://xpprojects.wikispaces.com/. Please consider taking ten minutes to
record your organization's experience there.

Regards,

Kent Beck
Three Rivers Institute

_____

From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of John A. De Goes
Sent: Friday, March 21, 2008 10:29 AM
To: extremeprogramming@yahoogroups.com
Subject: Re: [XP] Success rates of Agile Transitions




Hi Kent,

You can't predict what will happen in specific cases. At best, you can
say something like, "Companies similar to yours, as judged by criteria
A, B, C, have an X% chance of successfully transitioning to agile, at
a total average cost of Y$, and should the transition be successful,
the companies have a Z% chance of increasing/decreasing ROI by at
least W% after at most M months."

If you try to do more than that, then you're not showing guts --
you're spouting BS.

Many consultancies and tool providers do make hard claims in specific
cases. "We'll improve your production of function points by 153.2% in
6 months, which will double your ROI!" But there is no such thing as a
crystal ball. The future is impossible to predict. The best you can do
is provide statistics, which do not apply to specific cases, but to
large aggregates of cases.

Back of the envelope calculations provide somewhat more value than
none at all, but not by much. They're based on assumptions. If those
assumptions aren't grounded in statistics, but in experience, you
can't quantify them, so you can't provide reliability estimates. If
the assumptions are grounded in statistics, then they don't apply to
specific cases.

Most software projects fail. Most companies fail. Most attempts at
transitioning to new methodologies fail. Most attempts at changing
management style also fail. Doing nothing fails, and trying to do
something fails.

Success is elusive. That's why the industry is so fragmented into
thousands of development methodologies, tens of thousands of languages
and frameworks and tools and books and consultants and everything else.

Does that mean we shouldn't try to do anything? That we should stay
where we are, and not aim for improvement? A CIO might imagine so, if
things are 'good enough'.

If things are not good enough, it's a tacit admission that what you're
doing now has failed you. How did you adopt what you're doing now?
Probably, not by statistics -- and if you didn't adopt what you're
doing now by looking at statistics, why do you demand them to try a
different approach, especially when you can try that approach on a
small scale and see if it works for you? And if you adopted what
you're doing now by statistics, then your case has illustrated the
obvious: that statistics don't apply to specific cases, only to
aggregates. Maybe you tried plan-based development because statistics
showed it works in 90% of cases and has all these other wonderful
benefits. A lot of good those numbers do you when things are going
poorly.

Numbers are good for persuading people. They seem objective and
scientific. How do you argue with the number 5? The number 5 is a
fact, you can't dispute it. Statistics, if properly collected, can't
be argued with, because they describe what has happened in known
cases. If you fly a small plane, your chances of dying in a plane
crash are 1 in 10,000 per flight. That's a fact. You can't argue with
that. However, some people have died their first flight in a small
plane, and others have survived twenty or thirty thousand flights.

Statistics are useful, but I must emphasize again and again: they
can't be used to predict the outcome in specific cases.

Now suppose we had detailed statistics on rates of failure for
transitioning to agile. In order to be even slightly meaningful, we'd
need a lot more statistics than that. What are the rates of failure
for continuing to do whatever you're doing now (i.e. doing nothing)?
Likely they're very high. What are the rates of failure for
transitioning to every other development methodology (or at least the
more popular ones)? Do they differ at all from the rates of failure
for transitioning to agile, and if so, exactly how do they differ?

Until you have this information, I don't think hunting down a single
statistic that quantifies failure rates for agile transitions is going
to help you. I really don't.

Regards,

John A. De Goes
N-BRAIN, Inc.
http://www.n- <http://www.n-brain.net> brain.net
[n minds are better than n-1]

On Mar 20, 2008, at 4:49 PM, Kent Beck wrote:
> Early in the life of XP a few leaders in a large division of a
> gigantic
> corporation came and asked what it would cost, time and money, to
> roll XP
> out organization-wide and when they could expect what kind of
> benefits. We
> said, being good XPers, try a little and we'll see. They asked
> again--how
> much and when? We said try a little and we'll see. They went away,
> never to
> be heard from again.
>
> IWe failed. We could have given them an envelope calculation of the
> total
> training and consulting cost. We could have (fairly) confidently
> predicted,
> given their current performance, when they could see what kinds of
> improvement. Rather than extend ourselves to communicate in their
> terms,
> though, we (as I see it now out of fear) stuck to our own frame of
> reference
> and severed the relationship. Bad move financially. Bad move for XP.
>
> That's why I like the OPs question. It is framed in executive terms.
> Do we,
> as a community, have the guts to respond in those terms?
>
> Regards,
>
> Kent Beck
> Three Rivers Institute
>
> _____
>
> From: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
yahoogroups.com
> [mailto:extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
yahoogroups.com] On Behalf Of Steven Gordon
> Sent: Thursday, March 20, 2008 1:07 PM
> To: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
yahoogroups.com
> Subject: Re: [XP] Success rates of Agile Transitions
>
> On Thu, Mar 20, 2008 at 11:59 AM, Chris Wheeler
> <christopher. <mailto:christopher.wheeler%40gmail.com> wheeler@gmail.
<mailto:wheeler%40gmail.com> com
> >
> wrote:
> >
> > On Thu, Mar 20, 2008 at 2:54 PM, Steven Gordon <sgordonphd@gmail.
> <mailto:sgordonphd%40gmail.com> com> wrote:
> >
> > > If agile development is the opposite of big design and planning up
> > > front, why would we even suggest a big-bang agile adoption.
> > >
> > > We should suggest first executing an agile adoption in a small
> > > representative slice of the organization, and frequently monitor
> the
> > > issues, obstructions, morale, improvements, and of course, costs
> > > incurred and value produced. The CIO will then have real
> information
> > > that is directly applicable to their organization to support an
> > > informed decision as to whether or not to proceed with
> transitioning
> > > the entire company.
> > >
> >
> > This doesn't help agile adoption in-the-large. Publications such as
> Harvard
> > Business Review and organizations such as Hackett exist to offer
> up data
> > that says 'best-in-class adoptions of X cost $Y and paid for
> themselves
> > after Z years'. People in roles such as CIO, CEO, etc. read these
> > publications as due diligence. This is why Lean Sigma / Six Sigma
> has such
> > a
> > large adoption rate - practitioners share their data, they tell
> how long a
> > program took to pay back it's startup costs, and they report
> whether they
> > felt the program is returning on it's cost, over time.
> >
> > It's more than prudent for agile to support and encourage the
> adoption of
> > such practices of data sharing, talking about 'best-in-class', and
> making
> > an
> > attempt to appeal to those seeking this information.
>
> Do we sign up for fixed price waterfall software development project
> just because our competors do? Do we make false promises of guaranteed
> success just because our competitors do? No, we tout the greater
> benefit of collaborating via the frequent, iterative delivery of
> value, gathering of feedback, and adapting to what the feedback tells
> us! Some of us even put our money behind that approach by saying the
> customer can cancel anytime the do not believe the value of what is
> being delivered is worth the cost and get what they have paid for thus
> far.
>
> A large agile adoption is not so much different than a development
> project. Every one is different, different people to work with,
> different obstacles to be navigated, different feedback to leverage,
> different benefits to accrue. To tell some CIO that his/her company
> is just like dozens of others and the agile adoption will cost some
> fixed amount and will have some specific predictable gains is simply
> false, just as it would be to make such promises for a software
> development project.
>
> On the other hand, to tell the CIO that a small pilot project will
> provide much more applicable information about the costs and benefits
> of an agile adoption at his/her unique company and quote a fixed cost
> for doing such a pilot is a much more honest way to do business. The
> response will also give a good indication of whether the company is
> ready for agile or is simply looking for a quick-fix silver bullet.
> If they would not accept an agile approach to the agile adoption, then
> they will be unlikely to accept the agile projects that will result
> from that adoption.
>
> Steve
>
> >
> > Chris.
> >
>






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