Failure modes

NAVIGATION

CATEGORIES

Development

REFERRENCE

If you have some good idea, Cilck and mail to us please...

LINKS

Home » Development

Failure modes
8 answers - 1692 bytes -
"Is there anything in XP that would prevent the Customer was driving
the team with stories that didn't lead to commercial success?"
Sure there is.
If you are working with customers
1. You can take real customers (ones that will pay for the product, onsite-users), not the proxies. Proxies can be misleading
2. You can take more than one customers so it becomes "Customers" not "The Customer". If one customer gives you irrelevant stories others surely warn you.
3. You can choose your customers (onsite-users) such that they can represent all your target user profiles. So your final product won't stuck into a specific customer base.
All these ideas are not mine. They are well-defined in Books or Communities of XP, which are the solutions for the problem that you describe.
If you cannot work with onsite-users, XP has other tricks which will decrease or eliminate the risk to lose money in the wrong project ( at least it will definitely decrease the amount of lost invention)
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2/min or less.
[Non-text portions of this message have been removed]
To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com
To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*To visit your group on the web, go to:
<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com
<*Your use of Yahoo! Groups is subject to:
No.1 | | 4492 bytes | |
13 Aug 2006, at 20:36, Seyit Caglar Abbasoglu wrote:

"Is there anything in XP that would prevent the Customer was driving
the team with stories that didn't lead to commercial success?"

Sure there is.

If you are working with customers
1. You can take real customers (ones that will pay for the product,
onsite-users), not the proxies. Proxies can be misleading
2. You can take more than one customers so it becomes "Customers"
not "The Customer". If one customer gives you irrelevant stories
others surely warn you.
3. You can choose your customers (onsite-users) such that they can
represent all your target user profiles. So your final product
won't stuck into a specific customer base.

Not sure I follow. From my experience of XP:

* if the developers are taking stories from more than one group
directly then you're not doing XP (Customer Speaks With Voice)

* if somebody, or some process, is managing the input from this group
of users - they're acting as a Customer proxy :-)

I know projects I've worked on have dozens of interested parties,
user groups, etc. I do not think having all those people in the team
room will produce a productive environment ;-) Customer Speaks With
Voice seems to me to be an essential aspect of XP.

Even an excellent Customer proxy, you don't always get stories that
will lead to business success. I think the market related example I
gave in reply to one of Phlip's mails is an example of this.

All these ideas are not mine. They are well-defined in Books or
Communities of XP, which are the solutions for the problem that you
describe.

If you cannot work with onsite-users, XP has other tricks which
will decrease or eliminate the risk to lose money in the wrong
project ( at least it will definitely decrease the amount of lost
invention)

Please don't get me wrong. I /love/ XP. It's a fantastic process. I
evangelise it to death.

What I'm niggling about is that Phlip seems to be wanting to define
XP as a process that cannot fail (that might not have been his intent
of course - but that's how it read to me :-) I don't see this as
being either true or productive.

Sometimes projects fail late, rather than failing fast as we prefer.

Sometimes this is because people aren't following the XP practices
and proceed to fall into one of the holes those practices would have
protected them from. This is not an XP project - no argument from me :-)

Sometimes projects fail through external forces not under their
control. From what I've read the original C2 project would fall into
this category. I've seen productive projects die because an order
from above comes that "we're now a 100% Java shop" - instantly
killing a money making Perl group. An so on.

Sometimes projects fail because the team missed something. The
Customer didn't know enough about the market to correctly prioritise
the stories, usability related issues were overlooked because the
team didn't have those skills on board, etc.

If an XP project fail through external forces, or through the team
missing something, is it really an instance of not-XP? Doesn't seem
that way to me.

An XP team with things to learn? Certainly.

Next time we might get higher levels of management involved so we can
get better input and quicker feedback on issues that were external to
the project that failed.

Next time we might try and be more aggressive with sales, so we can
get more feedback from a larger user group more quickly, so we can
better prioritise stories.

Next time we might hire a usability dude to coach the Customer and
Developers.

And so on.

Hopefully making some vague sort of sense :-)

Cheers,

Adrian

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:
No.2 | | 1082 bytes | |
Hello scabbasoglu,

Thanks for a nifty idea. Tuesday, August 15, 2006, at 1:07:29 PM,
you wrote:

I don't want to change a definition since I'm not that expert but
"Customer Speaks With Voice" seems somewhat wrong to me. I would
prefer "Customers Speak With Voice" but not sure of it:)))

I like that distinction. I don't believe I've heard it before, but
I'm inclined to adopt it. Thanks!

Ron Jeffries
www.XProgramming.com
Analysis kills spontaneity.
The grain once ground into flour germinates no more. -- Henri Amiel

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:
No.3 | | 771 bytes | |
Ron Jeffries wrote:
Thanks for a nifty idea. Tuesday, August 15, 2006, at 1:07:29 PM,
you wrote:

