Well then, how about "unintential SD" ? ;-)

Charlie

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Dean Wampler
> Sent: Tuesday, July 17, 2007 3:25 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] Intentional Software Development
>
> Good name, but there is a prior claim to it.
>
> http://intentsoft.com/
>
> Dean
>
> On 7/17/07, J. B. Rainsberger <jbrains762@...> wrote:
> >
> >   [I can't remember the last time I started a thread. Here goes.]
> >
> > In another thread, I wrote that we could rename "agile software
> > development" to "Intentional Software Development" and retain the
> > essence and value of agile. The goal is to sidestep the
> "define agile"
> > problem and instead use a more intention-revealing name whose
> > definition is more apparent in general.
> >
> > So let me propose an idea. I'm sure it's not new.
> >
> > INTENTIONAL SOFTWARE DEVELOPMENT
> > --------------------------------
> > We have discovered that working intentionally is the cornerstone of
> > effective software development, through building software, running
> > software companies and teaching others to do both. In an attempt to
> > clarify our approach and give context to what we recommend
> others do,
> > we use the term "intentional" do describe our philosophy.
> That is, we
> > develop software most effectively when we do so intentionally. This
> > means that we stop doing any activity whose intention is not both
> > clearly understood and demonstrably relevant to our business goals.
> > What is left is what we need to do in order to be effective.
> >
> > Intentional Software Development (ISD) focuses primarily on
> > identifying waste and eliminating it, making it a Lean approach to
> > software. It proposes asking the question "What's the good business
> > reason to do this?" as the primary tool for identifying
> waste. When we
> > ask this question of an activity, there are three possible answers:
> >
> > 1. There is no good business reason to do this.
> > 2. X is the good business reason to do this.
> > 3. We aren't sure whether there is a good business reason
> to do this.
> > (Alternately: we think there's a good business reason to do
> this, but
> > can't put our finger on it.)
> >
> > When we answer #1, we stop doing the activity until and unless we
> > discover a good business reason to do it.
> >
> > When we answer #2, we continue doing the activity, but ask the
> > follow-up question, "Is there a cheaper way to do this and still
> > satisfy the corresponding business needs?"
> >
> > When we answer #3, we formulate a plan to gather
> information to help
> > us answer the question. The good business reason to do this
> is clear:
> > if the activity really is waste, and if the (potential)
> waste is big
> > enough that its cost dominates the cost of discovering
> whether it is
> > waste, then it is worthwhile to invest time and money in
> making that
> > determination. This implies that we must be able to measure the
> > potential waste from the activity in question. If we
> cannot, then we
> > formulate a plan for learning how to measure it... (and so on).
> >
> > I posit that asking these questions repeatedly will help us
> converge
> > towards a more intentional, less wasteful, and therefore more
> > effective way to work.
> >
> > [So is all this just a restatement of old ideas? I suspect
> it is, but
> > perhaps this restatement has value. The good business
> reason to do it
> > is that I get to add my own flavor-of-the-month-looking approach to
> > agile, which might raise my profile as a consultant. See? I'm
> > intentional in my approach to describing ISD!]
> >
> > So is there anything valuable about agile or XP that we
> wouldn't do in
> > ISD?
> > --
> > J. B. (Joe) Rainsberger :: http://www.jbrains.ca Your guide to
> > software craftsmanship JUnit Recipes: Practical Methods for
> Programmer
> > Testing
> > 2005 Gordon Pask Award for contribution Agile Software Practice
> >
> >
>
>
>
> --
> Dean Wampler
> http://www.objectmentor.com
> http://www.aspectprogramming.com
> http://www.contract4j.org
>
>
> [Non-text portions of this message have been removed]
>
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>

If XHelper is really a helper, I think this is OK. I use the
term "helper" to mean objects that are constructed to do a
particular job and then discarded. Obviously, they should
be tested but I don't feel they need to be mocked when
testing the objects that use them.

At least that's how I feel today :-)

Charlie

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
> Muhammad Ichsan
> Sent: Tuesday, July 17, 2007 4:07 AM
> To: extremeprogramming@yahoogroups.com
> Subject: [XP] Is this testing a collaborator?
>
> Dear All,
>
> I have a PHP function that call methods of constructed inside
> the function.
>
> function submitForm(){
>     $helper = new XHelper( $reponse );
>     $helper->putMsg( "test" );
>
>     .....
> }
>
> Is it helper a collaborator? I think it is, but how to
> observe its usage? Since the implementation is inside
> therefore we can't observe if the class used properly. We
> can't use mock. What do you think?
>
> --
> ~Useful man to others is a lucky man
> http://michsan.wordpress.com
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>

Wait for the cease-and-desist from C.Simonyi
That name has more-or-less been taken by an uber microserf.
You need a new name.

I'll read the rest later.

----- Original Message ----
From: J. B. Rainsberger <jbrains762@...>
To: extreme programming <extremeprogramming@yahoogroups.com>
Sent: Tuesday, July 17, 2007 4:18:29 PM
Subject: [XP] Intentional Software Development

[I can't remember the last time I started a thread. Here goes.]

In another thread, I wrote that we could rename "agile software
development" to "Intentional Software Development" and retain the
essence and value of agile. The goal is to sidestep the "define agile"
problem and instead use a more intention-revealing name whose definition
is more apparent in general.

So let me propose an idea. I'm sure it's not new.

INTENTIONAL SOFTWARE DEVELOPMENT
--------------------------------
We have discovered that working intentionally is the cornerstone of
effective software development, through building software, running
software companies and teaching others to do both. In an attempt to
clarify our approach and give context to what we recommend others do, we
use the term "intentional" do describe our philosophy. That is, we
develop software most effectively when we do so intentionally. This
means that we stop doing any activity whose intention is not both
clearly understood and demonstrably relevant to our business goals. What
is left is what we need to do in order to be effective.

Intentional Software Development (ISD) focuses primarily on identifying
waste and eliminating it, making it a Lean approach to software. It
proposes asking the question "What's the good business reason to do
this?" as the primary tool for identifying waste. When we ask this
question of an activity, there are three possible answers:

1. There is no good business reason to do this.
2. X is the good business reason to do this.
3. We aren't sure whether there is a good business reason to do this.
(Alternately: we think there's a good business reason to do this, but
can't put our finger on it.)

When we answer #1, we stop doing the activity until and unless we
discover a good business reason to do it.

When we answer #2, we continue doing the activity, but ask the follow-up
question, "Is there a cheaper way to do this and still satisfy the
corresponding business needs?"

When we answer #3, we formulate a plan to gather information to help us
answer the question. The good business reason to do this is clear: if
the activity really is waste, and if the (potential) waste is big enough
that its cost dominates the cost of discovering whether it is waste,
then it is worthwhile to invest time and money in making that
determination. This implies that we must be able to measure the
potential waste from the activity in question. If we cannot, then we
formulate a plan for learning how to measure it... (and so on).

I posit that asking these questions repeatedly will help us converge
towards a more intentional, less wasteful, and therefore more effective
way to work.

[So is all this just a restatement of old ideas? I suspect it is, but
perhaps this restatement has value. The good business reason to do it is
that I get to add my own flavor-of-the-month-looking approach to agile,
which might raise my profile as a consultant. See? I'm intentional in my
approach to describing ISD!]

So is there anything valuable about agile or XP that we wouldn't do in ISD?
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice


To Post a message, send it to:   extremeprogramming@eGroups.com

To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com

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











________________________________________________________________________________\
____
Choose the right car based on your needs.  Check out Yahoo! Autos new Car Finder
tool.
http://autos.yahoo.com/carfinder/

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

On 7/17/07, Chris Wheeler <christopher.wheeler@...> wrote:
>
> On 7/17/07, Steven Gordon <sgordonphd@...> wrote:
>  >
>  > Perhaps, the best we can do is to say org A is more agile than org B if:
>  > - they are competitors in the same market/domain,
>  > - orgA can consistently adapt to change more rapidly/appropriately than
>  > orgB.
>  >
>  > If we resort to this definition, we are saying -
>  > 1. the point in being agile is to be able to outflank/outperform your
>  > competitors,
>  > 2. there is no strong business case for being agile if you have no
>  > competitors (although not being agile will encourage the emergence of
>  > competitors),
>  > 3. there is really no such thing as being agile or not agile - all you
>  > can be is more agile or less agile.
>
>  Also:
>
>  4. Agile has nothing to do with your practices only your position in the
>  market. (by this definition)

Not necessarily.  Your past practices could easily be the reason for
the agility or lack thereof in the market place. Your future practices
could change your market position by making you more or less agile
than your competitors.  Some organizations leverage their agility by
adding features that they know their competitors would have trouble
adding to their products.

On the other hand, I do know of markets where a large unagile
enterprise preserves their dominant market position by buying out
agile competitors before they get threatening.

>
>  Chris.
>

Phlip wrote:
> This is why XP practices have other balancing practices, such as Energetic
> Work.
>
> Would you pair with Stallman again? How about on something minor??

...

> It didn't occur to them to stop. I think they would have done better with
> breaks.

Don't get me, um, wrong - I agree with everything, and I understand the
point. But, did they really do anything /wrong/, or just do something
that probably could have been done a better way?

I don't want to be pedantic about terminology, but one of the things I
think we should be cautious about is labeling specific practices as
"wrong". Chiefly because people who read this list take people who
contribute a lot as knowing a thing or two and are likely to apply that
label without necessarily having proper context.

So what could the two have done better? A lot from an Agile perspective.
But did they do anything *wrong*?

--
Cory Foy
http://www.cornetdesign.com

Hello, J..  On Tuesday, July 17, 2007, at 7:58:48 PM, you wrote:

> Tim Ottinger wrote:

>> Refactored to remove redundancy:
>> "Is it unethical to be unethical?"

> Let me refactor another way: reveal intent better.

  >>  > Let me try. To block is to lie. Lying is unethical.
  >>
  >> Hm. Is it unethical to be unethical so that the rest of the team can act
  >> reasonably?

> "Is it unethical to lie to someone uninterested in the truth so that the
> rest of the team can act reasonably?"

Well, to begin, it comes out that blocking means to some of us,
producing a document or report that we don't really need ourselves.
There's nothing whatsoever wrong with that, in my opinion, if
someone in power has asked for it. I'd track and report the cost,
however.

Then to others, blocking means to pretend to be doing one process
while in fact done some other one. That troubles me more.

Now I am certainly not entirely ethical, though I do try to be, just
because I feel better about it. That said, I think that the truth is
more likely to get me what I really want than lies, and I see that
as as much of a pragmatic position as an ethical one.

Ron Jeffries
www.XProgramming.com
Fear is the mindkiller. --Bene Gesserit Litany Against Fear

Cory Foy wrote:

>> Now what did they do wrong, folks?
>
> I can't say they did anything wrong. The goal of pair programming, as I
> understand it, is to reduce the bus number of the team by sharing ideas.
> For a one-off session such as this, can we say that the ideas would have
> be shared any more effectively if they would have switched who was
> driving?

This is why XP practices have other balancing practices, such as Energetic
Work.

Would you pair with Stallman again? How about on something minor??

> In addition, while some may say it isn't sustainable, and be correct, it
> doesn't mean that what they did was /wrong/ per se - not wanting to stop
> when the ideas are flowing once in a while seems perfectly OK.

It didn't occur to them to stop. I think they would have done better with
breaks.

> Perhaps I'm just responding strongly towards the word "wrong". The only
> thing they may have done "wrong" was work on something that there wasn't
> a business need for - and if RMS was the customer, then even that was
> probably OK.

The article covered that early on - wasn't it Emac's syntax highlighter?

--
   Phlip
   http://www.oreilly.com/catalog/9780596510657/
   "Test Driven Ajax (on Rails)"
   assert_xpath, assert_javascript, & assert_ajax

On 7/17/07, Chris Wheeler <christopher.wheeler@...> wrote:
>
>
>
>
>
>
> On 7/17/07, Steven Gordon <sgordonphd@...> wrote:
>  >
>  > Perhaps, the best we can do is to say org A is more agile than org B if:
>  > - they are competitors in the same market/domain,
>  > - orgA can consistently adapt to change more rapidly/appropriately than
>  > orgB.
>  >
>  > If we resort to this definition, we are saying -
>  > 1. the point in being agile is to be able to outflank/outperform your
>  > competitors,
>  > 2. there is no strong business case for being agile if you have no
>  > competitors (although not being agile will encourage the emergence of
>  > competitors),
>  > 3. there is really no such thing as being agile or not agile - all you
>  > can be is more agile or less agile.
>
>  Also:
>
>  4. Agile has nothing to do with your practices only your position in the
>  market. (by this definition)
>
>  Chris.
>

Phlip wrote:
> Michael Feathers wrote:
>
>> ... Looking back, Steele says he found
>> the Stallman mind-meld both exhilarating and scary at the same time. "My
>> first thought afterward was: it was a great experience, very intense,
>> and that I never wanted to do it again in my life."
>
> Now what did they do wrong, folks?

I can't say they did anything wrong. The goal of pair programming, as I
understand it, is to reduce the bus number of the team by sharing ideas.
For a one-off session such as this, can we say that the ideas would have
be shared any more effectively if they would have switched who was driving?

In addition, while some may say it isn't sustainable, and be correct, it
doesn't mean that what they did was /wrong/ per se - not wanting to stop
when the ideas are flowing once in a while seems perfectly OK.

Perhaps I'm just responding strongly towards the word "wrong". The only
thing they may have done "wrong" was work on something that there wasn't
a business need for - and if RMS was the customer, then even that was
probably OK.


--
Cory Foy
http://www.cornetdesign.com

Allow me to gush and +1 on this part:

> 3. there is really no such thing as being agile or not agile - all you
>     can be is more agile or less agile.

I think that one can do XP or SCRUM entirely, but how to qualify for the "agile"
in an ongoing way? Agile has been XP.  What will it be next? How will our
definitions not exclude further development in possibly new directions?  What if
one of my coworkers suddenly figures out the practical secret ingredient to
solving the problem of multi-site, multi-company, distributed, life-critical
software development -- will the departure from SCRUM and XP mean it's not
agile?

Now, of course, the answer is whether such a definition is the easiest thing
that might possibly work, and of course maybe YAGNI.  Hm. Maybe the definition
always has to be open to retrospective and review.

I do go into churches. Mine has a constitution of sorts, a manual. It is
separate from the writings we hold to be Holy.  It is constantly under review
and revision.  Positions on social issues and our responses to them have been
softened or strengthened in order to comply with a more important set of
conditions laid down quite a long time ago, which are in principle unchanging. 
This is the kind of thing I would like to see for Agile.  There should be some
more-or-less timeless set of principles, and ongoing adaptations of them should
be applied to contemporary issues. These should be reviewed and changed, while
being maintained alignment with the original to the extent we can make it so.

I don't always agree with my manual, even when I am in agreement with the
principles behind it. But I know there is a process to change this, and I don't
mind expending a little patience. I also am generally pleased with how well our
delegates handle the retrospective and refactoring, so I don't mind waiting for
the yearly convention to make decisions.

Maybe that's not a bad model for Agile Alliance. I've certainly seen worse.


----- Original Message ----
From: Steven Gordon <sgordonphd@...>
To: extremeprogramming@yahoogroups.com
Sent: Tuesday, July 17, 2007 7:27:20 PM
Subject: Re: [XP] Defining Agile -- my definition

On 7/17/07, Ron Jeffries <ronjeffries@...> wrote:
>
> Hello, Andrew.  On Tuesday, July 17, 2007, at 4:05:15 PM, you
>  wrote:
>
>  > Not to jump in midway on a heated discussion (oops, looks like I
>  > did :-), but I thought agile was concerned with dealing with change
>  > appropriately, instead of following a by-now-out-of-date plan.  That
>  > doesn't require functional testing, or TDD, or anything else -- those
>  > are implementation details.  Damned handy ones, if you ask me, but
>  > not required by any realistic, broadly based definition.
>
>  > FWIW, in Practices of an Agile Developer that I wrote with Venkat, I
>  > posited this definition of agile:
>
>  > "Agile development uses feedback to make constant adjustments in a
>  > highly collaborative environment."
>
>  Good points, Andy, but it seems that many projects would make this
>  claim. "Hey, look, we have a Change Control Board so that we can
>  work together and adjust the project appropriately."
>
>  It seems the concern in this thread is to come up with an IS / IS
>  NOT test for Agile. I'm not deeply optimistic about this, but I am
>  hopeful.
>
>  How do you know whether you'd say a project is definitely "not
>  Agile"? Can you write down a test?
>

Perhaps, the best we can do is to say org A is more agile than org B if:
- they are competitors in the same market/domain,
- orgA can consistently adapt to change more rapidly/appropriately than orgB.

If we resort to this definition, we are saying -
1. the point in being agile is to be able to outflank/outperform your
competitors,
2. there is no strong business case for being agile if you have no
competitors (although not being agile will encourage the emergence of
competitors),
3. there is really no such thing as being agile or not agile - all you
can be is more agile or less agile.

What I do not like about this approach is that it implies there is no
reason to be agile projects internal to an enterprise, unless you
consider internal projects as part of what makes an enterprise more
agile than its competitors.

Steve

>  Ron Jeffries
>  www.XProgramming.com
>  Don't confuse more exact with better.  -- Brian Marick
>


To Post a message, send it to:   extremeprogramming@eGroups.com

To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com

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











________________________________________________________________________________\
____
Get the Yahoo! toolbar and be alerted to new email wherever you're surfing.
http://new.toolbar.yahoo.com/toolbar/features/mail/index.php

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

J. B. Rainsberger wrote:
> 1. There is no good business reason to do this.
> 2. X is the good business reason to do this.
> 3. We aren't sure whether there is a good business reason to do this.
> (Alternately: we think there's a good business reason to do this, but
> can't put our finger on it.)

It seems like this would just be a good pattern for either Planning
games or when a team goes to pull a card (or sign up for stories in a
Sprint Planning session). But it really doesn't seem to give any
guidance beyond that, so I'm wondering if it would be able to stand on
its own (and I may have missed something).

--
Cory Foy
http://www.cornetdesign.com

On 7/17/07, Steven Gordon <sgordonphd@...> wrote:
>
> Perhaps, the best we can do is to say org A is more agile than org B if:
> - they are competitors in the same market/domain,
> - orgA can consistently adapt to change more rapidly/appropriately than
> orgB.
>
> If we resort to this definition, we are saying -
> 1. the point in being agile is to be able to outflank/outperform your
> competitors,
> 2. there is no strong business case for being agile if you have no
> competitors (although not being agile will encourage the emergence of
> competitors),
> 3. there is really no such thing as being agile or not agile - all you
> can be is more agile or less agile.



Also:

4. Agile has nothing to do with your practices only your position in the
market. (by this definition)

Chris.


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

Tim Ottinger wrote:

> Refactored to remove redundancy:
> "Is it unethical to be unethical?"

Let me refactor another way: reveal intent better.

  >  > Let me try. To block is to lie. Lying is unethical.
  >
  > Hm. Is it unethical to be unethical so that the rest of the team can act
  > reasonably?

"Is it unethical to lie to someone uninterested in the truth so that the
rest of the team can act reasonably?"
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

Ron Jeffries wrote:

> Hello, Robert. On Friday, July 13, 2007, at 8:04:13 AM, you wrote:
>
>  > Gary Brown wrote:
>  >> If you could provide ten ideas/goals/requirements/use cases/stories,
>  >> then let the folks here describe how they could be done as vertical
>  >> slices. You will get feedback from each slice, and you can refine and
>  >> enhance the stories at any time.
>
>  > Thanks, but I suspect that would involve a lot of work, and still just
>  > be argument. Anyway, I don't doubt that it can be done in an artificial
>  > setting. I would like to see details of a real project. And, let me be
>  > clear: I am not arguing that is impossible. But I do want to see it. And
>  > despite studying projects looking exactly for this kind of thing, I have
>  > not seen it so far.
>
> Interesting. Real people here, who know how to do it and will demo,
> and you don't want to see what they do.

I think Ron and Gary, whom I respect deeply, both missed it when Robert
said that he doesn't want to see it demoed now, but rather he wants to
know what has happened on "real" (I guess that means for-the-money)
projects. I might be wrong, but I thought I'd point it out as a possible
reason for the misunderstanding.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

Refactored to remove redundancy:
   "Is it unethical to be unethical?"

----- Original Message ----
From: J. B. Rainsberger <jbrains762@...>
To: extremeprogramming@yahoogroups.com
Sent: Tuesday, July 17, 2007 3:41:08 PM
Subject: Re: [XP] Re: The success/failure distinctions

Ron Jeffries wrote:

> Hello, Scott. On Thursday, July 12, 2007, at 5:22:25 AM, you
> wrote:
>
>  > About a year and a half ago I got caught up in a flame war with
>  > someone who claimed that this was an unethical thing to do. He
>  > couldn't justify this of course, and naturally didn't want to budge
>  > from his opinion.
>
> Let me try. To block is to lie. Lying is unethical.

Hm. Is it unethical to be unethical so that the rest of the team can act
reasonably?
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice


To Post a message, send it to:   extremeprogramming@eGroups.com

To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com

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











________________________________________________________________________________\
____
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play
Sims Stories at Yahoo! Games.
http://sims.yahoo.com/

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

Andrew Hunt wrote:

> On Jul 17, 2007, at 6:22 PM, J. B. Rainsberger wrote:

>  > I'd forgot about the "responding to change" part of the manifesto, but
>  > then, I think predictable delivery handles that: in order to deliver a
>  > changing product predictably, we need to be able to respond to change
>  > effectively.
>
> That's a pretty important point to be left to inference, doncha think?

Theories are theories and axioms are axioms. It all depends on the
audience. In general, I prefer definitions to be minimal, so in this
case, declare as little as possible and leave the rest to inference.

In another context, I'd definitely want to make that more obvious.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

That's okay, I have mine:
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

----- Original Message ----
From: J. B. Rainsberger <jbrains762@...>
To: extremeprogramming@yahoogroups.com
Sent: Tuesday, July 17, 2007 3:37:00 PM
Subject: Re: [XP] Re: The success/failure distinctions

igouy2 wrote:

>  > It matches the analysis of studies of Waterfall projects that the
>  > closer you follow the process, the more likely you are to fail.
>
> Appeal to the authority of /anonymous/ studies will fool some of the
> people some of the time, it's a nice variation on "scientists say".

How's this? My office is in shambles because we've just moved, so I
can't find my copy of Royce's paper, so my memory will have to do.

Royce himself wrote in 1970 that the Waterfall (as many people came to
interpret it) works for /only the most straightforward projects/. From
there, it's not much of a leap to say "the more you try to do waterfall
on a complex project, the more likely you'll fail". In fact, it's a
pretty simple logical conclusion.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice


To Post a message, send it to:   extremeprogramming@eGroups.com

To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com

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











________________________________________________________________________________\
____
Be a better Heartthrob. Get better relationship answers from someone who knows.
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545433

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

Robert Biddle wrote:

> Gary Brown wrote:
>
>  > Perhaps, having not tried the Agile way, a person can't imagine how it
>  > might work. I understand that. Having tried the Agile way, I can't
>  > imagine why it wouldn't work. I think that we only differ in
>  > experiences.
>
> I do think that the UI community has some issues that bias them against
> agile software development. On the other hand, many of their own methods
> themselves seem similar to agile: iterations, formative evaluation,
> close contact with users, etc.
>
> And I do regard the approach you described as fascinating and valuable.
> But I would like to know more details of how it actually works, with
> specific real-world examples, either by reading about it or by studying
> it being used. If anyone can help me with these, I would welcome that.

I wrote about one that was real, although it was a one-person project
(me) and a small one (the registration features at xpday.info).

http://www.jbrains.ca/permalink/5

I hope it gives you a taste.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

On 7/17/07, Ron Jeffries <ronjeffries@...> wrote:
>
> Hello, Andrew.  On Tuesday, July 17, 2007, at 4:05:15 PM, you
>  wrote:
>
>  > Not to jump in midway on a heated discussion (oops, looks like I
>  > did :-), but I thought agile was concerned with dealing with change
>  > appropriately, instead of following a by-now-out-of-date plan.  That
>  > doesn't require functional testing, or TDD, or anything else -- those
>  > are implementation details.  Damned handy ones, if you ask me, but
>  > not required by any realistic, broadly based definition.
>
>  > FWIW, in Practices of an Agile Developer that I wrote with Venkat, I
>  > posited this definition of agile:
>
>  > "Agile development uses feedback to make constant adjustments in a
>  > highly collaborative environment."
>
>  Good points, Andy, but it seems that many projects would make this
>  claim. "Hey, look, we have a Change Control Board so that we can
>  work together and adjust the project appropriately."
>
>  It seems the concern in this thread is to come up with an IS / IS
>  NOT test for Agile. I'm not deeply optimistic about this, but I am
>  hopeful.
>
>  How do you know whether you'd say a project is definitely "not
>  Agile"? Can you write down a test?
>

Perhaps, the best we can do is to say org A is more agile than org B if:
- they are competitors in the same market/domain,
- orgA can consistently adapt to change more rapidly/appropriately than orgB.

If we resort to this definition, we are saying -
1. the point in being agile is to be able to outflank/outperform your
competitors,
2. there is no strong business case for being agile if you have no
competitors (although not being agile will encourage the emergence of
competitors),
3. there is really no such thing as being agile or not agile - all you
can be is more agile or less agile.

What I do not like about this approach is that it implies there is no
reason to be agile projects internal to an enterprise, unless you
consider internal projects as part of what makes an enterprise more
agile than its competitors.

Steve

>  Ron Jeffries
>  www.XProgramming.com
>  Don't confuse more exact with better.  -- Brian Marick
>

On Jul 17, 2007, at 6:22 PM, J. B. Rainsberger wrote:

>
> I'd forgot about the "responding to change" part of the manifesto, but
> then, I think predictable delivery handles that: in order to deliver a
> changing product predictably, we need to be able to respond to change
> effectively.

That's a pretty important point to be left to inference, doncha think?

/\ndy

Dan Turk
Colorado State University
26 Rockwell Hall
Fort Collins, CO 80523-1277
USA

July 17, 2007




My name is Dan Turk, and I am a faculty member in the Department of
Computer Information Systems at Colorado State University.  My
colleague, Leo Vijayasarathy, and I are conducting a study to better
understand the use of agile software development processes, methods,
and techniques, and the benefits and limitations associated with
their use.  About 2 years ago we performed a similar survey.
However, while that survey was targeted solely at people who had
already been frequent users of agile processes, the current survey
looks to draw data from a larger segment of developers and has been
updated for that purpose.

Please consider participating in this study by completing a brief
survey posted at
http://www.business.colostate.edu/leov/research/agile/start.cfm .

A summary of the results will be posted to this group at the
conclusion of this study.

Your responses will be entirely anonymous and confidential.  The
survey does not collect any identifying information and cannot be
tracked to the person completing it.   General information about your
title and years of experience are requested only to build a profile
of the survey respondents.

Your participation in this study is voluntary.  There are no known
risks associated with taking part in it.  You may stop participating
at any time without penalty or loss of benefits to which you are
otherwise entitled.  If you have questions regarding your rights as a
volunteer in this research, please contact Janell Meldrem, Senior
Human Research Administrator, (970) 491-1563,
Janell.Meldrem@....

Thank you in advance for completing the survey and your contribution
to this research.   If you have any questions about the study or the
survey, please call me at 970-491-0467 or email me at
Dan.Turk@....

Sincerely,

Dan Turk, Ph.D.
Associate Professor of Computer Information Systems

On Jul 17, 2007, at 6:24 PM, Ron Jeffries wrote:

>
> Good points, Andy, but it seems that many projects would make this
> claim. "Hey, look, we have a Change Control Board so that we can
> work together and adjust the project appropriately."

Perhaps "timely" feedback would be more appropriate...

> It seems the concern in this thread is to come up with an IS / IS
> NOT test for Agile. I'm not deeply optimistic about this, but I am
> hopeful.

Otherwise it ends up much like the classic judge's definition of
pornography: I can't define it, but I know it when I see it.

Seriously, it seems to me that rapid and effective adjustment to
change is the single most definitive hallmark of agile development.
But no matter *what* definition you come up with, they'll be folks
who say "we're agile, and we've been agile all along" when of course
they are not by any sane measure from the community.

Instead of a test for agile, how about a test for "was your project a
success or was it horked?" If it was a success, call it anything you
want.  If not, don't dare call it agile :-)

/\ndy

On 7/17/07, J. B. Rainsberger <jbrains762@...> wrote:
>
> [I can't remember the last time I started a thread. Here goes.]
>
> Intentional Software Development (ISD) focuses primarily on identifying
> waste and eliminating it, making it a Lean approach to software. It
> proposes asking the question "What's the good business reason to do
> this?" as the primary tool for identifying waste. When we ask this
> question of an activity, there are three possible answers:
>
> 1. There is no good business reason to do this.
> 2. X is the good business reason to do this.
> 3. We aren't sure whether there is a good business reason to do this.
> (Alternately: we think there's a good business reason to do this, but
> can't put our finger on it.)
>
>
> So is there anything valuable about agile or XP that we wouldn't do in
> ISD?
>

I guess it depends on how narrow or how broad ISD defines 'good business
reason'. For instance, I could make a case that pair programming, which XP
places a high value on, does nothing that good documentation can't do or
that sitting together can't do, and I could (arguably) show that producing
both of those environments can be done at lower cost than pair programming.
That in mind, I could thus say that there is no 'good business reason' to do
pair programming.


[To be clear, I'm not saying that pairing is worse/better. I'm using it as
an example to illustrate that 'good business reason' is a fairly nebulous
term and can be manipulated to get what one wants. I issue this disclaimer
because, in the past, using pairing as an example tends to illicit a debate
about pairing, and not the issue that is being discussed. If this bothers
you, substitute 'pairing' with 'monkey shaving', 'documentation' with
'monkey piercing' and 'sitting together' with 'monkey licking', and you
should be fine.]

Chris.


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

Hello, Andrew.  On Tuesday, July 17, 2007, at 4:05:15 PM, you
wrote:

> Not to jump in midway on a heated discussion (oops, looks like I
> did :-), but I thought agile was concerned with dealing with change
> appropriately, instead of following a by-now-out-of-date plan.  That
> doesn't require functional testing, or TDD, or anything else -- those
> are implementation details.  Damned handy ones, if you ask me, but
> not required by any realistic, broadly based definition.

> FWIW, in Practices of an Agile Developer that I wrote with Venkat, I
> posited this definition of agile:

> "Agile development uses feedback to make constant adjustments in a
> highly collaborative environment."

Good points, Andy, but it seems that many projects would make this
claim. "Hey, look, we have a Change Control Board so that we can
work together and adjust the project appropriately."

It seems the concern in this thread is to come up with an IS / IS
NOT test for Agile. I'm not deeply optimistic about this, but I am
hopeful.

How do you know whether you'd say a project is definitely "not
Agile"? Can you write down a test?

Ron Jeffries
www.XProgramming.com
Don't confuse more exact with better.  -- Brian Marick

Good name, but there is a prior claim to it.

http://intentsoft.com/

Dean

On 7/17/07, J. B. Rainsberger <jbrains762@...> wrote:
>
>   [I can't remember the last time I started a thread. Here goes.]
>
> In another thread, I wrote that we could rename "agile software
> development" to "Intentional Software Development" and retain the
> essence and value of agile. The goal is to sidestep the "define agile"
> problem and instead use a more intention-revealing name whose definition
> is more apparent in general.
>
> So let me propose an idea. I'm sure it's not new.
>
> INTENTIONAL SOFTWARE DEVELOPMENT
> --------------------------------
> We have discovered that working intentionally is the cornerstone of
> effective software development, through building software, running
> software companies and teaching others to do both. In an attempt to
> clarify our approach and give context to what we recommend others do, we
> use the term "intentional" do describe our philosophy. That is, we
> develop software most effectively when we do so intentionally. This
> means that we stop doing any activity whose intention is not both
> clearly understood and demonstrably relevant to our business goals. What
> is left is what we need to do in order to be effective.
>
> Intentional Software Development (ISD) focuses primarily on identifying
> waste and eliminating it, making it a Lean approach to software. It
> proposes asking the question "What's the good business reason to do
> this?" as the primary tool for identifying waste. When we ask this
> question of an activity, there are three possible answers:
>
> 1. There is no good business reason to do this.
> 2. X is the good business reason to do this.
> 3. We aren't sure whether there is a good business reason to do this.
> (Alternately: we think there's a good business reason to do this, but
> can't put our finger on it.)
>
> When we answer #1, we stop doing the activity until and unless we
> discover a good business reason to do it.
>
> When we answer #2, we continue doing the activity, but ask the follow-up
> question, "Is there a cheaper way to do this and still satisfy the
> corresponding business needs?"
>
> When we answer #3, we formulate a plan to gather information to help us
> answer the question. The good business reason to do this is clear: if
> the activity really is waste, and if the (potential) waste is big enough
> that its cost dominates the cost of discovering whether it is waste,
> then it is worthwhile to invest time and money in making that
> determination. This implies that we must be able to measure the
> potential waste from the activity in question. If we cannot, then we
> formulate a plan for learning how to measure it... (and so on).
>
> I posit that asking these questions repeatedly will help us converge
> towards a more intentional, less wasteful, and therefore more effective
> way to work.
>
> [So is all this just a restatement of old ideas? I suspect it is, but
> perhaps this restatement has value. The good business reason to do it is
> that I get to add my own flavor-of-the-month-looking approach to agile,
> which might raise my profile as a consultant. See? I'm intentional in my
> approach to describing ISD!]
>
> So is there anything valuable about agile or XP that we wouldn't do in
> ISD?
> --
> J. B. (Joe) Rainsberger :: http://www.jbrains.ca
> Your guide to software craftsmanship
> JUnit Recipes: Practical Methods for Programmer Testing
> 2005 Gordon Pask Award for contribution Agile Software Practice
>
>



--
Dean Wampler
http://www.objectmentor.com
http://www.aspectprogramming.com
http://www.contract4j.org


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

Andrew Hunt wrote:

> On Jul 17, 2007, at 4:56 PM, J. B. Rainsberger wrote:

>  > Why should agile /require/ TDD? TDD is a design activity. Does agile
>  > care how I design software? I thought agile was mostly concerned with
>  > issues like early realization of value and predictable delivery.
>
> Not to jump in midway on a heated discussion (oops, looks like I
> did :-), but I thought agile was concerned with dealing with change
> appropriately, instead of following a by-now-out-of-date plan. That
> doesn't require functional testing, or TDD, or anything else -- those
> are implementation details. Damned handy ones, if you ask me, but
> not required by any realistic, broadly based definition.
>
> FWIW, in Practices of an Agile Developer that I wrote with Venkat, I
> posited this definition of agile:
>
> "Agile development uses feedback to make constant adjustments in a
> highly collaborative environment."

I'd forgot about the "responding to change" part of the manifesto, but
then, I think predictable delivery handles that: in order to deliver a
changing product predictably, we need to be able to respond to change
effectively.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

Robert Biddle wrote:

> Ron Jeffries wrote:
>  > > There are many kinds of human activity systems.
>  > I suppose there are. I suspect that they would all work better
>  > insofar as they worked in concert rather than against each other.
>
> That's not so clear to me, except if we imagine it in the most general
> sense. Consider a parliament, for example: I think the tension between
> the government and the opposition is useful. Of course, I don't think
> is makes sense for it to become too bitter, but civil disagreement can
> be enlightening.

One reason to participate in a parliament is perhaps the shared vision
that such an adversarial system is effective to combat the "absolute
power corrupts absolutely" phenomenon. That's certainly a shared goal
towards which everyone works. I speak, of course, only of those people
who participate in parliament intentionally, and not of the ones who do
it for reasons of, say, lack of a better thing to do, or in a desire to
carry on family tradition, that sort of thing.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

Robert Biddle wrote:
> In that spirit, let me ask:
>
> * is a family a team?
> * is a church a team?
> * is a prison a team?
> * is a hospital a team?

I suppose you mean these in the sense of "does being a 'good' family
require being a team?" I think so. In my limited experience, the best
personal relationships have been marked by shared goals, shared
philosophy and a sense of "we're in this together". The poorest
relationships have been marked by different goals, hiding, incongruence,
and the like.

I can't speak to churches, since I don't go into them. Same with prisons.

I do have some experience in hospital, and I'd venture that even if the
entire hospital isn't a team, good hospitals house many teams working
side by side within a general framework, such as the laws that pertain
to medicine and basic principles of business.

> * do I form a team with my mailman?
> * do I form a team with my local police?
> * do I form a team with my local criminals?
> * do I form a team with my goverment?

I'm not sure how you mean these questions. Do you mean "should I..."? Do
you mean "am I now..."?

I don't feel like I'm on a team with my mailman, but rather he provides
me a service. I don't do anything directly for him. I don't run a
business with the purpose of needing to mail things, which happens to
pay his salary.

My (our) government certainly isn't on my team. Specifically, the CRA is
very much not on my team.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

Robert Biddle wrote:

> My difficulty is with P2 and P3. In these cases, one actor is really
> driving, and the other has a role as a helper. If, for example, the
> driver decides that they no longer need the helper, they can just let
> them go. This doesn't seem like a "whole team" to me. To return to
> your sports analogy, while they both might be players on the team, one
> is also both the team owner and the referee.

Well, I think "the market" is the referee, and currency flow is the
usual scoring mechanism.

As for the team owner, I guess that's the owner of the business.

Returning to your cases, if Pat and Sandy truly work together, then it
becomes clear before too long that as long as the project delivers
needed value to the company, then they need one another. If Pat happens
to be the business owner and decides that the project has delivered
enough value, Pat can stop the project. Pat is letting go of the
project, which happens to let go of Sandy, rather than letting go of
Sandy because Sandy's no longer useful.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

[I can't remember the last time I started a thread. Here goes.]

In another thread, I wrote that we could rename "agile software
development" to "Intentional Software Development" and retain the
essence and value of agile. The goal is to sidestep the "define agile"
problem and instead use a more intention-revealing name whose definition
is more apparent in general.

So let me propose an idea. I'm sure it's not new.

INTENTIONAL SOFTWARE DEVELOPMENT
--------------------------------
We have discovered that working intentionally is the cornerstone of
effective software development, through building software, running
software companies and teaching others to do both. In an attempt to
clarify our approach and give context to what we recommend others do, we
use the term "intentional" do describe our philosophy. That is, we
develop software most effectively when we do so intentionally. This
means that we stop doing any activity whose intention is not both
clearly understood and demonstrably relevant to our business goals. What
is left is what we need to do in order to be effective.

Intentional Software Development (ISD) focuses primarily on identifying
waste and eliminating it, making it a Lean approach to software. It
proposes asking the question "What's the good business reason to do
this?" as the primary tool for identifying waste. When we ask this
question of an activity, there are three possible answers:

1. There is no good business reason to do this.
2. X is the good business reason to do this.
3. We aren't sure whether there is a good business reason to do this.
(Alternately: we think there's a good business reason to do this, but
can't put our finger on it.)

When we answer #1, we stop doing the activity until and unless we
discover a good business reason to do it.

When we answer #2, we continue doing the activity, but ask the follow-up
question, "Is there a cheaper way to do this and still satisfy the
corresponding business needs?"

When we answer #3, we formulate a plan to gather information to help us
answer the question. The good business reason to do this is clear: if
the activity really is waste, and if the (potential) waste is big enough
that its cost dominates the cost of discovering whether it is waste,
then it is worthwhile to invest time and money in making that
determination. This implies that we must be able to measure the
potential waste from the activity in question. If we cannot, then we
formulate a plan for learning how to measure it... (and so on).

I posit that asking these questions repeatedly will help us converge
towards a more intentional, less wasteful, and therefore more effective
way to work.

[So is all this just a restatement of old ideas? I suspect it is, but
perhaps this restatement has value. The good business reason to do it is
that I get to add my own flavor-of-the-month-looking approach to agile,
which might raise my profile as a consultant. See? I'm intentional in my
approach to describing ISD!]

So is there anything valuable about agile or XP that we wouldn't do in ISD?
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice