How do XP projects fail?
Isaac Gouy
How do XP projects fail?
When the team fails to follow XP practices?
When the customer cancels the project?
When the customer takes the system out of operation?
Ron Jeffries
>"Fail-safe systems fail when they fail to fail safe."
>
>How do XP projects fail?
>
>When the team fails to follow XP practices?
If the team isn't following XP practices, is it an XP project after all?
>When the customer cancels the project?
If the project is costing more than it is worth, is it a failure to cancel it
... or is it a success?
>When the customer takes the system out of operation?
Depends why they do that, does it not?
I think it depends on what we mean by "fail". What does it mean to you for a
project to fail?
Regards,
--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.
Steve Jorgensen
wrote:
>On 8 Jan 2004 17:03:51 -0800, ig...@yahoo.com (Isaac Gouy) wrote:
>
>>"Fail-safe systems fail when they fail to fail safe."
>>
>>How do XP projects fail?
>>
>>When the team fails to follow XP practices?
>
>If the team isn't following XP practices, is it an XP project after all?
>
>>When the customer cancels the project?
>
>If the project is costing more than it is worth, is it a failure to cancel it
>... or is it a success?
>
>>When the customer takes the system out of operation?
>
>Depends why they do that, does it not?
>
>
>I think it depends on what we mean by "fail". What does it mean to you for a
>project to fail?
>
>Regards,
First off, I don't know why I repeatedly feel compelled to post in these
threads when I probably have less real-world experience with XP than most
everyone here, but I guess it's just the zeal of a newby enthusiast. I hope
no one minds that I post like I know what I'm talking about.
Reading your post, I thought of another way to frame this. What's the
difference between the way projects fail with XP vs the most commonly used
non-XP techniques in the marketplace?
One obvious thought that comes to mind is simply regarding "release often".
If a project is terminated because the cost/benefit does not pan out, it seems
to me that this realization would become usually apparent with "realease
often" than without it. Also, if it turned out that the original project
concept was not valuable enough to justify the cost, but something else would
be, again, this can happen sooner, and some of the effort already done may
contribute to fulfilling the new idea.
Essentially, instead of a whole failed project after a large investment, we
simply end up with a very useful spike.
Randy A. Ynchausti
> How do XP projects fail?
XP projects will fail the same way non-XP projects fail -- the expectations
of the client are not met. It doesn't matter what process a development
team uses. When the client doesn't get what they want and/or can use, at
some point, they will stop wasting money on it.
This is rarely what the development team will say after the project is
cancelled (has failed). The development team usually says some variation
of, "The management just didn't get it!" From the developer's perspective,
management is too dumb to see what a great thing they have. And if the
client is kind, he will say some variation of, "That problem is too hard to
be solved with software."
XP is a software development process. Software development processes are
rarely to blame for failed projects. Most of the time, people are the
reason that software projects fail. The next most influential factor is the
complexity of the problem being tackled. Somewhere down the list, in about
the 64th position of the next most influential factors for project failure,
is software development process.
If anyone ever tells me that "such-and-such" project would not have failed
if they had used XP, I kindly thank them for their help and then look for
the real reason. I hope you do too.
> When the team fails to follow XP practices?
This is not a very influential factor as to why a software development
project fails. If the team fails to follow XP practices, that means that
the members of the team don't feel they are getting enough value out of the
process compared with the pain it causes.
> When the customer cancels the project?
This is the final act of the client in a failed project. It is not the
reason why the project fails. If a client cancels a project, it means that
the client's expectations have not been met.
> When the customer takes the system out of operation?
The reason clients take systems out of operation is that they no longer feel
they are getting the value that they want. If the system is taken out of
operation before "customer-acceptance," I consider the project a failure.
If "customer-acceptance" is given base on conditions of future development
and then is taken out of service before those conditional elements are
developed and deployed, most of the time I consider the project a failure.
But the act of taking the system out of operation is a symptom and not the
reason for the failure.
I hope these comments have met your expectations!
Regards,
Randy
Otis Bricker
news:0p7svv8lkbdnkfpmv...@4ax.com:
> On 8 Jan 2004 17:03:51 -0800, ig...@yahoo.com (Isaac Gouy) wrote:
>
>>"Fail-safe systems fail when they fail to fail safe."
>>
>>How do XP projects fail?
>>
>>When the team fails to follow XP practices?
>
> If the team isn't following XP practices, is it an XP project after
> all?
>
If the team is TRYING to follow XP practices but having problems because
they are difficult to understand or actually do, you might still consider
it an XP project. To do so would require, in my view, a serious attempt to
understand and implement XP. It could be that XP is just too hard for mere
mortals to perform.
>>When the customer cancels the project?
>
> If the project is costing more than it is worth, is it a failure to
> cancel it ... or is it a success?
>
This may depend on the point its cancelled.
>>When the customer takes the system out of operation?
>
> Depends why they do that, does it not?
>
>
"We planned on using this system forever and after only 25 years we are
dropping it because we are leaving this part of the market. Another XP
failure!"
> I think it depends on what we mean by "fail". What does it mean to you
> for a project to fail?
>
Wasted time and/or money without providing adequate business value? This
misses by a bit since I would not consider a short-lived project that
quickly proved itself unworthy of further funding a failure. Running it to
completion first and then cancelling would be the failure. Though perhaps
thinking of the short project as a minor failure, without prejudice, is a
better model. We learn from our mistakes.
Otis
Ron Jeffries
wrote:
>Ron Jeffries <ronje...@REMOVEacm.org> wrote in
>news:0p7svv8lkbdnkfpmv...@4ax.com:
>
>> On 8 Jan 2004 17:03:51 -0800, ig...@yahoo.com (Isaac Gouy) wrote:
>>
>>>"Fail-safe systems fail when they fail to fail safe."
>>>
>>>How do XP projects fail?
>>>
>>>When the team fails to follow XP practices?
>>
>> If the team isn't following XP practices, is it an XP project after
>> all?
>>
>
>If the team is TRYING to follow XP practices but having problems because
>they are difficult to understand or actually do, you might still consider
>it an XP project. To do so would require, in my view, a serious attempt to
>understand and implement XP. It could be that XP is just too hard for mere
>mortals to perform.
It could be, but it isn't. I am mortal -- although I am in no hurry to prove
that -- and I can do it pretty well, and I've taught upwards of one or two
hundred other people as well.
Software development is never easy, mind you, but the skills required to do the
XP practices are not difficult. They do require ... practice.
>
>> I think it depends on what we mean by "fail". What does it mean to you
>> for a project to fail?
>
>Wasted time and/or money without providing adequate business value? This
>misses by a bit since I would not consider a short-lived project that
>quickly proved itself unworthy of further funding a failure. Running it to
>completion first and then cancelling would be the failure. Though perhaps
>thinking of the short project as a minor failure, without prejudice, is a
>better model. We learn from our mistakes.
Yes. And the practice of having every feature defined in part by executable
tests detects technical mistakes early and often, and the practice of releasing
the software frequently detects business mistakes early and often. It's kind of
cool how nifty feedback is ...
Otis Bricker
> On Fri, 09 Jan 2004 12:00:41 -0600, Otis Bricker
> <obri...@my-dejanews.com> wrote:
>
>>Ron Jeffries <ronje...@REMOVEacm.org> wrote in
>>news:0p7svv8lkbdnkfpmv...@4ax.com:
>>
>>> On 8 Jan 2004 17:03:51 -0800, ig...@yahoo.com (Isaac Gouy) wrote:
>>>
>>>>"Fail-safe systems fail when they fail to fail safe."
>>>>
>>>>How do XP projects fail?
>>>>
>>>>When the team fails to follow XP practices?
>>>
>>> If the team isn't following XP practices, is it an XP project after
>>> all?
>>>
>>
>>If the team is TRYING to follow XP practices but having problems
>>because they are difficult to understand or actually do, you might
>>still consider it an XP project. To do so would require, in my view, a
>>serious attempt to understand and implement XP. It could be that XP is
>>just too hard for mere mortals to perform.
>
> It could be, but it isn't. I am mortal -- although I am in no hurry to
> prove that -- and I can do it pretty well, and I've taught upwards of
> one or two hundred other people as well.
>
Sorry. I hadn't meant to imply that XP was hard. But that a team REALLY
trying to understand and do XP might be counted as an XP team. And that
any failure in such a case could then be laid on XP for being too hard.
Of course, you are free to think that such a team would not fail often.
And you may well be right. I don't think XP sounds hard, but based on the
many folks that seem to completely misunderstand it I have to think that
some people just cannot get it.
> Software development is never easy, mind you, but the skills required
> to do the XP practices are not difficult. They do require ...
> practice.
>>
>>> I think it depends on what we mean by "fail". What does it mean to
>>> you for a project to fail?
>>
>>Wasted time and/or money without providing adequate business value?
>>This misses by a bit since I would not consider a short-lived project
>>that quickly proved itself unworthy of further funding a failure.
>>Running it to completion first and then cancelling would be the
>>failure. Though perhaps thinking of the short project as a minor
>>failure, without prejudice, is a better model. We learn from our
>>mistakes.
>
> Yes. And the practice of having every feature defined in part by
> executable tests detects technical mistakes early and often, and the
> practice of releasing the software frequently detects business
> mistakes early and often. It's kind of cool how nifty feedback is ...
>
I agree. Again, this was more an attempt to handle the idea that lots of
XP projects may 'fail'. Usually in the first iteration or two when the
business value of the project is really seen. I wouldn't view these as
failures since they might well have saved a lot over what more
"standard" practices would have done. The advantage of XP here seems
obvious to me.
Otis
Ron Jeffries
wrote:
>I agree. Again, this was more an attempt to handle the idea that lots of
>XP projects may 'fail'. Usually in the first iteration or two when the
>business value of the project is really seen. I wouldn't view these as
>failures since they might well have saved a lot over what more
>"standard" practices would have done. The advantage of XP here seems
>obvious to me.
And to me.
And I still don't know what "fail" means, to you, to me, or to the world at
large. I'm pretty sure that blaming failure, whatever we mean by it, on a
process, XP or otherwise, is looking at the wrong end of the issue. If the
results were not satisfactory, someone has made a mistake, and it probably
wasn't Kent Beck, it was more likely someone on the project.
Unless we believe that sh1t happens. And I don't believe that. I believe that
sh1t is caused.
Regards,
Isaac Gouy
RON:
> If the team isn't following XP practices, is it an XP project after all?
Seems like we should say it is - if the intent was to use XP.
OTIS:
> >Usually in the first iteration or two when the
> >business value of the project is really seen. I wouldn't view these as
> >failures since they might well have saved a lot over what more
> >"standard" practices would have done.
Doesn't this indicate a failure mode particular to incremental
methods?
Failure to cancel a failing project after the first couple of
iterations.
(Do we have examples of the development staff pushing to cancel an XP
project that wasn't delivering?)
OTIS:
> Though perhaps thinking of the short project as a minor failure, without
> prejudice, is a better model.
Smaller failures are preferable to expensive disasters (for the
customer) but they want success ;-)
RON:
> I'm pretty sure that blaming failure, whatever we mean by it, on a
> process, XP or otherwise, is looking at the wrong end of the issue.
Then so is crediting success to a process.
> Unless we believe that shit happens.
I believe the insurance industry refers to "Acts of God".
> And I still don't know what "fail" means, to you, to me,
> or to the world at large.
Different things to different folk, I expect.
Let's agree that "Project Termination Doesn't Equal Project Failure"
http://www.cs.unc.edu/~welch/class/comp145/media/docs/Boehm_Term_NE_Fail.pdf
Here's one rationale: economic criterion
http://www.cioupdate.com/reports/article.php/1563701
Isaac Gouy
> XP projects will fail the same way non-XP projects fail -- the expectations
> of the client are not met.
Yes, so there are all the usual project management issues of
clarifying expectations and managing risk. My impression was that
several XP practices are intended to address these issues.
-snip-
> If the team fails to follow XP practices, that means that
> the members of the team don't feel they are getting enough value out of the
> process compared with the pain it causes.
Really changing working practices is hard - couldn't this also be due
to lack of resources for training?
> The reason clients take systems out of operation is that they no longer feel
> they are getting the value that they want.
ROI?
> If "customer-acceptance" is given base on conditions of future development
> and then is taken out of service before those conditional elements are
> developed and deployed, most of the time I consider the project a failure.
Seems reasonable.
Robert C. Martin
When the team fails to regularly deliver something valuable.
Phlip
> Isaac Gouy wrote:
>
>>"Fail-safe systems fail when they fail to fail safe."
>>
>>How do XP projects fail?
>>
>>When the team fails to follow XP practices?
>>When the customer cancels the project?
>>When the customer takes the system out of operation?
>
> When the team fails to regularly deliver something valuable.
When the team fails to regularily increase end-users' productivity.
(That definition zooms in on the word "valuable".)
--
Phlip
http://www.greencheese.org/LucidScheming
-- The first few lines of code must "hook" the
computer, and make it "care" about the program --
jarod
"Robert C. Martin" <uncl...@objectmentor.com>
??????:298300di2kdbjei7a...@4ax.com...
begin with the end in mind.
Phlip
>> >How do XP projects fail?
>> When the team fails to regularly deliver something valuable.
>>
> Yes software is for use, and software process (all other process) should
> begin with the end in mind.
You missed the word "regularily". On an Agile project it means small
incremental releases, deployed like clockwork. Every two weeks is best.
With the highest business value features in the earliest releases is
bestest.
Beginning with the end in mind is not good enough; that end might never
come.
--
Phlip
http://andstuff.org/CelebrityImpersonations
-- All analysis and no code makes Jack a dull boy.
All analysis and no code makes Jack a dull boy.
All analysis and no code makes Jack a dull boy. --
jarod
"Phlip" <phli...@yahoo.com>
??????:XorMb.56012$hu1....@newssvr31.news.prodigy.com...
> jarod wrote:
>
> >> >How do XP projects fail?
>
> >> When the team fails to regularly deliver something valuable.
> >>
> > Yes software is for use, and software process (all other process) should
> > begin with the end in mind.
>
> You missed the word "regularily". On an Agile project it means small
> incremental releases, deployed like clockwork. Every two weeks is best.
> With the highest business value features in the earliest releases is
> bestest.
>
(always short than a week) in my team .
> Beginning with the end in mind is not good enough; that end might never
> come.
/*This week*/ is very useful and important.
Phlip
> Hoho, I miss the point. But I always set a clear goal in a iterate process
> (always short than a week) in my team .
Are you the Onsite Customer?
Are your iterations always the same length?
--
Phlip
http://www.greencheese.org/AndNowaNitelyLitelyUrbanOne
-- Because I'm the sysadmin. That's why. --
jarod
"Phlip" <phli...@yahoo.com>
??????:iOrMb.56021$dy1....@newssvr31.news.prodigy.com...
> jarod wrote:
>
> > Hoho, I miss the point. But I always set a clear goal in a iterate
process
> > (always short than a week) in my team .
>
> Are you the Onsite Customer?
>
> Are your iterations always the same length?
delering a optimized kvm in 3 months ,and pass sun's tck test in a seek.
Gerold Keefer
simple: they don't.
in a move that would have made george orwell
claiming license fees, a project failure as defined
in the SE and PM literature was excluded from
the XP namespace.
if you cannot avoid it, rename it!
best regards,
gerold
Ron Jeffries
How does any process fail? Even yours?
geoff
How do projects fail in general? The most common reason I have seen is
people can't decide what they want. There is a constant tug of war and
sometimes, managers lose their nerve and decide the whole thing was a bad
idea.
The first project I was on, the manager told the GM he would write software
for all the company's products. They would have a common software platform.
After a year and a half, he could not deliver on what he promised and he and
the GM were fired.
Another project, there were too many people who had to stick their finger in
the pie, tug of war, etc. and eventually some vp called the whole thing off
after 1 year.
Another project had bad requirements, incompetent requirements gatherers.
They wrote use cases and were not detailed enough to write anything. So,
the project tried to do a course correction, used many different methods,
but the customer got upset and pulled funding.
-g
"Isaac Gouy" <ig...@yahoo.com> wrote in message
news:ce7ef1c8.04010...@posting.google.com...