Geez, Ron, that's so insipid it's funny! :) Are they as 'random' as
your sigs?

Dave Rooney
Mayford Technologies
http://www.mayford.ca

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:
No.4 | | 1053 bytes | |
Hello Dave,

Thanks for nothing. Tuesday, August 15, 2006, at 2:05:10 PM, you
wrote:

Ron Jeffries wrote:
>Thanks for a nifty idea. Tuesday, August 15, 2006, at 1:07:29 PM,
>you wrote:

Geez, Ron, that's so insipid it's funny! :) Are they as 'random' as
your sigs?

Sometimes they're random. I actually wrote that one. I liked the
idea. See lead-in. :)

Ron Jeffries
www.XProgramming.com
I'm not bad, I'm just drawn that way. -- Jessica Rabbit

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:
No.5 | | 2072 bytes | |
Adrian Howard wrote:

What I'm niggling about is that Phlip seems to be wanting to define
XP as a process that cannot fail (that might not have been his intent
of course - but that's how it read to me :-) I don't see this as
being either true or productive.

Someone on the XP newsgroup (unaware of its low quality), asked if any
studies or surveys had reported if any XP projects had failed, and
what their failure profiles were.

I asked if a boss had asked for a "risk assessment" before trying XP.
Ron answered with "early failure is success".

The original poster never returned.

So what's the answer? We are all here familiar with projects that
failed long after violating an obvious XP practice. Is there really no
accounting of XP projects that ran a long time and then lost money?

Sometimes projects fail through external forces not under their
control. From what I've read the original C2 project would fall into
this category.

C2 didn't release early and often, hence it was not an XP project,
hence it failed long after violating the obvious practice.

Sometimes projects fail because the team missed something. The
Customer didn't know enough about the market to correctly prioritise
the stories, usability related issues were overlooked because the
team didn't have those skills on board, etc.

And the team, again, skipped the Early Delivery rule.

So the box to fit inside is

- ran a long time
- can't profit (maybe lifecritical software)
- no evil bosses
- all XP practices
- failed anyway

For example, SAIC's first XP project was life-critical, so they could
not deploy early and often. The bosses were not evil, invested in the
project, and made certain it would have customers when it popped. SAIC
released their code (and hardware) on-time and under-budget, after
like 8 internal iterations. So it seems the only weak spot is the
Early Delivery rule.
No.6 | | 1217 bytes | |
Ron Jeffries wrote:
Hello Dave,

Thanks for nothing. Tuesday, August 15, 2006, at 2:05:10 PM, you
wrote:

>Ron Jeffries wrote:
>
Thanks for a nifty idea. Tuesday, August 15, 2006, at 1:07:29 PM,
you wrote:

>Geez, Ron, that's so insipid it's funny! :) Are they as 'random' as
>your sigs?
>
>
Sometimes they're random. I actually wrote that one. I liked the
idea. See lead-in. :)

Ron Jeffries
www.XProgramming.com
I'm not bad, I'm just drawn that way. -- Jessica Rabbit

T! :)

Dave Rooney
Mayford Technologies
http://www.mayford.ca

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:
No.7 | | 1361 bytes | |
15 Aug 2006, at 20:10, Phlip wrote:
[snip]
>Sometimes projects fail because the team missed something. The
>Customer didn't know enough about the market to correctly prioritise
>the stories, usability related issues were overlooked because the
>team didn't have those skills on board, etc.
>
And the team, again, skipped the Early Delivery rule.
[snip]

How are you defining "early delivery"?

We released regularly to real customers. This is what I understand as
"Early Delivery".

The problem was that the market wasn't as large as we thought - so
after a few releases we hit a wall where nobody else wanted to buy
the product.

The investment in coding was on the basis of the initial market
estimates, which were wrong.

Cheers,

Adrian

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:
No.8 | | 1034 bytes | |
Adrian Howard wrote:

How are you defining "early delivery"?

We released regularly to real customers. This is what I understand as
"Early Delivery".

Right.

Parenthetically, I met someone in a Customer role yesterday, who was
really pumped about Continuous Deployment. He gets updates every few
days, not just every week.

While I question the long-term stability of this practice, and we know
that regular weeks help balance the process, his team is to be
commended for automating and defending the entire pipeline, from
features to

The problem was that the market wasn't as large as we thought - so
after a few releases we hit a wall where nobody else wanted to buy
the product.

The investment in coding was on the basis of the initial market
estimates, which were wrong.

Because XP always succeeds, you must have only written features for
this narrow market, right?

And got your users hooked on a subscription of regular updates, right?

Re: Failure modes

EMSDN.COM

It's a question for 'Failure modes' under 'Development'

Development

Failure modes