Home > Archive > Extreme Programming > August 2006 > XP negative case studies
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
XP negative case studies
|
|
|
| Does anyone know of a good source of data that is against extreme
programming? I don't need unsubstantiated arguments, but rather some real
data that is against XP.
--JS
| |
| Isaac Gouy 2006-08-10, 6:58 pm |
|
John wrote:
> Does anyone know of a good source of data that is against extreme
> programming? I don't need unsubstantiated arguments, but rather some real
> data that is against XP.
>
> --JS
Phlip usually suggests people also ask questions on the yahoo group
http://groups.yahoo.com/group/extremeprogramming/
On a practical note, what would you consider to be evidence against
extreme programming?
| |
| Ron Jeffries 2006-08-10, 9:58 pm |
| On Thu, 10 Aug 2006 22:18:22 GMT, "John" <js866xp@yahoo.com> wrote:
>Does anyone know of a good source of data that is against extreme
>programming? I don't need unsubstantiated arguments, but rather some real
>data that is against XP.
I'm kind of on top of that sort of thing and I'm aware of no such data. There
are plenty of people who don't like XP or who have theoretical arguments against
it, but no one has produced real data that I know of.
Of course, it's hard to come up with data against a process that ships running
tested features every w or two, requested by the customer, created by a team
that works together with the business people, expresses all the requirements in
terms of automated tests, keeping the design clean all the time. You can find
data about teams that /didn't/ do the process, but teams that do it have this
deplorable tendency to succeed.
It might be imagined that XP would be hard to do -- though my experience is that
it is not -- but I do find it hard to imagine that if a team did it, it wouldn't
work.
Failures of my imagination notwithstanding, I'm aware of no such data. If I
were, I'd go dig into it and figure out what had happened. It could only help.
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Isaac Gouy 2006-08-10, 9:58 pm |
|
Ron Jeffries wrote:
> On Thu, 10 Aug 2006 22:18:22 GMT, "John" <js866xp@yahoo.com> wrote:
>
>
> I'm kind of on top of that sort of thing and I'm aware of no such data. There
> are plenty of people who don't like XP or who have theoretical arguments against
> it, but no one has produced real data that I know of.
>
Has anyone produced real data for XP - rather than saying they like XP
or have theoretical arguments for it?
> Of course, it's hard to come up with data against a process that ships running
> tested features every w or two, requested by the customer, created by a team
> that works together with the business people, expresses all the requirements in
> terms of automated tests, keeping the design clean all the time. You can find
> data about teams that /didn't/ do the process, but teams that do it have this
> deplorable tendency to succeed.
>
> It might be imagined that XP would be hard to do -- though my experience is that
> it is not -- but I do find it hard to imagine that if a team did it, it wouldn't
> work.
>
> Failures of my imagination notwithstanding, I'm aware of no such data. If I
> were, I'd go dig into it and figure out what had happened. It could only help.
>
> Regards,
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Isaac Gouy 2006-08-11, 6:59 pm |
|
Isaac Gouy wrote:
> Ron Jeffries wrote:
>
> Has anyone produced real data for XP - rather than saying they like XP
> or have theoretical arguments for it?
Ron, are you saying that you are aware of no real data for or against
extreme programming?
| |
|
| John wrote:
> Does anyone know of a good source of data that is against extreme
> programming? I don't need unsubstantiated arguments, but rather some real
> data that is against XP.
To what use would you put the evidence?
One common FAQ here derives from a skeptical boss who has asked "what risks
will this XP nonsense incur?"
For a thought experiment, let's pretend we live in Dilbert's world. A boss
has asked Catbert to sabotage a team using XP, to ensure they fail. So our
Catbert will supply an analogy to Murphy's Law, in our world.
Catbert could...
- send the Onsite Customer to the hospital for
unnecessary surgery
- relocate half the team to another continent
- inspire DBAs to demand the team never change
their data schema
- switch the team to a language that inhibits TDD
- forbid team members to integrate more than once
a w
- forbid the team to sort features in order of business
priority
- require the team to design for a long time on paper
- forbid the team to productize a release once per w
(somehow)
- reward the team for their code's line count
- forbid the team to deliver to end-users.
Now we notice a curious effect. When the Onsite Customer goes missing, the
team must notice. Similarly when their pair-programmers disappear, or when
their access to their version controller disappears.
At that time, the team should detect they are no longer doing XP.
So they now have the choice to continue working with Brand X - whatever the
result of the sabotage is - or halt the project. If the project then wastes
money and fails, the team must blame Brand X, not XP.
So the question arises - is there some way Catbert can sabotage the project,
but the team would never notice? If the team still thinks they are doing XP,
and they burn up a lot of runway and then fail, then XP deserves the blame.
If the team notices, they will either adjust or halt the project. If they
halt the project early, then they didn't waste much money.
If Catbert lets the project run for a few ws before sabotaging it, then
XP's rules state the team must deliver something to end-users. So even if
Catbert then forces the project to halt, end-users will have a release in
their hands, with high-value features. (They might even rise up against
Catbert's sabotage!)
If a team did not waste much money, then it did not fail. The principle here
is "early failure is success". If you treat the project as a feasibility
study, then the study must either return evidence the project won't work (or
is being sabotaged), or the study must return working code that could pay
for the study. In these terms, XP is a "success detector", and it reliably
detects projects that will not succeed, very efficiently.
So the question remains: How can Catbert sabotage this project in a way that
makes it run for a long time, and only then fail to make a profit?
Note that one particular high-profile proto-XP failed because its
organization forbade the team to release code to users early and often. So
this exception proves the rule; the team kept running anyway, after the XP
Rules said the project was no longer XP.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
|
| Phlip wrote:
> If a team did not waste much money, then it did not fail. The principle
> here is "early failure is success". If you treat the project as a
> feasibility study, then the study must either return evidence the project
> won't work (or is being sabotaged), or the study must return working code
> that could pay for the study. In these terms, XP is a "success detector",
> and it reliably detects projects that will not succeed, very efficiently.
Another way for XP to fail is if it flunks a project that would have
succeeded using Brand X.
Now we need to find citations for these two situations:
- A team thought it was doing XP, and respected every
success indicator, but ran for a long time and failed
- A team that tried XP and it failed, then tried Brand X
and it succeeded
> --
> Phlip
> [url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| Isaac Gouy 2006-08-11, 6:59 pm |
|
Phlip wrote:
-snip-
> If the team notices, they will either adjust or halt the project. If they
> halt the project early, then they didn't waste much money.
-snip-
Do you have any examples of a team halting a project and giving up
their pay checks?
| |
| Ron Jeffries 2006-08-11, 9:58 pm |
| On 10 Aug 2006 20:49:00 -0700, "Isaac Gouy" <igouy@yahoo.com> wrote:
>
>Has anyone produced real data for XP - rather than saying they like XP
>or have theoretical arguments for it?
There are quite a few experience reports at the conference. Would those
constitute read data by your standards, Mr Prosecutor?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ron Jeffries 2006-08-11, 9:58 pm |
| On 11 Aug 2006 08:17:44 -0700, "Isaac Gouy" <igouy@yahoo.com> wrote:
>Ron, are you saying that you are aware of no real data for or against
>extreme programming?
No. What sentence of mine did you parse to obtain that meaning?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ron Jeffries 2006-08-11, 9:58 pm |
| On 11 Aug 2006 14:32:28 -0700, "Isaac Gouy" <igouy@yahoo.com> wrote:
>Phlip wrote:
>-snip-
>-snip-
>
>Do you have any examples of a team halting a project and giving up
>their pay checks?
Teams don't often halt projects, whether their paychecks are in jeopardy or not.
Their bosses halt projects more often. I think a careful reading of Phlip's
posting points out that Agile projects produce information that can readily be
used by management to determine whether they are producing enough, well enough.
The information Agile projects produce is a stream of features. Agile projects
are supposed to produce running tested features specified by their customer. If
they aren't doing that, they should be scrutinized, realigned, or the project
terminated.
I would have guessed that you already knew that, and wonder why, in that
interest you have in fair discourse, why you didn't reflect on it in your
inquiry.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
|
| Ron Jeffries wrote:
> Teams don't often halt projects, whether their paychecks are in jeopardy
> or not.
A team that keeps its projects' status a secret from its boss is not
practicing XP. The practices of Planning Game, Onsite Customer, Acceptance
Tests, and Frequent Releases require the team to provide evidence in
software of their status. (_Not_ in "Progress Reports"!;)
Keeping the status a secret from the boss would violate all five core Values
of Communication, Respect, Simplicity, Courage, and Feedback. A team that
lies about its status is not communicating, is not respecting their boss, is
not keeping their process simple, is not brave, and is not using a feedback
loop.
So an XP project that fails early must perforce inform the boss. Now the
team is indeed at risk. XP does not require the boss to be enlightened, to
reward the team for successfully detecting failure, or to find a new
project.
In real life, the boss would probably use the evidence collected to
re-schedule a much more modest project, within the team's grasp.
Yet the boss might indeed fire the team. In this case, the team should take
heart that many "Agile" and "XP" job openings are now available in the
markets, and that the rumor among the XP mailing lists and newsgroups is
that nobody who has learned it is hurting for work. Their employment rates
(and compensation) might indeed be higher than average. A team that
successfully detected failure, without wasting money, has every right to
list this success in their resumes!
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| Isaac Gouy 2006-08-12, 3:58 am |
|
Ron Jeffries wrote:
> On 11 Aug 2006 08:17:44 -0700, "Isaac Gouy" <igouy@yahoo.com> wrote:
>
>
> No. What sentence of mine did you parse to obtain that meaning?
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
What you don't say is sometimes more interesting than what you do say
:-)
| |
| Isaac Gouy 2006-08-12, 3:58 am |
|
Ron Jeffries wrote:
> On 10 Aug 2006 20:49:00 -0700, "Isaac Gouy" <igouy@yahoo.com> wrote:
>
>
> There are quite a few experience reports at the conference. Would those
> constitute read data by your standards, Mr Prosecutor?
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
Is that the same standard you applied when answering the OP's question?
(Mr Gouy is the correct form of address.)
| |
| Isaac Gouy 2006-08-12, 6:58 pm |
|
Ron Jeffries wrote:
> On 11 Aug 2006 14:32:28 -0700, "Isaac Gouy" <igouy@yahoo.com> wrote:
>
>
> Teams don't often halt projects, whether their paychecks are in jeopardy or not.
> Their bosses halt projects more often. I think a careful reading of Phlip's
> posting points out that Agile projects produce information that can readily be
> used by management to determine whether they are producing enough, well enough.
>
> The information Agile projects produce is a stream of features. Agile projects
> are supposed to produce running tested features specified by their customer. If
> they aren't doing that, they should be scrutinized, realigned, or the project
> terminated.
>
> I would have guessed that you already knew that, and wonder why, in that
> interest you have in fair discourse, why you didn't reflect on it in your
> inquiry.
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
Hold Phlip responsible for what he writes, not me - when he writes "If
the team notices, they will either adjust or halt the project" it's
clear from the preceding statements that he means - if the team
notices, the team will either adjust or the team will halt the project.
Is it realistic to think that the team will halt the project, or is it
a pious fantasy? With examples we might answer that question.
| |
| Isaac Gouy 2006-08-12, 6:58 pm |
|
Phlip wrote:
> Ron Jeffries wrote:
>
>
> A team that keeps its projects' status a secret from its boss is not
> practicing XP. The practices of Planning Game, Onsite Customer, Acceptance
> Tests, and Frequent Releases require the team to provide evidence in
> software of their status. (_Not_ in "Progress Reports"!;)
>
> Keeping the status a secret from the boss would violate all five core Values
> of Communication, Respect, Simplicity, Courage, and Feedback. A team that
> lies about its status is not communicating, is not respecting their boss, is
> not keeping their process simple, is not brave, and is not using a feedback
> loop.
As Mr Jeffries said of C3
"
>Presumably "his boss" was a stakeholder - and at that point there was
>a blatant lack of "Open Honest Communication"?
Exactly. XP, like any other process, cannot help a team that doesn't do
the process. As I mentioned elsewhere, probably I, or someone else,
should have valued communication highly enough to go around the
obstacle. At the time, we didn't have the courage to do so."
http://groups.google.com/group/comp...fe2f0eb7d5b8da4
>
> So an XP project that fails early must perforce inform the boss. Now the
> team is indeed at risk. XP does not require the boss to be enlightened, to
> reward the team for successfully detecting failure, or to find a new
> project.
>
> In real life, the boss would probably use the evidence collected to
> re-schedule a much more modest project, within the team's grasp.
>
> Yet the boss might indeed fire the team. In this case, the team should take
> heart that many "Agile" and "XP" job openings are now available in the
> markets, and that the rumor among the XP mailing lists and newsgroups is
> that nobody who has learned it is hurting for work. Their employment rates
> (and compensation) might indeed be higher than average. A team that
> successfully detected failure, without wasting money, has every right to
> list this success in their resumes!
>
> --
> Phlip
> [url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
|
| Isaac Gouy wrote:
> Hold Phlip responsible for what he writes, not me - when he writes "If
> the team notices, they will either adjust or halt the project" it's
> clear from the preceding statements that he means - if the team
> notices, the team will either adjust or the team will halt the project.
In the jargon, "Whole Team" includes the boss.
(And we have all seen team members simply job-hop out of a failing
project, whatever its methodology. That indeed halts their
participation, and maybe the boss will get the hint. Or maybe not!)
> Is it realistic to think that the team will halt the project, or is it
> a pious fantasy? With examples we might answer that question.
If I hold you responsible for what you write, could I ask for examples
of your own process in action?
--
Phlip
| |
|
| Isaac Gouy wrote:
> As Mr Jeffries said of C3
I mentioned C3 first, obliquely:
"Note that one particular high-profile proto-XP failed because its
organization forbade the team to release code to users early and often.
So this exception proves the rule; the team kept running anyway, after
the XP Rules said the project was no longer XP."
Hence, you get no bounce from it. Sorry.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| Ron Jeffries 2006-08-12, 9:58 pm |
| On 11 Aug 2006 21:05:46 -0700, "Isaac Gouy" <igouy@yahoo.com> wrote:
>What you don't say is sometimes more interesting than what you do say
>:-)
A lot of people think that.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ron Jeffries 2006-08-12, 9:58 pm |
| On 12 Aug 2006 14:47:53 -0700, "Phlip" <phlip2005@gmail.com> wrote:
>If I hold you responsible for what you write, could I ask for examples
>of your own process in action?
Phlip, we are forgetting Isaac's First Law: DFTFT. I apologize for getting
sucked in again.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Isaac Gouy 2006-08-13, 9:58 pm |
|
Phlip wrote:
> Isaac Gouy wrote:
>
>
> In the jargon, "Whole Team" includes the boss.
You sketched a caricature where "A boss has asked Catbert to sabotage a
team using XP, to ensure they fail". In your caricature it seems that
the boss is not included in the team.
>
> (And we have all seen team members simply job-hop out of a failing
> project, whatever its methodology. That indeed halts their
> participation, and maybe the boss will get the hint. Or maybe not!)
>
>
> If I hold you responsible for what you write, could I ask for examples
> of your own process in action?
>
> --
> Phlip
Phlip, perhaps you have merged your identity so closely with a
particular process that you think it makes sense to ask someone about
their own process. I'm not selling a software development process. I
use different processes on different projects. I'm not selling a
programming language. I use different programming languages on
different projects.
It makes no more sense to ask about my own process than it would to ask
about my own knife and fork.
| |
| Isaac Gouy 2006-08-13, 9:58 pm |
|
Phlip wrote:
> Isaac Gouy wrote:
>
>
> I mentioned C3 first, obliquely:
>
> "Note that one particular high-profile proto-XP failed because its
> organization forbade the team to release code to users early and often.
> So this exception proves the rule; the team kept running anyway, after
> the XP Rules said the project was no longer XP."
>
> Hence, you get no bounce from it. Sorry.
>
> --
> Phlip
> [url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
That doesn't seem to be connected to Mr Jeffries' clear statement that
he knew the truth about the schedule was not being communicated to the
development manager's boss.
If the XP rules are aspirational then it's enough that a team tries to
follow the rules. If the XP rules are prescriptive and define XP then
it's necessary to show that there's a realistic expectation that the
rules will be followed. Prescriptive rules which a team ignores are no
more than pious fantasy.
|
|
|
|
|