[AM] Unfounded assertion

[Graham]

"I mentioned to Graham several times that he should invest the time to read
the values and principles at www.agilealliance.org, but he chose not to. I
eventually posted the material to the DM discussion list, but the only
responses were to mock the concepts. Oh well."
----------------------------------------------
Scott

Please discontinue making unfounded assertions and implying I have done no
research into Agile methods. As to whether I am misinterpreting Agile...

I long ago read the Agile manifesto, and indeed include it in presentations
on Agile methods. I have gathered feedback from DSDM projects and
interviewed people from a team applying Extreme Programming in close to its
pure form. (You think coding the unit test first is not a painful
discipline? You think everybody enjoys pair programming?)

The agile values are mushy. The agile principles are more helpful, and you
ought to have noticed that I drew on them to formulate my list of 8 points
------------------------------------------
1 ensure sponsors and customers are commited to all of the following
principles

2 be flexibile about requirements and time or cash box your delivery
³Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.²

3 maintain continuous and close user involvement
³Business people and developers must work together daily throughout the
project.²

4 empower a small team (including users) to get on with it
³Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.²

5 focus on program code and tests rather than on specifications
³Working software is the primary measure of progress.
The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.²

6 develop iteratively, driven by priorities
³Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.²

7 iteratively refactor program structures and data structures built so far

8 use prototypes to tackle tricky design issues early
------------------------------------------
I added one point at the beginning, which Agilists overlook at their peril.

I added two points at the end: 7 in deference to Martin Fowler and yourself,
and 8 in deference to DSDM and UP/RUP.

I left out principles at the bottom of the Agile list partly because they
did not seem to me so definitive, and partly to be more concise.
"Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances
agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from
self-organizing teams.
At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly."

I won't explain all my rewordings, but ³Welcome changing requirements, even
late in development" is simply untenable unless your customer has agreed to
point 2 as I express it above.

Graham

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Scott Ambler]

At 05:02 PM 1/27/2004 +0000, you wrote:
>"I mentioned to Graham several times that he should invest the time to read
>the values and principles at www.agilealliance.org, but he chose not to. I
>eventually posted the material to the DM discussion list, but the only
>responses were to mock the concepts. Oh well."
>----------------------------------------------
>Scott
>
>Please discontinue making unfounded assertions and implying I have done no
>research into Agile methods.

I'm sorry. I must have jumped to that conclusion last week when I asked
you whether you had taken the time to read the 12 principles defined by the
Agile Alliance (AA) and you replied that you didn't need to follow the link
that I provided. Then you preceded to present your points which were close
to those described by the alliance but not quite along the lines of what
everyone else within the industry has been talking about, as you're seeing
in the other postings on this list.


> As to whether I am misinterpreting Agile...
>
>I long ago read the Agile manifesto, and indeed include it in presentations
>on Agile methods. I have gathered feedback from DSDM projects and
>interviewed people from a team applying Extreme Programming in close to its
>pure form. (You think coding the unit test first is not a painful
>discipline? You think everybody enjoys pair programming?)

I've been quite clear in the past that it takes great discipline to follow
XP. I've also been very clear that not everyone can do PP, that a small
minority just don't have the interpersonal skills that it requires.



>The agile values are mushy. The agile principles are more helpful, and you
>ought to have noticed that I drew on them to formulate my list of 8 points

If memory serves, you never once referred to them in any of your posts on
the DM discuss list, and now, I believe, is the first time you're
mentioning them on this list.


>------------------------------------------
>1 ensure sponsors and customers are commited to all of the following
>principles
>
><snip>
>
>7 iteratively refactor program structures and data structures built so far
>
>8 use prototypes to tackle tricky design issues early
>------------------------------------------
>I added one point at the beginning, which Agilists overlook at their peril.

No, we don't overlook this. It's basic change management. It's also
something that is implied by the greater teamwork and cooperation that we
do focus on, although it doesn't hurt to make ideas such as this explicit.



>I added two points at the end: 7 in deference to Martin Fowler and yourself,
>and 8 in deference to DSDM and UP/RUP.

I'm not sure that you need to insist on refactoring as a principle of
agility -- you can be agile and not refactor, and you can refactor and not
be agile.

#8 is clearly covered by the first principle described by the AA.



>I left out principles at the bottom of the Agile list partly because they
>did not seem to me so definitive, and partly to be more concise.
>"Agile processes promote sustainable development. The sponsors, developers,
>and users should be able to maintain a constant pace indefinitely.
>Continuous attention to technical excellence and good design enhances
>agility.
>Simplicity--the art of maximizing the amount of work not done--is essential.
>The best architectures, requirements, and designs emerge from
>self-organizing teams.
>At regular intervals, the team reflects on how to become more effective,
>then tunes and adjusts its behavior accordingly."
>
>I won't explain all my rewordings, but ³Welcome changing requirements, even
>late in development" is simply untenable unless your customer has agreed to
>point 2 as I express it above.

Graham, I think you should explain your rewordings. "I think it's mushy"
isn't a very good reason to reinvent the wheel, particularly when that
wheel is well accepted within the industry and when you haven't responded
to the feedback which people have provided on this list.



>Graham
>
><snip>

====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Jason Gorman]

I would take the manifesto with a pinch of salt. They're hardly the Ten
Commandments or Principa Mathematica. They're just stories about how other
people managed to adapt quickly to change on software projects. I treat them
like diet books or exercise regimes. Some minor celeb loses 20 lbs eating
nothing but leather and running up and down stairs with a cat on their head,
and everybody says "you look great! What's your secret?" and before you know
it they've got a book and a video out telling everybody "this is how to lose
20lbs"... XP is the Atkins Diet of software development methods. It worked
for Jennifer Aniston, but I hear Geri Halliwell's not too keen.

Jason Gorman
http://www.objectmonkey.com

-----Original Message-----
From: Graham [mailto:***@virgin.net]
Sent: 27 January 2004 17:02
To: ***@topica.com
Subject: [AM] Unfounded assertion

"I mentioned to Graham several times that he should invest the time to read
the values and principles at www.agilealliance.org, but he chose not to. I
eventually posted the material to the DM discussion list, but the only
responses were to mock the concepts. Oh well."
----------------------------------------------
Scott

Please discontinue making unfounded assertions and implying I have done no
research into Agile methods. As to whether I am misinterpreting Agile...

I long ago read the Agile manifesto, and indeed include it in presentations
on Agile methods. I have gathered feedback from DSDM projects and
interviewed people from a team applying Extreme Programming in close to its
pure form. (You think coding the unit test first is not a painful
discipline? You think everybody enjoys pair programming?)

The agile values are mushy. The agile principles are more helpful, and you
ought to have noticed that I drew on them to formulate my list of 8 points
------------------------------------------
1 ensure sponsors and customers are commited to all of the following
principles

2 be flexibile about requirements and time or cash box your delivery
³Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.²

3 maintain continuous and close user involvement ³Business people and
developers must work together daily throughout the project.²

4 empower a small team (including users) to get on with it ³Build projects
around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.²

5 focus on program code and tests rather than on specifications ³Working
software is the primary measure of progress.
The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.²

6 develop iteratively, driven by priorities ³Our highest priority is to
satisfy the customer through early and continuous delivery of valuable
software.
Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.²

7 iteratively refactor program structures and data structures built so far

8 use prototypes to tackle tricky design issues early
------------------------------------------
I added one point at the beginning, which Agilists overlook at their peril.

I added two points at the end: 7 in deference to Martin Fowler and yourself,
and 8 in deference to DSDM and UP/RUP.

I left out principles at the bottom of the Agile list partly because they
did not seem to me so definitive, and partly to be more concise.
"Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances
agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from
self-organizing teams.
At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly."

I won't explain all my rewordings, but ³Welcome changing requirements, even
late in development" is simply untenable unless your customer has agreed to
point 2 as I express it above.

Graham

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[J. B. Rainsberger]

Jason Gorman wrote:

> I would take the manifesto with a pinch of salt. They're hardly the Ten
> Commandments or Principa Mathematica. They're just stories about how other
> people managed to adapt quickly to change on software projects. I treat them
> like diet books or exercise regimes. Some minor celeb loses 20 lbs eating
> nothing but leather and running up and down stairs with a cat on their head,
> and everybody says "you look great! What's your secret?" and before you know
> it they've got a book and a video out telling everybody "this is how to lose
> 20lbs"... XP is the Atkins Diet of software development methods. It worked
> for Jennifer Aniston, but I hear Geri Halliwell's not too keen.

Of course.... only something like 3/4 of the population has the
hyperinsulinemia problem that low-carbohydrate eating counters. The rest
of the people have differently-behaving metabolisms. I happen to respond
well to it, whereas it makes my wife ill.

To bring this back to Agile, you have to pay attention the landscape
when choosing whether to be Agile on a particular project or in a
particular organization. Ward Cunningham said it well in his
presentation at XP/Agile Universe 2003: you have to have the right kind
of organization and the right kind of materials to run a successful XP
project. I don't know where Ward's presentation sits on the web, but you
might start at xpuniverse.com and see what you can find, if you're
interested.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Jonathan Kern]

Uhhh.

Are you saying the Agile Manifesto principles are equivalent one-off,
random, questionable statistical evidence as implied by your leather and
running regimen "fad" example?

Uhhh.

-- jon



> -----Original Message-----
> From: Jason Gorman [mailto:***@objectmonkey.com]
> Sent: Tuesday, January 27, 2004 1:23 PM
> To: ***@topica.com
> Subject: RE: [AM] Unfounded assertion
>
>
> I would take the manifesto with a pinch of salt. They're hardly the Ten
> Commandments or Principa Mathematica. They're just stories about how other
> people managed to adapt quickly to change on software projects. I
> treat them
> like diet books or exercise regimes. Some minor celeb loses 20 lbs eating
> nothing but leather and running up and down stairs with a cat on
> their head,
> and everybody says "you look great! What's your secret?" and
> before you know
> it they've got a book and a video out telling everybody "this is
> how to lose
> 20lbs"... XP is the Atkins Diet of software development methods. It worked
> for Jennifer Aniston, but I hear Geri Halliwell's not too keen.
>
> Jason Gorman
> http://www.objectmonkey.com
>
> -----Original Message-----
> From: Graham [mailto:***@virgin.net]
> Sent: 27 January 2004 17:02
> To: ***@topica.com
> Subject: [AM] Unfounded assertion
>
> "I mentioned to Graham several times that he should invest the
> time to read
> the values and principles at www.agilealliance.org, but he chose
> not to. I
> eventually posted the material to the DM discussion list, but the only
> responses were to mock the concepts. Oh well."
> ----------------------------------------------
> Scott
>
> Please discontinue making unfounded assertions and implying I have done no
> research into Agile methods. As to whether I am misinterpreting Agile...
>
> I long ago read the Agile manifesto, and indeed include it in
> presentations
> on Agile methods. I have gathered feedback from DSDM projects and
> interviewed people from a team applying Extreme Programming in
> close to its
> pure form. (You think coding the unit test first is not a painful
> discipline? You think everybody enjoys pair programming?)
>
> The agile values are mushy. The agile principles are more helpful, and you
> ought to have noticed that I drew on them to formulate my list of 8 points
> ------------------------------------------
> 1 ensure sponsors and customers are commited to all of the following
> principles
>
> 2 be flexibile about requirements and time or cash box your delivery
> ³Welcome changing requirements, even late in development. Agile processes
> harness change for the customer's competitive advantage.²
>
> 3 maintain continuous and close user involvement ³Business people and
> developers must work together daily throughout the project.²
>
> 4 empower a small team (including users) to get on with it ³Build projects
> around motivated individuals. Give them the environment and support they
> need, and trust them to get the job done.²
>
> 5 focus on program code and tests rather than on specifications ³Working
> software is the primary measure of progress.
> The most efficient and effective method of conveying information to and
> within a development team is face-to-face conversation.²
>
> 6 develop iteratively, driven by priorities ³Our highest priority is to
> satisfy the customer through early and continuous delivery of valuable
> software.
> Deliver working software frequently, from a couple of weeks to a couple of
> months, with a preference to the shorter timescale.²
>
> 7 iteratively refactor program structures and data structures built so far
>
> 8 use prototypes to tackle tricky design issues early
> ------------------------------------------
> I added one point at the beginning, which Agilists overlook at
> their peril.
>
> I added two points at the end: 7 in deference to Martin Fowler
> and yourself,
> and 8 in deference to DSDM and UP/RUP.
>
> I left out principles at the bottom of the Agile list partly because they
> did not seem to me so definitive, and partly to be more concise.
> "Agile processes promote sustainable development. The sponsors,
> developers,
> and users should be able to maintain a constant pace indefinitely.
> Continuous attention to technical excellence and good design enhances
> agility.
> Simplicity--the art of maximizing the amount of work not done--is
> essential.
> The best architectures, requirements, and designs emerge from
> self-organizing teams.
> At regular intervals, the team reflects on how to become more effective,
> then tunes and adjusts its behavior accordingly."
>
> I won't explain all my rewordings, but ³Welcome changing
> requirements, even
> late in development" is simply untenable unless your customer has
> agreed to
> point 2 as I express it above.
>
> Graham
>
> For more information about AM, visit the Agile Modeling Home Page at
> www.agilemodeling.com
>
> For more information about AM, visit the Agile Modeling Home Page
> at www.agilemodeling.com
>
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Jason Gorman]

I'm suggesting that there's more than one way to succeed, and that maybe
people shouldn't present their descriptions of how they succeeded as
*prescriptions* for how others will succeed. In agility, can we really
succeed in the future by repeating the successes of the past? Whether we
like it or not, projects are so complex now that there is always a
signfificant element of chance in the outcome, and no two projects are ever
exactly alike. When I read the manifesto, I see an attempt to generalise and
create a "theory of agility", and I think we would all admit we're a long
way from agreeing on that. If we're being genuinely agile, then we should
stick to the war stories and parables, and maybe over time a theory will
emerge :-)

Jason Gorman
http://www.objectmonkey.com

-----Original Message-----
From: Jonathan Kern [mailto:***@comcast.net]
Sent: 29 January 2004 04:17
To: ***@topica.com
Subject: RE: [AM] Unfounded assertion

Uhhh.

Are you saying the Agile Manifesto principles are equivalent one-off,
random, questionable statistical evidence as implied by your leather and
running regimen "fad" example?

Uhhh.

-- jon



> -----Original Message-----
> From: Jason Gorman [mailto:***@objectmonkey.com]
> Sent: Tuesday, January 27, 2004 1:23 PM
> To: ***@topica.com
> Subject: RE: [AM] Unfounded assertion
>
>
> I would take the manifesto with a pinch of salt. They're hardly the
> Ten Commandments or Principa Mathematica. They're just stories about
> how other people managed to adapt quickly to change on software
> projects. I treat them like diet books or exercise regimes. Some minor
> celeb loses 20 lbs eating nothing but leather and running up and down
> stairs with a cat on their head, and everybody says "you look great!
> What's your secret?" and before you know it they've got a book and a
> video out telling everybody "this is how to lose 20lbs"... XP is the
> Atkins Diet of software development methods. It worked for Jennifer
> Aniston, but I hear Geri Halliwell's not too keen.
>
> Jason Gorman
> http://www.objectmonkey.com
>
> -----Original Message-----
> From: Graham [mailto:***@virgin.net]
> Sent: 27 January 2004 17:02
> To: ***@topica.com
> Subject: [AM] Unfounded assertion
>
> "I mentioned to Graham several times that he should invest the time to
> read the values and principles at www.agilealliance.org, but he chose
> not to. I eventually posted the material to the DM discussion list,
> but the only responses were to mock the concepts. Oh well."
> ----------------------------------------------
> Scott
>
> Please discontinue making unfounded assertions and implying I have
> done no research into Agile methods. As to whether I am misinterpreting
Agile...
>
> I long ago read the Agile manifesto, and indeed include it in
> presentations on Agile methods. I have gathered feedback from DSDM
> projects and interviewed people from a team applying Extreme
> Programming in close to its pure form. (You think coding the unit test
> first is not a painful discipline? You think everybody enjoys pair
> programming?)
>
> The agile values are mushy. The agile principles are more helpful, and
> you ought to have noticed that I drew on them to formulate my list of
> 8 points
> ------------------------------------------
> 1 ensure sponsors and customers are commited to all of the following
> principles
>
> 2 be flexibile about requirements and time or cash box your delivery
> ³Welcome changing requirements, even late in development. Agile
> processes harness change for the customer's competitive advantage.²
>
> 3 maintain continuous and close user involvement ³Business people and
> developers must work together daily throughout the project.²
>
> 4 empower a small team (including users) to get on with it ³Build
> projects around motivated individuals. Give them the environment and
> support they need, and trust them to get the job done.²
>
> 5 focus on program code and tests rather than on specifications
> ³Working software is the primary measure of progress.
> The most efficient and effective method of conveying information to
> and within a development team is face-to-face conversation.²
>
> 6 develop iteratively, driven by priorities ³Our highest priority is
> to satisfy the customer through early and continuous delivery of
> valuable software.
> Deliver working software frequently, from a couple of weeks to a
> couple of months, with a preference to the shorter timescale.²
>
> 7 iteratively refactor program structures and data structures built so
> far
>
> 8 use prototypes to tackle tricky design issues early
> ------------------------------------------
> I added one point at the beginning, which Agilists overlook at their
> peril.
>
> I added two points at the end: 7 in deference to Martin Fowler and
> yourself, and 8 in deference to DSDM and UP/RUP.
>
> I left out principles at the bottom of the Agile list partly because
> they did not seem to me so definitive, and partly to be more concise.
> "Agile processes promote sustainable development. The sponsors,
> developers, and users should be able to maintain a constant pace
> indefinitely.
> Continuous attention to technical excellence and good design enhances
> agility.
> Simplicity--the art of maximizing the amount of work not done--is
> essential.
> The best architectures, requirements, and designs emerge from
> self-organizing teams.
> At regular intervals, the team reflects on how to become more
> effective, then tunes and adjusts its behavior accordingly."
>
> I won't explain all my rewordings, but ³Welcome changing requirements,
> even late in development" is simply untenable unless your customer has
> agreed to point 2 as I express it above.
>
> Graham
>
> For more information about AM, visit the Agile Modeling Home Page at
> www.agilemodeling.com
>
> For more information about AM, visit the Agile Modeling Home Page at
> www.agilemodeling.com
>
>

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[J. B. Rainsberger]

Jason Gorman wrote:

> I'm suggesting that there's more than one way to succeed, and that maybe
> people shouldn't present their descriptions of how they succeeded as
> *prescriptions* for how others will succeed.

Please describe the part of the manifesto that says "if you do these
things, you will be successful." When I read it, I see, "we think there
is more value in XXX than YYY; we work according to these values and
prefer to work with others who share these values."

> In agility, can we really
> succeed in the future by repeating the successes of the past? Whether we
> like it or not, projects are so complex now that there is always a
> signfificant element of chance in the outcome, and no two projects are ever
> exactly alike. When I read the manifesto, I see an attempt to generalise and
> create a "theory of agility", and I think we would all admit we're a long
> way from agreeing on that. If we're being genuinely agile, then we should
> stick to the war stories and parables, and maybe over time a theory will
> emerge :-)

No, no... the manifesto is a /description/ of agility, and not a theory
of agility. The book Lean Software Development is a theory of agility,
and I think a pretty good one.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Jason Gorman]

Quite right. The principles aren't principles at all. They're preferences
:-)

Jason Gorman
http://www.objectmonkey.com

-----Original Message-----
From: J. B. Rainsberger [mailto:***@rogers.com]
Sent: 29 January 2004 17:05
To: ***@topica.com
Subject: Re: [AM] Unfounded assertion

Jason Gorman wrote:

> I'm suggesting that there's more than one way to succeed, and that
> maybe people shouldn't present their descriptions of how they
> succeeded as
> *prescriptions* for how others will succeed.

Please describe the part of the manifesto that says "if you do these things,
you will be successful." When I read it, I see, "we think there is more
value in XXX than YYY; we work according to these values and prefer to work
with others who share these values."

> In agility, can we really
> succeed in the future by repeating the successes of the past? Whether
> we like it or not, projects are so complex now that there is always a
> signfificant element of chance in the outcome, and no two projects are
> ever exactly alike. When I read the manifesto, I see an attempt to
> generalise and create a "theory of agility", and I think we would all
> admit we're a long way from agreeing on that. If we're being genuinely
> agile, then we should stick to the war stories and parables, and maybe
> over time a theory will emerge :-)

No, no... the manifesto is a /description/ of agility, and not a theory of
agility. The book Lean Software Development is a theory of agility, and I
think a pretty good one.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone] Let's write software that
people understand

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Scott Ambler]

Perhaps at an upcoming conference it would be interesting to hold some sort
of workshop where the manifesto and principles are explored and potentially
validated based on experience since they were defined?

Snowbird II perhaps?

- Scott

At 11:17 PM 1/28/2004 -0500, you wrote:
>Uhhh.
>
>Are you saying the Agile Manifesto principles are equivalent one-off,
>random, questionable statistical evidence as implied by your leather and
>running regimen "fad" example?
>
>Uhhh.
>
>-- jon
>
>
>
> > -----Original Message-----
> > From: Jason Gorman [mailto:***@objectmonkey.com]
> > Sent: Tuesday, January 27, 2004 1:23 PM
> > To: ***@topica.com
> > Subject: RE: [AM] Unfounded assertion
> >
> >
> > I would take the manifesto with a pinch of salt. They're hardly the Ten
> > Commandments or Principa Mathematica. They're just stories about how other
> > people managed to adapt quickly to change on software projects. I
> > treat them
> > like diet books or exercise regimes. Some minor celeb loses 20 lbs eating
> > nothing but leather and running up and down stairs with a cat on
> > their head,
> > and everybody says "you look great! What's your secret?" and
> > before you know
> > it they've got a book and a video out telling everybody "this is
> > how to lose
> > 20lbs"... XP is the Atkins Diet of software development methods. It worked
> > for Jennifer Aniston, but I hear Geri Halliwell's not too keen.
> >
> > Jason Gorman
> > http://www.objectmonkey.com
> >
> > -----Original Message-----
> > From: Graham [mailto:***@virgin.net]
> > Sent: 27 January 2004 17:02
> > To: ***@topica.com
> > Subject: [AM] Unfounded assertion
> >
> > "I mentioned to Graham several times that he should invest the
> > time to read
> > the values and principles at www.agilealliance.org, but he chose
> > not to. I
> > eventually posted the material to the DM discussion list, but the only
> > responses were to mock the concepts. Oh well."
> > ----------------------------------------------
> > Scott
> >
> > Please discontinue making unfounded assertions and implying I have done no
> > research into Agile methods. As to whether I am misinterpreting Agile...
> >
> > I long ago read the Agile manifesto, and indeed include it in
> > presentations
> > on Agile methods. I have gathered feedback from DSDM projects and
> > interviewed people from a team applying Extreme Programming in
> > close to its
> > pure form. (You think coding the unit test first is not a painful
> > discipline? You think everybody enjoys pair programming?)
> >
> > The agile values are mushy. The agile principles are more helpful, and you
> > ought to have noticed that I drew on them to formulate my list of 8 points
> > ------------------------------------------
> > 1 ensure sponsors and customers are commited to all of the following
> > principles
> >
> > 2 be flexibile about requirements and time or cash box your delivery
> > ³Welcome changing requirements, even late in development. Agile processes
> > harness change for the customer's competitive advantage.²
> >
> > 3 maintain continuous and close user involvement ³Business people and
> > developers must work together daily throughout the project.²
> >
> > 4 empower a small team (including users) to get on with it ³Build projects
> > around motivated individuals. Give them the environment and support they
> > need, and trust them to get the job done.²
> >
> > 5 focus on program code and tests rather than on specifications ³Working
> > software is the primary measure of progress.
> > The most efficient and effective method of conveying information to and
> > within a development team is face-to-face conversation.²
> >
> > 6 develop iteratively, driven by priorities ³Our highest priority is to
> > satisfy the customer through early and continuous delivery of valuable
> > software.
> > Deliver working software frequently, from a couple of weeks to a couple of
> > months, with a preference to the shorter timescale.²
> >
> > 7 iteratively refactor program structures and data structures built so far
> >
> > 8 use prototypes to tackle tricky design issues early
> > ------------------------------------------
> > I added one point at the beginning, which Agilists overlook at
> > their peril.
> >
> > I added two points at the end: 7 in deference to Martin Fowler
> > and yourself,
> > and 8 in deference to DSDM and UP/RUP.
> >
> > I left out principles at the bottom of the Agile list partly because they
> > did not seem to me so definitive, and partly to be more concise.
> > "Agile processes promote sustainable development. The sponsors,
> > developers,
> > and users should be able to maintain a constant pace indefinitely.
> > Continuous attention to technical excellence and good design enhances
> > agility.
> > Simplicity--the art of maximizing the amount of work not done--is
> > essential.
> > The best architectures, requirements, and designs emerge from
> > self-organizing teams.
> > At regular intervals, the team reflects on how to become more effective,
> > then tunes and adjusts its behavior accordingly."
> >
> > I won't explain all my rewordings, but ³Welcome changing
> > requirements, even
> > late in development" is simply untenable unless your customer has
> > agreed to
> > point 2 as I express it above.
> >
> > Graham
> >
> > For more information about AM, visit the Agile Modeling Home Page at
> > www.agilemodeling.com
> >
> > For more information about AM, visit the Agile Modeling Home Page
> > at www.agilemodeling.com
> >
> >
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com

====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Jason Gorman]

I'd be up for that :-) When is Snowbird II?

Jason Gorman
http://www.objectmonkey.com


-----Original Message-----
From: Scott Ambler [mailto:***@ronin-intl.com]
Sent: 29 January 2004 13:18
To: ***@topica.com
Subject: Validating Agility was RE: [AM] Unfounded assertion

Perhaps at an upcoming conference it would be interesting to hold some sort
of workshop where the manifesto and principles are explored and potentially
validated based on experience since they were defined?

Snowbird II perhaps?

- Scott

At 11:17 PM 1/28/2004 -0500, you wrote:
>Uhhh.
>
>Are you saying the Agile Manifesto principles are equivalent one-off,
>random, questionable statistical evidence as implied by your leather
>and running regimen "fad" example?
>
>Uhhh.
>
>-- jon
>
>
>
> > -----Original Message-----
> > From: Jason Gorman [mailto:***@objectmonkey.com]
> > Sent: Tuesday, January 27, 2004 1:23 PM
> > To: ***@topica.com
> > Subject: RE: [AM] Unfounded assertion
> >
> >
> > I would take the manifesto with a pinch of salt. They're hardly the
> > Ten Commandments or Principa Mathematica. They're just stories about
> > how other people managed to adapt quickly to change on software
> > projects. I treat them like diet books or exercise regimes. Some
> > minor celeb loses 20 lbs eating nothing but leather and running up
> > and down stairs with a cat on their head, and everybody says "you
> > look great! What's your secret?" and before you know it they've got
> > a book and a video out telling everybody "this is how to lose
> > 20lbs"... XP is the Atkins Diet of software development methods. It
> > worked for Jennifer Aniston, but I hear Geri Halliwell's not too keen.
> >
> > Jason Gorman
> > http://www.objectmonkey.com
> >
> > -----Original Message-----
> > From: Graham [mailto:***@virgin.net]
> > Sent: 27 January 2004 17:02
> > To: ***@topica.com
> > Subject: [AM] Unfounded assertion
> >
> > "I mentioned to Graham several times that he should invest the time
> > to read the values and principles at www.agilealliance.org, but he
> > chose not to. I eventually posted the material to the DM discussion
> > list, but the only responses were to mock the concepts. Oh well."
> > ----------------------------------------------
> > Scott
> >
> > Please discontinue making unfounded assertions and implying I have
> > done no research into Agile methods. As to whether I am misinterpreting
Agile...
> >
> > I long ago read the Agile manifesto, and indeed include it in
> > presentations on Agile methods. I have gathered feedback from DSDM
> > projects and interviewed people from a team applying Extreme
> > Programming in close to its pure form. (You think coding the unit
> > test first is not a painful discipline? You think everybody enjoys
> > pair programming?)
> >
> > The agile values are mushy. The agile principles are more helpful,
> > and you ought to have noticed that I drew on them to formulate my
> > list of 8 points
> > ------------------------------------------
> > 1 ensure sponsors and customers are commited to all of the following
> > principles
> >
> > 2 be flexibile about requirements and time or cash box your delivery
> > ³Welcome changing requirements, even late in development. Agile
> > processes harness change for the customer's competitive advantage.²
> >
> > 3 maintain continuous and close user involvement ³Business people
> > and developers must work together daily throughout the project.²
> >
> > 4 empower a small team (including users) to get on with it ³Build
> > projects around motivated individuals. Give them the environment and
> > support they need, and trust them to get the job done.²
> >
> > 5 focus on program code and tests rather than on specifications
> > ³Working software is the primary measure of progress.
> > The most efficient and effective method of conveying information to
> > and within a development team is face-to-face conversation.²
> >
> > 6 develop iteratively, driven by priorities ³Our highest priority is
> > to satisfy the customer through early and continuous delivery of
> > valuable software.
> > Deliver working software frequently, from a couple of weeks to a
> > couple of months, with a preference to the shorter timescale.²
> >
> > 7 iteratively refactor program structures and data structures built
> > so far
> >
> > 8 use prototypes to tackle tricky design issues early
> > ------------------------------------------
> > I added one point at the beginning, which Agilists overlook at their
> > peril.
> >
> > I added two points at the end: 7 in deference to Martin Fowler and
> > yourself, and 8 in deference to DSDM and UP/RUP.
> >
> > I left out principles at the bottom of the Agile list partly because
> > they did not seem to me so definitive, and partly to be more concise.
> > "Agile processes promote sustainable development. The sponsors,
> > developers, and users should be able to maintain a constant pace
> > indefinitely.
> > Continuous attention to technical excellence and good design
> > enhances agility.
> > Simplicity--the art of maximizing the amount of work not done--is
> > essential.
> > The best architectures, requirements, and designs emerge from
> > self-organizing teams.
> > At regular intervals, the team reflects on how to become more
> > effective, then tunes and adjusts its behavior accordingly."
> >
> > I won't explain all my rewordings, but ³Welcome changing
> > requirements, even late in development" is simply untenable unless
> > your customer has agreed to point 2 as I express it above.
> >
> > Graham
> >
> > For more information about AM, visit the Agile Modeling Home Page at
> > www.agilemodeling.com
> >
> > For more information about AM, visit the Agile Modeling Home Page at
> > www.agilemodeling.com
> >
> >
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com

====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[r***@eiscon.com]

I like the restatement of #3 :-)

Ronald E. Thompson III
Director of Product Delivery
govONE Solutions
[phone]
[phone]
***@govONEsolutions.com
***@eiscon.com

"One of the penalties for refusing to participate in politics is that you
end up being governed by your inferiors."
-Plato




-----Original Message-----
From: Graham [mailto:***@virgin.net]
Sent: Tuesday, January 27, 2004 10:02 AM
To: ***@topica.com
Subject: [AM] Unfounded assertion


"I mentioned to Graham several times that he should invest the time to read
the values and principles at www.agilealliance.org, but he chose not to. I
eventually posted the material to the DM discussion list, but the only
responses were to mock the concepts. Oh well."
----------------------------------------------
Scott

Please discontinue making unfounded assertions and implying I have done no
research into Agile methods. As to whether I am misinterpreting Agile...

I long ago read the Agile manifesto, and indeed include it in presentations
on Agile methods. I have gathered feedback from DSDM projects and
interviewed people from a team applying Extreme Programming in close to its
pure form. (You think coding the unit test first is not a painful
discipline? You think everybody enjoys pair programming?)

The agile values are mushy. The agile principles are more helpful, and you
ought to have noticed that I drew on them to formulate my list of 8 points
------------------------------------------
1 ensure sponsors and customers are commited to all of the following
principles

2 be flexibile about requirements and time or cash box your delivery
³Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.²

3 maintain continuous and close user involvement
³Business people and developers must work together daily throughout the
project.²

4 empower a small team (including users) to get on with it
³Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.²

5 focus on program code and tests rather than on specifications
³Working software is the primary measure of progress.
The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.²

6 develop iteratively, driven by priorities
³Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.²

7 iteratively refactor program structures and data structures built so far

8 use prototypes to tackle tricky design issues early
------------------------------------------
I added one point at the beginning, which Agilists overlook at their peril.

I added two points at the end: 7 in deference to Martin Fowler and yourself,
and 8 in deference to DSDM and UP/RUP.

I left out principles at the bottom of the Agile list partly because they
did not seem to me so definitive, and partly to be more concise.
"Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances
agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from
self-organizing teams.
At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly."

I won't explain all my rewordings, but ³Welcome changing requirements, even
late in development" is simply untenable unless your customer has agreed to
point 2 as I express it above.

Graham

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 01/27/2004 2:46:29 PM Pacific Standard Time,
***@objectmonkey.com writes:


> I would take the manifesto with a pinch of salt. They're hardly the Ten
> Commandments or Principa Mathematica. They're just stories about how other
> people managed to adapt quickly to change on software projects. I treat them
> like diet books or exercise regimes.

Jason:

Like anything else, some people get it, and others don't. Those that need
hard and fast rules will turn their noses up at the Manifesto, those that don't
might get it.

Someone or other once told me that there are three kinds of people in the
world:
1. Those that make things happen.
2. Those that watch things happen.
3. Those that wonder what happened.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Jason Gorman]

Or perhaps those that don't need manifestos?

Jason Gorman
http://www.objectmonkey.com

_____

From: ***@aol.com [mailto:***@aol.com]
Sent: 27 January 2004 23:00
To: ***@topica.com
Subject: Re: [AM] Unfounded assertion


In a message dated 01/27/2004 2:46:29 PM Pacific Standard Time,
***@objectmonkey.com writes:




I would take the manifesto with a pinch of salt. They're hardly the Ten
Commandments or Principa Mathematica. They're just stories about how other
people managed to adapt quickly to change on software projects. I treat them
like diet books or exercise regimes.



Jason:

Like anything else, some people get it, and others don't. Those that need
hard and fast rules will turn their noses up at the Manifesto, those that
don't might get it.

Someone or other once told me that there are three kinds of people in the
world:
1. Those that make things happen.
2. Those that watch things happen.
3. Those that wonder what happened.

Regards,

Pete
For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Graham]

I have previously explained what mushy means, but briefly
- none of us would disagree
- unmeasurable

One reason I presented my eight points my way was for the rhetorical
purposes of my ongoing essay, which we haven't got to yet. But I also wanted
to distill the key points of Agility into a few short phrases you can more
readily say yes or no to when assessing a project.


----------
>From: Scott Ambler <***@ronin-intl.com>
>To: ***@topica.com
>Subject: Re: [AM] Unfounded assertion
>Date: Tue, Jan 27, 2004, 7:43 pm
>

>At 05:02 PM 1/27/2004 +0000, you wrote:
>>"I mentioned to Graham several times that he should invest the time to read
>>the values and principles at www.agilealliance.org, but he chose not to. I
>>eventually posted the material to the DM discussion list, but the only
>>responses were to mock the concepts. Oh well."
>>----------------------------------------------
>>Scott
>>
>>Please discontinue making unfounded assertions and implying I have done no
>>research into Agile methods.
>
>I'm sorry. I must have jumped to that conclusion last week when I asked
>you whether you had taken the time to read the 12 principles defined by the
>Agile Alliance (AA) and you replied that you didn't need to follow the link
>that I provided. Then you preceded to present your points which were close
>to those described by the alliance but not quite along the lines of what
>everyone else within the industry has been talking about, as you're seeing
>in the other postings on this list.
>
>
>> As to whether I am misinterpreting Agile...
>>
>>I long ago read the Agile manifesto, and indeed include it in presentations
>>on Agile methods. I have gathered feedback from DSDM projects and
>>interviewed people from a team applying Extreme Programming in close to its
>>pure form. (You think coding the unit test first is not a painful
>>discipline? You think everybody enjoys pair programming?)
>
>I've been quite clear in the past that it takes great discipline to follow
>XP. I've also been very clear that not everyone can do PP, that a small
>minority just don't have the interpersonal skills that it requires.
>
>
>
>>The agile values are mushy. The agile principles are more helpful, and you
>>ought to have noticed that I drew on them to formulate my list of 8 points
>
>If memory serves, you never once referred to them in any of your posts on
>the DM discuss list, and now, I believe, is the first time you're
>mentioning them on this list.
>
>
>>------------------------------------------
>>1 ensure sponsors and customers are commited to all of the following
>>principles
>>
>><snip>
>>
>>7 iteratively refactor program structures and data structures built so far
>>
>>8 use prototypes to tackle tricky design issues early
>>------------------------------------------
>>I added one point at the beginning, which Agilists overlook at their peril.
>
>No, we don't overlook this. It's basic change management. It's also
>something that is implied by the greater teamwork and cooperation that we
>do focus on, although it doesn't hurt to make ideas such as this explicit.
>
>
>
>>I added two points at the end: 7 in deference to Martin Fowler and yourself,
>>and 8 in deference to DSDM and UP/RUP.
>
>I'm not sure that you need to insist on refactoring as a principle of
>agility -- you can be agile and not refactor, and you can refactor and not
>be agile.
>
>#8 is clearly covered by the first principle described by the AA.
>
>
>
>>I left out principles at the bottom of the Agile list partly because they
>>did not seem to me so definitive, and partly to be more concise.
>>"Agile processes promote sustainable development. The sponsors, developers,
>>and users should be able to maintain a constant pace indefinitely.
>>Continuous attention to technical excellence and good design enhances
>>agility.
>>Simplicity--the art of maximizing the amount of work not done--is essential.
>>The best architectures, requirements, and designs emerge from
>>self-organizing teams.
>>At regular intervals, the team reflects on how to become more effective,
>>then tunes and adjusts its behavior accordingly."
>>
>>I won't explain all my rewordings, but ³Welcome changing requirements, even
>>late in development" is simply untenable unless your customer has agreed to
>>point 2 as I express it above.
>
>Graham, I think you should explain your rewordings. "I think it's mushy"
>isn't a very good reason to reinvent the wheel, particularly when that
>wheel is well accepted within the industry and when you haven't responded
>to the feedback which people have provided on this list.
>
>
>
>>Graham
>>
>><snip>
>
>====================================================
>Scott W. Ambler
>Senior Consultant, Ronin International, Inc.
>www.ronin-intl.com/company/scottAmbler.html
>
>www.agiledata.org
>www.agilemodeling.com
>www.ambysoft.com
>www.enterpriseunifiedprocess.info
>www.modelingstyle.info
>www.ronin-intl.com
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Graham]

Pete
People don't want hard and fast rules - they simply want advice, along with
a good indiication of when that advice works well and when it doesn't.
Agilists could usefully address more clearly the trade offs and compromises
we all have to make that move us away from an Agile ideal.

Jason
To test a statement of what Agile means, I like to reverse it and see if I
have a sensible statement or plausible recommendation. When I reverse your
observation I get something about people not adapting to change, and I am
not sure where that leaves me, since there isn't a contrasting methodology
that recommends this.


----------
From: ***@aol.com
To: ***@topica.com
Subject: Re: [AM] Unfounded assertion
Date: Tue, Jan 27, 2004, 11:00 pm


In a message dated 01/27/2004 2:46:29 PM Pacific Standard Time,
***@objectmonkey.com writes:


I would take the manifesto with a pinch of salt. They're hardly the Ten
Commandments or Principa Mathematica. They're just stories about how other
people managed to adapt quickly to change on software projects. I treat them
like diet books or exercise regimes.


Jason:

Like anything else, some people get it, and others don't. Those that need
hard and fast rules will turn their noses up at the Manifesto, those that
don't might get it.

Someone or other once told me that there are three kinds of people in the
world:
1. Those that make things happen.
2. Those that watch things happen.
3. Those that wonder what happened.

Regards,

PeteFor more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Scott E. Preece]

| From: <***@aol.com>
|
| In a message dated 01/27/2004 2:46:29 PM Pacific Standard Time,
| ***@objectmonkey.com writes:
|
| > I would take the manifesto with a pinch of salt. They're hardly the Ten
| > Commandments or Principa Mathematica. They're just stories about how other
| > people managed to adapt quickly to change on software projects. I treat them
| > like diet books or exercise regimes.
|
| Jason:
|
| Like anything else, some people get it, and others don't. Those that need
| hard and fast rules will turn their noses up at the Manifesto, those
| that don't might get it.
|
| Someone or other once told me that there are three kinds of people in the
| world:
| 1. Those that make things happen.
| 2. Those that watch things happen.
| 3. Those that wonder what happened.
---

I think the problem is that we're sitting here, in a community that
talks about various aspects of agile methods, and none of can point to
a set of rules for defining what "an agile method" is. The Principles
are generally good rules, but they're too vague to be a measuring stick
for saying "This process is agile, that one isn't," at least, not in the
sense that XP's 12 rules let you say "This project used XP, that one
didn't."

I think that's completely understandable, given their origins - the
alliance is a loose alliance that shares certain values and principles,
but not ALL values, principles, or rules. It's probably not possible to
strictly define the space of agile methods; that is naturally going to
be frustrating to the natural human desire to have such a definition for
an area one is interested in.

The Principles are a good starting point for testing a new approach - if
it seems well-aligned with the Principles it is likely to share at least
some of the advantages claimed for agile methods; if the new approach
doesn't fit well with some of the Principles, the author would be
well-advised to ask why and think about the implications.

Note, however, that it's perfectly possible to be in line with all the
Principles and fail (there's nothing in there about limits,
interrelationships, pathologies, etc.), just as it's perfectly possible
for non-agile processes to succeed at delivering software.


scott
--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: [phone]
phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Adrian Howard]

On Wednesday, January 28, 2004, at 02:36 pm, Scott E. Preece wrote:
[snip]
> I think the problem is that we're sitting here, in a community that
> talks about various aspects of agile methods, and none of can point to
> a set of rules for defining what "an agile method" is. The Principles
> are generally good rules, but they're too vague to be a measuring stick
> for saying "This process is agile, that one isn't," at least, not in
> the
> sense that XP's 12 rules let you say "This project used XP, that one
> didn't."
[snip]

Perhaps it's just me, but I've never really thought of agility as a
is/isn't divide but as a spectrum.

I can imagine saying things like:

"We were less agile when the customer worked offsite"
"We became more agile once we started doing continuous integration"

I can't imagine saying things like

"We stopped being agile when the customer worked offsite"
"We became agile once we started doing continuous integration"

At one end of the spectrum we have processes like XP at the other end
we have BDUF throw-it-over-the-wall waterfall. Any discussion about an
agile/not-agile divide seems likely to end up as a pointless argument
over where to draw the line in the middle.

The principles of the agile manifesto (or the XP/ICP values) don't give
me a measuring stick to say whether my process is/isn't agile. I never
thought they were intended to. What they do give me are some ways to
think about how to compare and contrast practices and processes to see
how they fit on the agility spectrum.

Here's hoping this makes some vague sort of sense :-)

Cheers,

Adrian

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Paul Oldfield]

(responding to Graham)

> People don't want hard and fast rules - they simply want advice,
> along with a good indiication of when that advice works well and
> when it doesn't. Agilists could usefully address more clearly the
> trade offs and compromises we all have to make that move us
> away from an Agile ideal.

Ah! As usual, all advice needs to be tailored to situations. You
might try looking at the stuff I've posted at
www.aptprocess.com/whitepapers/risk/RiskToPatternTable.htm
and let me know whether that sort of information is useful to you.


> To test a statement of what Agile means, I like to reverse it and
> see if I have a sensible statement or plausible recommendation.
> When I reverse your observation I get something about people
> not adapting to change, and I am not sure where that leaves me,
> since there isn't a contrasting methodology that recommends this.

OTOH you could probably find places that adopt the practices
by default, running on "if it ain't broken, don't fix it" way past the
breaking point.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Scott E. Preece]

| From: Paul Oldfield<***@compuserve.com>
|
| (responding to Graham)
|
| > People don't want hard and fast rules - they simply want advice,
| > along with a good indiication of when that advice works well and
| > when it doesn't. Agilists could usefully address more clearly the
| > trade offs and compromises we all have to make that move us
| > away from an Agile ideal.
|
| Ah! As usual, all advice needs to be tailored to situations. You
| might try looking at the stuff I've posted at
| www.aptprocess.com/whitepapers/risk/RiskToPatternTable.htm
| and let me know whether that sort of information is useful to you.
---

I'm not sure that psychologists would agree that "people don't want hard
and fast rules". People generally DO want rules to be clear and
well-defined and the borders of their autonomy clear. Security is very
high on the pyramid of needs.

People don't like being forced to operate by rules that don't work and
that they can't change, but I suspect you would find that most people
are perfectly happy operating by rules that they believe are working
well, especially if they feel that the system would repair itself if
the situation changed so that it didn't work.

There's a reason why self-help and diet books are hugely popular -
people generally WANT to defer to authority, especially if they believe
the blame for failure will go to the person with authority rather than
themselves. "I tried the X diet, but it didn't work" is easier to
accept than "I haven't been able to change my habits."

scott
--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: [phone]
phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Graham]

It is worse than that Scott. Anybody promoting (in the loosest sense of that
term) a methodology (in the loosest sense of that term) ought to start and
finish by addressing the two questions the senior business mamager asks

1) how can I tell whether a project is applying this methodology or not?
2) how will I know a year from now whether my projects are more or less
succesful as a result of following this methodology?

If we start out (as some in this list seem to do) by denying there can be
objective ways to distinguish an Agile project from a non-Agile one, then we
do not deserve to be taken seriously by business managers.

I am a fan of simplicity in a methodology, but not to the point of
vacuousness. I am fan of clarity, but not to the point of SBOs (statements
of the bleeding obvious). Above all I am a fan of stating where the
methodology stops, what its limits are, what situations it does not handle
so well, what the trade offs are. If the Agile manifesto gave more space to
these things, it would be immediately more persuasive.


----------
>From: "Scott E. Preece" <***@urbana.css.mot.com>
>To: ***@topica.com
>Subject: Re: [AM] Unfounded assertion
>Date: Wed, Jan 28, 2004, 2:36 pm
>

>
>| From: <***@aol.com>
>|
>| In a message dated 01/27/2004 2:46:29 PM Pacific Standard Time,
>| ***@objectmonkey.com writes:
>|
>| > I would take the manifesto with a pinch of salt. They're hardly the Ten
>| > Commandments or Principa Mathematica. They're just stories about how other
>| > people managed to adapt quickly to change on software projects. I treat them
>| > like diet books or exercise regimes.
>|
>| Jason:
>|
>| Like anything else, some people get it, and others don't. Those that need
>| hard and fast rules will turn their noses up at the Manifesto, those
>| that don't might get it.
>|
>| Someone or other once told me that there are three kinds of people in the
>| world:
>| 1. Those that make things happen.
>| 2. Those that watch things happen.
>| 3. Those that wonder what happened.
>---
>
>I think the problem is that we're sitting here, in a community that
>talks about various aspects of agile methods, and none of can point to
>a set of rules for defining what "an agile method" is. The Principles
>are generally good rules, but they're too vague to be a measuring stick
>for saying "This process is agile, that one isn't," at least, not in the
>sense that XP's 12 rules let you say "This project used XP, that one
>didn't."
>
>I think that's completely understandable, given their origins - the
>alliance is a loose alliance that shares certain values and principles,
>but not ALL values, principles, or rules. It's probably not possible to
>strictly define the space of agile methods; that is naturally going to
>be frustrating to the natural human desire to have such a definition for
>an area one is interested in.
>
>The Principles are a good starting point for testing a new approach - if
>it seems well-aligned with the Principles it is likely to share at least
>some of the advantages claimed for agile methods; if the new approach
>doesn't fit well with some of the Principles, the author would be
>well-advised to ask why and think about the implications.
>
>Note, however, that it's perfectly possible to be in line with all the
>Principles and fail (there's nothing in there about limits,
>interrelationships, pathologies, etc.), just as it's perfectly possible
>for non-agile processes to succeed at delivering software.
>
>
>scott
>--
>scott preece
>motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
>e-mail: ***@urbana.css.mot.com fax: [phone]
>phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Ian Chamberlain]

> Graham Berrisford Sent: 28 January 2004 17:01
>
> It is worse than that Scott. Anybody promoting (in the
> loosest sense of that
> term) a methodology (in the loosest sense of that term) ought
> to start and finish by addressing the two questions the
> senior business mamager asks

Agile is not one methodology. It is a suite of methodologies that more
or less conform to a common set of principles.
>
> 1) how can I tell whether a project is applying this
> methodology or not?

Let me fire this one back at you. As a business manager why should you
care? What you want is a solution to a business problem. Any
methodology, agile or not, that delivers the solution in a manner that
provides quantifiable benefit is good enough. Software Development
methodologies should be the remit of software development professionals,
in the same way as accountants decide how to implement GAAP, engineers
decide how to calculate stresses and loads and so on.

> 2) how will I know a year from now whether my projects are
> more or less succesful as a result of following this methodology?
>
Again why is this the province of the business manager? If the project
does what is required and gives benefit who cares what methodology was
used except for other software development professionals who might want
to learn what worked in that particular set of circumstances. The senior
business manager should be concerned with scoping issues - the what, not
the how. The project team should be professional and skilled enough to
identify the most appropriate process to deliver a solution within the
scope of the what. Trouble is, the vast majority of project teams just
don't have that ability, either through external constraints or lack of
skill and knowledge or some combination. What we have to do is find a
way to get them properly equipped.

> If we start out (as some in this list seem to do) by denying
> there can be objective ways to distinguish an Agile project
> from a non-Agile one, then we do not deserve to be taken
> seriously by business managers.
>
We do not deserve to be taken seriously by business managers when we
promise to do the impossible for nothing. That is why there is a lack of
trust. Repeatedly business managers are routinely lied to by technical
people. We use a special language littered with TLAs and pretend we know
all there is to know. When something goes wrong we try and blame
everyone and everything but ourselves. I.T. Salesmen, Project Managers,
et al are better than politicians at spin.

> I am a fan of simplicity in a methodology, but not to the
> point of vacuousness. I am fan of clarity, but not to the
> point of SBOs (statements of the bleeding obvious). Above all
> I am a fan of stating where the methodology stops, what its
> limits are, what situations it does not handle so well, what
> the trade offs are. If the Agile manifesto gave more space to
> these things, it would be immediately more persuasive.
>
It is not for the Agile Manifesto to state those things. It is for the
individual methodologies that claim to be agile to state those things
and how by doing those particular practices in that set of particular
circumstances they apply the principles of agility. Read the work of
those who actually developed the agile methodologies. None of them claim
that their methodology will work in every circumstance under any set of
conditions. Every one of them state that their methodology is a starting
point and should be adjusted as knowledge is discovered and lessons
learnt.

And if there is one thing that I've learnt over the last 20 years it is
that the bleeding obvious is as individual as you are.

Regards

Ian Chamberlain


>
> ----------
> >From: "Scott E. Preece" <***@urbana.css.mot.com>
> >To: ***@topica.com
> >Subject: Re: [AM] Unfounded assertion
> >Date: Wed, Jan 28, 2004, 2:36 pm
> >
>
> >
> >| From: <***@aol.com>
> >|
> >| In a message dated 01/27/2004 2:46:29 PM Pacific Standard Time,
> >| ***@objectmonkey.com writes:
> >|
> >| > I would take the manifesto with a pinch of salt. They're
> hardly the
> >| > Ten Commandments or Principa Mathematica. They're just stories
> >| > about how other people managed to adapt quickly to change on
> >| > software projects. I treat them like diet books or exercise
> >| > regimes.
> >|
> >| Jason:
> >|
> >| Like anything else, some people get it, and others don't.
> Those that
> >| need
> >| hard and fast rules will turn their noses up at the
> Manifesto, those
> >| that don't might get it.
> >|
> >| Someone or other once told me that there are three kinds
> of people in
> >| the
> >| world:
> >| 1. Those that make things happen.
> >| 2. Those that watch things happen.
> >| 3. Those that wonder what happened.
> >---
> >
> >I think the problem is that we're sitting here, in a community that
> >talks about various aspects of agile methods, and none of
> can point to
> >a set of rules for defining what "an agile method" is. The
> Principles
> >are generally good rules, but they're too vague to be a
> measuring stick
> >for saying "This process is agile, that one isn't," at least, not in
> >the sense that XP's 12 rules let you say "This project used XP, that
> >one didn't."
> >
> >I think that's completely understandable, given their origins - the
> >alliance is a loose alliance that shares certain values and
> principles,
> >but not ALL values, principles, or rules. It's probably not
> possible
> >to strictly define the space of agile methods; that is
> naturally going
> >to be frustrating to the natural human desire to have such a
> definition
> >for an area one is interested in.
> >
> >The Principles are a good starting point for testing a new
> approach -
> >if it seems well-aligned with the Principles it is likely to
> share at
> >least some of the advantages claimed for agile methods; if the new
> >approach doesn't fit well with some of the Principles, the
> author would
> >be well-advised to ask why and think about the implications.
> >
> >Note, however, that it's perfectly possible to be in line
> with all the
> >Principles and fail (there's nothing in there about limits,
> >interrelationships, pathologies, etc.), just as it's
> perfectly possible
> >for non-agile processes to succeed at delivering software.
> >
> >
> >scott
> >--
> >scott preece
> >motorola urbana design center (il67), 1800 s. oak st.,
> champaign, il 61820
> >e-mail: ***@urbana.css.mot.com fax: [phone]
> >phone: [phone] cell: 217-433-6114 pager:
> ***@msg.myvzw.com
> >
> >For more information about AM, visit the Agile Modeling Home Page at
> >www.agilemodeling.com
> >
> >
> >
>
> For more information about AM, visit the Agile Modeling Home
> Page at www.agilemodeling.com
>
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 01/28/2004 6:37:29 AM Pacific Standard Time,
***@urbana.css.mot.com writes:


> Note, however, that it's perfectly possible to be in line with all the
> Principles and fail (there's nothing in there about limits,
> interrelationships, pathologies, etc.), just as it's perfectly possible
> for non-agile processes to succeed at delivering software.
>

This one point may be the locus of the resistance to agile methods: people in
our business have heard of some many "silver bullets" that have fallen short
of their objectives that they are increasingly reluctant to consider new
ones, especially those that might seem "mushy" or imprecise.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Tiseo, Paul]

Jason:

That was *funny*! I'm just done cleaning the morning coffee off my screen.
Thanks.

_________________________________
Paul Tiseo, Systems Programmer
Research Computing Facility
Mayo Clinic Jacksonville, Griffin 371
***@mayo.edu
 

> -----Original Message-----
> From: Jason Gorman [mailto:***@objectmonkey.com]
> Sent: Tuesday, January 27, 2004 1:23 PM
> To: ***@topica.com
> Subject: RE: [AM] Unfounded assertion
>
> I would take the manifesto with a pinch of salt. They're hardly the Ten
> Commandments or Principa Mathematica. They're just stories about how other
> people managed to adapt quickly to change on software projects. I treat
> them
> like diet books or exercise regimes. Some minor celeb loses 20 lbs eating
> nothing but leather and running up and down stairs with a cat on their
> head,
> and everybody says "you look great! What's your secret?" and before you
> know
> it they've got a book and a video out telling everybody "this is how to
> lose
> 20lbs"... XP is the Atkins Diet of software development methods. It worked
> for Jennifer Aniston, but I hear Geri Halliwell's not too keen.
>
> Jason Gorman
> http://www.objectmonkey.com
>
> -----Original Message-----
> From: Graham [mailto:***@virgin.net]
> Sent: 27 January 2004 17:02
> To: ***@topica.com
> Subject: [AM] Unfounded assertion
>
> "I mentioned to Graham several times that he should invest the time to
> read
> the values and principles at www.agilealliance.org, but he chose not to.
> I
> eventually posted the material to the DM discussion list, but the only
> responses were to mock the concepts. Oh well."
> ----------------------------------------------
> Scott
>
> Please discontinue making unfounded assertions and implying I have done no
> research into Agile methods. As to whether I am misinterpreting Agile...
>
> I long ago read the Agile manifesto, and indeed include it in
> presentations
> on Agile methods. I have gathered feedback from DSDM projects and
> interviewed people from a team applying Extreme Programming in close to
> its
> pure form. (You think coding the unit test first is not a painful
> discipline? You think everybody enjoys pair programming?)
>
> The agile values are mushy. The agile principles are more helpful, and you
> ought to have noticed that I drew on them to formulate my list of 8 points
> ------------------------------------------
> 1 ensure sponsors and customers are commited to all of the following
> principles
>
> 2 be flexibile about requirements and time or cash box your delivery
> ³Welcome changing requirements, even late in development. Agile processes
> harness change for the customer's competitive advantage.²
>
> 3 maintain continuous and close user involvement ³Business people and
> developers must work together daily throughout the project.²
>
> 4 empower a small team (including users) to get on with it ³Build projects
> around motivated individuals. Give them the environment and support they
> need, and trust them to get the job done.²
>
> 5 focus on program code and tests rather than on specifications ³Working
> software is the primary measure of progress.
> The most efficient and effective method of conveying information to and
> within a development team is face-to-face conversation.²
>
> 6 develop iteratively, driven by priorities ³Our highest priority is to
> satisfy the customer through early and continuous delivery of valuable
> software.
> Deliver working software frequently, from a couple of weeks to a couple of
> months, with a preference to the shorter timescale.²
>
> 7 iteratively refactor program structures and data structures built so far
>
> 8 use prototypes to tackle tricky design issues early
> ------------------------------------------
> I added one point at the beginning, which Agilists overlook at their
> peril.
>
> I added two points at the end: 7 in deference to Martin Fowler and
> yourself,
> and 8 in deference to DSDM and UP/RUP.
>
> I left out principles at the bottom of the Agile list partly because they
> did not seem to me so definitive, and partly to be more concise.
> "Agile processes promote sustainable development. The sponsors,
> developers,
> and users should be able to maintain a constant pace indefinitely.
> Continuous attention to technical excellence and good design enhances
> agility.
> Simplicity--the art of maximizing the amount of work not done--is
> essential.
> The best architectures, requirements, and designs emerge from
> self-organizing teams.
> At regular intervals, the team reflects on how to become more effective,
> then tunes and adjusts its behavior accordingly."
>
> I won't explain all my rewordings, but ³Welcome changing requirements,
> even
> late in development" is simply untenable unless your customer has agreed
> to
> point 2 as I express it above.
>
> Graham
>
> For more information about AM, visit the Agile Modeling Home Page at
> www.agilemodeling.com
>
> For more information about AM, visit the Agile Modeling Home Page at
> www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Scott E. Preece]

It's important to distinguish between the Agile Alliance Principles and
the principles and practices of any specific methodology. The
Principles aren't a methodology, they're an abstraction of the
principles of a whole family of specific methodologies.

I would tend to advise organizations to start from a well-defined and
validated methodology rather than starting from scratch based on the
Principles, and to learn from the experience. The Principles could be
useful in evaluating proposed organization-specific adaptations of that
methodology, but I wouldn't advise anyone to trust them as sufficient
for such an evaluation.

The Principles might tell you "A process where all decisions are made by
the project manager is probably not agile", but they won't tell you
whether trading inspections for pair-programming will make you more
agile (or whether it will improve delivered quality or reduce cost).

scott


| From: Graham<***@virgin.net>
|
| It is worse than that Scott. Anybody promoting (in the loosest sense of that
| term) a methodology (in the loosest sense of that term) ought to start and
| finish by addressing the two questions the senior business mamager asks
|
| 1) how can I tell whether a project is applying this methodology or not?
| 2) how will I know a year from now whether my projects are more or less
| succesful as a result of following this methodology?
|
| If we start out (as some in this list seem to do) by denying there can be
| objective ways to distinguish an Agile project from a non-Agile one, then we
| do not deserve to be taken seriously by business managers.
|
| I am a fan of simplicity in a methodology, but not to the point of
| vacuousness. I am fan of clarity, but not to the point of SBOs (statements
| of the bleeding obvious). Above all I am a fan of stating where the
| methodology stops, what its limits are, what situations it does not handle
| so well, what the trade offs are. If the Agile manifesto gave more space to
| these things, it would be immediately more persuasive.
|
|
| ----------
| >From: "Scott E. Preece" <***@urbana.css.mot.com>
| >To: ***@topica.com
| >Subject: Re: [AM] Unfounded assertion
| >Date: Wed, Jan 28, 2004, 2:36 pm
| >
|
| >
| >| From: <***@aol.com>
| >|
| >| In a message dated 01/27/2004 2:46:29 PM Pacific Standard Time,
| >| ***@objectmonkey.com writes:
| >|
| >| > I would take the manifesto with a pinch of salt. They're hardly the Ten
| >| > Commandments or Principa Mathematica. They're just stories about how other
| >| > people managed to adapt quickly to change on software projects. I treat them
| >| > like diet books or exercise regimes.
| >|
| >| Jason:
| >|
| >| Like anything else, some people get it, and others don't. Those that need
| >| hard and fast rules will turn their noses up at the Manifesto, those
| >| that don't might get it.
| >|
| >| Someone or other once told me that there are three kinds of people in the
| >| world:
| >| 1. Those that make things happen.
| >| 2. Those that watch things happen.
| >| 3. Those that wonder what happened.
| >---
| >
| >I think the problem is that we're sitting here, in a community that
| >talks about various aspects of agile methods, and none of can point to
| >a set of rules for defining what "an agile method" is. The Principles
| >are generally good rules, but they're too vague to be a measuring stick
| >for saying "This process is agile, that one isn't," at least, not in the
| >sense that XP's 12 rules let you say "This project used XP, that one
| >didn't."
| >
| >I think that's completely understandable, given their origins - the
| >alliance is a loose alliance that shares certain values and principles,
| >but not ALL values, principles, or rules. It's probably not possible to
| >strictly define the space of agile methods; that is naturally going to
| >be frustrating to the natural human desire to have such a definition for
| >an area one is interested in.
| >
| >The Principles are a good starting point for testing a new approach - if
| >it seems well-aligned with the Principles it is likely to share at least
| >some of the advantages claimed for agile methods; if the new approach
| >doesn't fit well with some of the Principles, the author would be
| >well-advised to ask why and think about the implications.
| >
| >Note, however, that it's perfectly possible to be in line with all the
| >Principles and fail (there's nothing in there about limits,
| >interrelationships, pathologies, etc.), just as it's perfectly possible
| >for non-agile processes to succeed at delivering software.
| >
| >
| >scott
| >--
| >scott preece
| >motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
| >e-mail: ***@urbana.css.mot.com fax: [phone]
| >phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com
| >
| >For more information about AM, visit the Agile Modeling Home Page at
| >www.agilemodeling.com
| >
| >
| >
|
| For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
|
|


--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: [phone]
phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 01/28/2004 4:51:28 AM Pacific Standard Time,
***@virgin.net writes:


> People don't want hard and fast rules - they simply want advice, along with
> a good indiication of when that advice works well and when it doesn't.

Graham:

I would respectfully submit that many people do want hard and fast rules, or
at least descriptions that imply them, when encountering something new. This
holds true even when the "something new" is within their area of expertise or
experience. IMHO, the seemingly vague "mushy" and touchy-feely" descriptions of
agile modeling might be one factor that has been an impediment to wider
acceptance. I have been a proponent of the agile way since long before it became a
"movement", and the majority of responses I've encountered on the approach
have been much like your original post.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Paul Oldfield]

(responding to Scott P)

> I think the problem is that we're sitting here, in a community that
> talks about various aspects of agile methods, and none of can
> point to a set of rules for defining what "an agile method" is.
> The Principles are generally good rules, but they're too vague
> to be a measuring stick for saying "This process is agile, that
> one isn't," at least, not in the sense that XP's 12 rules let you say
> "This project used XP, that one didn't."

I go by a set of rules that say whether a method is appropriate
or not. They're good enough for me, and one would be
as agile as reasonably possible if the rules were applied.

I'm not sure it's possible to have a set of rules saying whether
a method is agile or not. 'Appropriate' has an intrinsic implication
of a relationship to where it is being applied. 'Agile' lacks
that connection, it is more a set of goals or requirements
than a solution that has been designed.

> I think that's completely understandable, given their origins - the
> alliance is a loose alliance that shares certain values and principles,
> but not ALL values, principles, or rules. It's probably not possible to
> strictly define the space of agile methods; that is naturally going to
> be frustrating to the natural human desire to have such a definition for
> an area one is interested in.

Again, I draw on the analogy of someone looking at a set of
requirements, and saying "That's no solution". Given the requirements,
we can strictly define whether a solution fits the requirements, but
first we need a solution to consider. Like all solutions, trying to
define it up front is not a good idea, because we don't know
enough, we need to observe the progress, learn the lessons,
adapt to the situation as we go. We can judge the agility by
the ability to adapt. In advance, what we can say is that some
solutions are likely to be more amenable to adaptation than
others. Hence XP and other methodologies that start with a
set of rules, with some process defined up front.

> The Principles are a good starting point for testing a new approach
> - if it seems well-aligned with the Principles it is likely to share at
least
> some of the advantages claimed for agile methods; if the new
> approach doesn't fit well with some of the Principles, the author would
> be well-advised to ask why and think about the implications.

Agreed. Yet do we need yet another 'new approach'? I agree
that each project should consider the most appropriate
starting point. I suppose one may say that each of these is a
'new approach', but it is tailored for a particular situation.

> Note, however, that it's perfectly possible to be in line with all the
> Principles and fail (there's nothing in there about limits,
> interrelationships, pathologies, etc.), just as it's perfectly possible
> for non-agile processes to succeed at delivering software.

Agreed. " A good process with poor people will fare worse than
a poor process with good people".

At least the agile values recognise that it's the quality of the people
that make the difference, far more than the process. People need
to know about 'process', rather than 'The Process'.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Graham]

Paul
That's a nice assembly
It is presented from the point of view that specific Agile techniques reduce
specific Risks.
I'm feeling the lack of something that defines the Risks created by the
Agile techniques.
Graham

What

>
>Ah! As usual, all advice needs to be tailored to situations. You
>might try looking at the stuff I've posted at
>www.aptprocess.com/whitepapers/risk/RiskToPatternTable.htm
>and let me know whether that sort of information is useful to you.
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Steven Gordon]

Agility is not a methodology. Scrum, XP, FSD, etc. are methodologies that claim to conform to the principles of agility.

So, to see if a project is applying an agile methodology, first ascertain the project's methodology, and then see if that particular methodology is meeting the principles of agility in the context of that project.

Again, I believe reading Boehm & Turner's "Balancing Agility and Discipline" will provide the perspective and framework you are looking for.

Steven Gordon

-----Original Message-----
From: Graham [mailto:***@virgin.net]
Sent: Wednesday, January 28, 2004 10:01 AM
To: ***@topica.com
Subject: Re: [AM] Unfounded assertion


It is worse than that Scott. Anybody promoting (in the loosest sense of that
term) a methodology (in the loosest sense of that term) ought to start and
finish by addressing the two questions the senior business mamager asks

1) how can I tell whether a project is applying this methodology or not?
2) how will I know a year from now whether my projects are more or less
succesful as a result of following this methodology?

If we start out (as some in this list seem to do) by denying there can be
objective ways to distinguish an Agile project from a non-Agile one, then we
do not deserve to be taken seriously by business managers.

I am a fan of simplicity in a methodology, but not to the point of
vacuousness. I am fan of clarity, but not to the point of SBOs (statements
of the bleeding obvious). Above all I am a fan of stating where the
methodology stops, what its limits are, what situations it does not handle
so well, what the trade offs are. If the Agile manifesto gave more space to
these things, it would be immediately more persuasive.


----------
>From: "Scott E. Preece" <***@urbana.css.mot.com>
>To: ***@topica.com
>Subject: Re: [AM] Unfounded assertion
>Date: Wed, Jan 28, 2004, 2:36 pm
>

>
>| From: <***@aol.com>
>|
>| In a message dated 01/27/2004 2:46:29 PM Pacific Standard Time,
>| ***@objectmonkey.com writes:
>|
>| > I would take the manifesto with a pinch of salt. They're hardly the Ten
>| > Commandments or Principa Mathematica. They're just stories about how other
>| > people managed to adapt quickly to change on software projects. I treat them
>| > like diet books or exercise regimes.
>|
>| Jason:
>|
>| Like anything else, some people get it, and others don't. Those that need
>| hard and fast rules will turn their noses up at the Manifesto, those
>| that don't might get it.
>|
>| Someone or other once told me that there are three kinds of people in the
>| world:
>| 1. Those that make things happen.
>| 2. Those that watch things happen.
>| 3. Those that wonder what happened.
>---
>
>I think the problem is that we're sitting here, in a community that
>talks about various aspects of agile methods, and none of can point to
>a set of rules for defining what "an agile method" is. The Principles
>are generally good rules, but they're too vague to be a measuring stick
>for saying "This process is agile, that one isn't," at least, not in the
>sense that XP's 12 rules let you say "This project used XP, that one
>didn't."
>
>I think that's completely understandable, given their origins - the
>alliance is a loose alliance that shares certain values and principles,
>but not ALL values, principles, or rules. It's probably not possible to
>strictly define the space of agile methods; that is naturally going to
>be frustrating to the natural human desire to have such a definition for
>an area one is interested in.
>
>The Principles are a good starting point for testing a new approach - if
>it seems well-aligned with the Principles it is likely to share at least
>some of the advantages claimed for agile methods; if the new approach
>doesn't fit well with some of the Principles, the author would be
>well-advised to ask why and think about the implications.
>
>Note, however, that it's perfectly possible to be in line with all the
>Principles and fail (there's nothing in there about limits,
>interrelationships, pathologies, etc.), just as it's perfectly possible
>for non-agile processes to succeed at delivering software.
>
>
>scott
>--
>scott preece
>motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
>e-mail: ***@urbana.css.mot.com fax: [phone]
>phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Graham]

That is by far the most useful advice I've had so far.
Now, I wonder if a consensus could form around which one to choose?

----------
>From: "Scott E. Preece" <***@urbana.css.mot.com>
>To: ***@topica.com
>Subject: Re: [AM] Unfounded assertion
>Date: Wed, Jan 28, 2004, 5:28 pm
>

>
>It's important to distinguish between the Agile Alliance Principles and
>the principles and practices of any specific methodology. The
>Principles aren't a methodology, they're an abstraction of the
>principles of a whole family of specific methodologies.
>
>I would tend to advise organizations to start from a well-defined and
>validated methodology rather than starting from scratch based on the
>Principles, and to learn from the experience. The Principles could be
>useful in evaluating proposed organization-specific adaptations of that
>methodology, but I wouldn't advise anyone to trust them as sufficient
>for such an evaluation.
>
>The Principles might tell you "A process where all decisions are made by
>the project manager is probably not agile", but they won't tell you
>whether trading inspections for pair-programming will make you more
>agile (or whether it will improve delivered quality or reduce cost).
>
>scott
>
>
>| From: Graham<***@virgin.net>
>|
>| It is worse than that Scott. Anybody promoting (in the loosest sense of that
>| term) a methodology (in the loosest sense of that term) ought to start and
>| finish by addressing the two questions the senior business mamager asks
>|
>| 1) how can I tell whether a project is applying this methodology or not?
>| 2) how will I know a year from now whether my projects are more or less
>| succesful as a result of following this methodology?
>|
>| If we start out (as some in this list seem to do) by denying there can be
>| objective ways to distinguish an Agile project from a non-Agile one, then we
>| do not deserve to be taken seriously by business managers.
>|
>| I am a fan of simplicity in a methodology, but not to the point of
>| vacuousness. I am fan of clarity, but not to the point of SBOs (statements
>| of the bleeding obvious). Above all I am a fan of stating where the
>| methodology stops, what its limits are, what situations it does not handle
>| so well, what the trade offs are. If the Agile manifesto gave more space to
>| these things, it would be immediately more persuasive.
>|
>|
>| ----------
>| >From: "Scott E. Preece" <***@urbana.css.mot.com>
>| >To: ***@topica.com
>| >Subject: Re: [AM] Unfounded assertion
>| >Date: Wed, Jan 28, 2004, 2:36 pm
>| >
>|
>| >
>| >| From: <***@aol.com>
>| >|
>| >| In a message dated 01/27/2004 2:46:29 PM Pacific Standard Time,
>| >| ***@objectmonkey.com writes:
>| >|
>| >| > I would take the manifesto with a pinch of salt. They're hardly the Ten
>| >| > Commandments or Principa Mathematica. They're just stories about how other
>| >| > people managed to adapt quickly to change on software projects. I treat them
>| >| > like diet books or exercise regimes.
>| >|
>| >| Jason:
>| >|
>| >| Like anything else, some people get it, and others don't. Those that need
>| >| hard and fast rules will turn their noses up at the Manifesto, those
>| >| that don't might get it.
>| >|
>| >| Someone or other once told me that there are three kinds of people in the
>| >| world:
>| >| 1. Those that make things happen.
>| >| 2. Those that watch things happen.
>| >| 3. Those that wonder what happened.
>| >---
>| >
>| >I think the problem is that we're sitting here, in a community that
>| >talks about various aspects of agile methods, and none of can point to
>| >a set of rules for defining what "an agile method" is. The Principles
>| >are generally good rules, but they're too vague to be a measuring stick
>| >for saying "This process is agile, that one isn't," at least, not in the
>| >sense that XP's 12 rules let you say "This project used XP, that one
>| >didn't."
>| >
>| >I think that's completely understandable, given their origins - the
>| >alliance is a loose alliance that shares certain values and principles,
>| >but not ALL values, principles, or rules. It's probably not possible to
>| >strictly define the space of agile methods; that is naturally going to
>| >be frustrating to the natural human desire to have such a definition for
>| >an area one is interested in.
>| >
>| >The Principles are a good starting point for testing a new approach - if
>| >it seems well-aligned with the Principles it is likely to share at least
>| >some of the advantages claimed for agile methods; if the new approach
>| >doesn't fit well with some of the Principles, the author would be
>| >well-advised to ask why and think about the implications.
>| >
>| >Note, however, that it's perfectly possible to be in line with all the
>| >Principles and fail (there's nothing in there about limits,
>| >interrelationships, pathologies, etc.), just as it's perfectly possible
>| >for non-agile processes to succeed at delivering software.
>| >
>| >
>| >scott
>| >--
>| >scott preece
>| >motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
>| >e-mail: ***@urbana.css.mot.com fax: [phone]
>| >phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com
>| >
>| >For more information about AM, visit the Agile Modeling Home Page at
>| >www.agilemodeling.com
>| >
>| >
>| >
>|
>| For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>|
>|
>
>
>--
>scott preece
>motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
>e-mail: ***@urbana.css.mot.com fax: [phone]
>phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Steven Gordon]

What is the first question you ask somebody when he wants to know which programming language to choose?

Hint: it is probably the same question we would ask when asked which agile methodology to use.

-----Original Message-----
From: Graham [mailto:***@virgin.net]
Sent: Wednesday, January 28, 2004 2:15 PM
To: ***@topica.com
Subject: Re: [AM] Unfounded assertion


That is by far the most useful advice I've had so far.
Now, I wonder if a consensus could form around which one to choose?

----------
>From: "Scott E. Preece" <***@urbana.css.mot.com>
>To: ***@topica.com
>Subject: Re: [AM] Unfounded assertion
>Date: Wed, Jan 28, 2004, 5:28 pm
>

>
>It's important to distinguish between the Agile Alliance Principles and
>the principles and practices of any specific methodology. The
>Principles aren't a methodology, they're an abstraction of the
>principles of a whole family of specific methodologies.
>
>I would tend to advise organizations to start from a well-defined and
>validated methodology rather than starting from scratch based on the
>Principles, and to learn from the experience. The Principles could be
>useful in evaluating proposed organization-specific adaptations of that
>methodology, but I wouldn't advise anyone to trust them as sufficient
>for such an evaluation.
>
>The Principles might tell you "A process where all decisions are made by
>the project manager is probably not agile", but they won't tell you
>whether trading inspections for pair-programming will make you more
>agile (or whether it will improve delivered quality or reduce cost).
>
>scott
>
>
>| From: Graham<***@virgin.net>
>|
>| It is worse than that Scott. Anybody promoting (in the loosest sense of that
>| term) a methodology (in the loosest sense of that term) ought to start and
>| finish by addressing the two questions the senior business mamager asks
>|
>| 1) how can I tell whether a project is applying this methodology or not?
>| 2) how will I know a year from now whether my projects are more or less
>| succesful as a result of following this methodology?
>|
>| If we start out (as some in this list seem to do) by denying there can be
>| objective ways to distinguish an Agile project from a non-Agile one, then we
>| do not deserve to be taken seriously by business managers.
>|
>| I am a fan of simplicity in a methodology, but not to the point of
>| vacuousness. I am fan of clarity, but not to the point of SBOs (statements
>| of the bleeding obvious). Above all I am a fan of stating where the
>| methodology stops, what its limits are, what situations it does not handle
>| so well, what the trade offs are. If the Agile manifesto gave more space to
>| these things, it would be immediately more persuasive.
>|
>|
>| ----------
>| >From: "Scott E. Preece" <***@urbana.css.mot.com>
>| >To: ***@topica.com
>| >Subject: Re: [AM] Unfounded assertion
>| >Date: Wed, Jan 28, 2004, 2:36 pm
>| >
>|
>| >
>| >| From: <***@aol.com>
>| >|
>| >| In a message dated 01/27/2004 2:46:29 PM Pacific Standard Time,
>| >| ***@objectmonkey.com writes:
>| >|
>| >| > I would take the manifesto with a pinch of salt. They're hardly the Ten
>| >| > Commandments or Principa Mathematica. They're just stories about how other
>| >| > people managed to adapt quickly to change on software projects. I treat them
>| >| > like diet books or exercise regimes.
>| >|
>| >| Jason:
>| >|
>| >| Like anything else, some people get it, and others don't. Those that need
>| >| hard and fast rules will turn their noses up at the Manifesto, those
>| >| that don't might get it.
>| >|
>| >| Someone or other once told me that there are three kinds of people in the
>| >| world:
>| >| 1. Those that make things happen.
>| >| 2. Those that watch things happen.
>| >| 3. Those that wonder what happened.
>| >---
>| >
>| >I think the problem is that we're sitting here, in a community that
>| >talks about various aspects of agile methods, and none of can point to
>| >a set of rules for defining what "an agile method" is. The Principles
>| >are generally good rules, but they're too vague to be a measuring stick
>| >for saying "This process is agile, that one isn't," at least, not in the
>| >sense that XP's 12 rules let you say "This project used XP, that one
>| >didn't."
>| >
>| >I think that's completely understandable, given their origins - the
>| >alliance is a loose alliance that shares certain values and principles,
>| >but not ALL values, principles, or rules. It's probably not possible to
>| >strictly define the space of agile methods; that is naturally going to
>| >be frustrating to the natural human desire to have such a definition for
>| >an area one is interested in.
>| >
>| >The Principles are a good starting point for testing a new approach - if
>| >it seems well-aligned with the Principles it is likely to share at least
>| >some of the advantages claimed for agile methods; if the new approach
>| >doesn't fit well with some of the Principles, the author would be
>| >well-advised to ask why and think about the implications.
>| >
>| >Note, however, that it's perfectly possible to be in line with all the
>| >Principles and fail (there's nothing in there about limits,
>| >interrelationships, pathologies, etc.), just as it's perfectly possible
>| >for non-agile processes to succeed at delivering software.
>| >
>| >
>| >scott
>| >--
>| >scott preece
>| >motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
>| >e-mail: ***@urbana.css.mot.com fax: [phone]
>| >phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com
>| >
>| >For more information about AM, visit the Agile Modeling Home Page at
>| >www.agilemodeling.com
>| >
>| >
>| >
>|
>| For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>|
>|
>
>
>--
>scott preece
>motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
>e-mail: ***@urbana.css.mot.com fax: [phone]
>phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Graham]

You cannot cop out of answering such awkward questions when you are running
a business. You are indeed faced with exactly the same decision about
programming languages. I believe last year's answer was 50% Java, 50% C
sharp. Now, what would you recommend wrt Agile methods?




----------
>From: Steven Gordon <***@asu.edu>
>To: ***@topica.com
>Subject: RE: [AM] Unfounded assertion
>Date: Wed, Jan 28, 2004, 9:43 pm
>

>What is the first question you ask somebody when he wants to know which
>programming language to choose?
>
>Hint: it is probably the same question we would ask when asked which agile
>methodology to use.
>
>-----Original Message-----
>From: Graham [mailto:***@virgin.net]
>Sent: Wednesday, January 28, 2004 2:15 PM
>To: ***@topica.com
>Subject: Re: [AM] Unfounded assertion
>
>
>That is by far the most useful advice I've had so far.
>Now, I wonder if a consensus could form around which one to choose?
>
>----------
>>From: "Scott E. Preece" <***@urbana.css.mot.com>
>>To: ***@topica.com
>>Subject: Re: [AM] Unfounded assertion
>>Date: Wed, Jan 28, 2004, 5:28 pm
>>
>
>>
>>It's important to distinguish between the Agile Alliance Principles and
>>the principles and practices of any specific methodology. The
>>Principles aren't a methodology, they're an abstraction of the
>>principles of a whole family of specific methodologies.
>>
>>I would tend to advise organizations to start from a well-defined and
>>validated methodology rather than starting from scratch based on the
>>Principles, and to learn from the experience. The Principles could be
>>useful in evaluating proposed organization-specific adaptations of that
>>methodology, but I wouldn't advise anyone to trust them as sufficient
>>for such an evaluation.
>>
>>The Principles might tell you "A process where all decisions are made by
>>the project manager is probably not agile", but they won't tell you
>>whether trading inspections for pair-programming will make you more
>>agile (or whether it will improve delivered quality or reduce cost).
>>
>>scott
>>
>>
>>| From: Graham<***@virgin.net>
>>|
>>| It is worse than that Scott. Anybody promoting (in the loosest sense of that
>>| term) a methodology (in the loosest sense of that term) ought to start and
>>| finish by addressing the two questions the senior business mamager asks
>>|
>>| 1) how can I tell whether a project is applying this methodology or not?
>>| 2) how will I know a year from now whether my projects are more or less
>>| succesful as a result of following this methodology?
>>|
>>| If we start out (as some in this list seem to do) by denying there can be
>>| objective ways to distinguish an Agile project from a non-Agile one, then we
>>| do not deserve to be taken seriously by business managers.
>>|
>>| I am a fan of simplicity in a methodology, but not to the point of
>>| vacuousness. I am fan of clarity, but not to the point of SBOs (statements
>>| of the bleeding obvious). Above all I am a fan of stating where the
>>| methodology stops, what its limits are, what situations it does not handle
>>| so well, what the trade offs are. If the Agile manifesto gave more space to
>>| these things, it would be immediately more persuasive.
>>|
>>|
>>| ----------
>>| >From: "Scott E. Preece" <***@urbana.css.mot.com>
>>| >To: ***@topica.com
>>| >Subject: Re: [AM] Unfounded assertion
>>| >Date: Wed, Jan 28, 2004, 2:36 pm
>>| >
>>|
>>| >
>>| >| From: <***@aol.com>
>>| >|
>>| >| In a message dated 01/27/2004 2:46:29 PM Pacific Standard Time,
>>| >| ***@objectmonkey.com writes:
>>| >|
>>| >| > I would take the manifesto with a pinch of salt. They're hardly the Ten
>>| >| > Commandments or Principa Mathematica. They're just stories about how other
>>| >| > people managed to adapt quickly to change on software projects. I
>treat them
>>| >| > like diet books or exercise regimes.
>>| >|
>>| >| Jason:
>>| >|
>>| >| Like anything else, some people get it, and others don't. Those that need
>>| >| hard and fast rules will turn their noses up at the Manifesto, those
>>| >| that don't might get it.
>>| >|
>>| >| Someone or other once told me that there are three kinds of people in the
>>| >| world:
>>| >| 1. Those that make things happen.
>>| >| 2. Those that watch things happen.
>>| >| 3. Those that wonder what happened.
>>| >---
>>| >
>>| >I think the problem is that we're sitting here, in a community that
>>| >talks about various aspects of agile methods, and none of can point to
>>| >a set of rules for defining what "an agile method" is. The Principles
>>| >are generally good rules, but they're too vague to be a measuring stick
>>| >for saying "This process is agile, that one isn't," at least, not in the
>>| >sense that XP's 12 rules let you say "This project used XP, that one
>>| >didn't."
>>| >
>>| >I think that's completely understandable, given their origins - the
>>| >alliance is a loose alliance that shares certain values and principles,
>>| >but not ALL values, principles, or rules. It's probably not possible to
>>| >strictly define the space of agile methods; that is naturally going to
>>| >be frustrating to the natural human desire to have such a definition for
>>| >an area one is interested in.
>>| >
>>| >The Principles are a good starting point for testing a new approach - if
>>| >it seems well-aligned with the Principles it is likely to share at least
>>| >some of the advantages claimed for agile methods; if the new approach
>>| >doesn't fit well with some of the Principles, the author would be
>>| >well-advised to ask why and think about the implications.
>>| >
>>| >Note, however, that it's perfectly possible to be in line with all the
>>| >Principles and fail (there's nothing in there about limits,
>>| >interrelationships, pathologies, etc.), just as it's perfectly possible
>>| >for non-agile processes to succeed at delivering software.
>>| >
>>| >
>>| >scott
>>| >--
>>| >scott preece
>>| >motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
>>| >e-mail: ***@urbana.css.mot.com fax: [phone]
>>| >phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com
>>| >
>>| >For more information about AM, visit the Agile Modeling Home Page at
>>| >www.agilemodeling.com
>>| >
>>| >
>>| >
>>|
>>| For more information about AM, visit the Agile Modeling Home Page at
>>www.agilemodeling.com
>>|
>>|
>>
>>
>>--
>>scott preece
>>motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
>>e-mail: ***@urbana.css.mot.com fax: [phone]
>>phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com
>>
>>For more information about AM, visit the Agile Modeling Home Page at
>>www.agilemodeling.com
>>
>>
>>
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Scott Ambler]

Like it or not, the job of management is to make decisions which aren't
always clear cut, based on imprecise information.

The recommendation would be to educate yourself as best as possible,
identify several good candidates, and pick the one(s) that appear best for
you. And you need to accept that you might get it wrong.

- Scott


At 10:02 PM 1/28/2004 +0000, you wrote:
>You cannot cop out of answering such awkward questions when you are running
>a business. You are indeed faced with exactly the same decision about
>programming languages. I believe last year's answer was 50% Java, 50% C
>sharp. Now, what would you recommend wrt Agile methods?
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Steven Gordon]

You would actually recommend doing a project in a mixture of 50% Java and 50% C++ without asking what the application was, who was developing it, what their time frame was, and what their intended market was?

-----Original Message-----
From: Graham [mailto:***@virgin.net]
Sent: Wednesday, January 28, 2004 3:02 PM
To: ***@topica.com
Subject: Re: [AM] Unfounded assertion


You cannot cop out of answering such awkward questions when you are running
a business. You are indeed faced with exactly the same decision about
programming languages. I believe last year's answer was 50% Java, 50% C
sharp. Now, what would you recommend wrt Agile methods?




----------
>From: Steven Gordon <***@asu.edu>
>To: ***@topica.com
>Subject: RE: [AM] Unfounded assertion
>Date: Wed, Jan 28, 2004, 9:43 pm
>

>What is the first question you ask somebody when he wants to know which
>programming language to choose?
>
>Hint: it is probably the same question we would ask when asked which agile
>methodology to use.
>
>-----Original Message-----
>From: Graham [mailto:***@virgin.net]
>Sent: Wednesday, January 28, 2004 2:15 PM
>To: ***@topica.com
>Subject: Re: [AM] Unfounded assertion
>
>
>That is by far the most useful advice I've had so far.
>Now, I wonder if a consensus could form around which one to choose?
>
>----------
>>From: "Scott E. Preece" <***@urbana.css.mot.com>
>>To: ***@topica.com
>>Subject: Re: [AM] Unfounded assertion
>>Date: Wed, Jan 28, 2004, 5:28 pm
>>
>
>>
>>It's important to distinguish between the Agile Alliance Principles and
>>the principles and practices of any specific methodology. The
>>Principles aren't a methodology, they're an abstraction of the
>>principles of a whole family of specific methodologies.
>>
>>I would tend to advise organizations to start from a well-defined and
>>validated methodology rather than starting from scratch based on the
>>Principles, and to learn from the experience. The Principles could be
>>useful in evaluating proposed organization-specific adaptations of that
>>methodology, but I wouldn't advise anyone to trust them as sufficient
>>for such an evaluation.
>>
>>The Principles might tell you "A process where all decisions are made by
>>the project manager is probably not agile", but they won't tell you
>>whether trading inspections for pair-programming will make you more
>>agile (or whether it will improve delivered quality or reduce cost).
>>
>>scott
>>
>>
>>| From: Graham<***@virgin.net>
>>|
>>| It is worse than that Scott. Anybody promoting (in the loosest sense of that
>>| term) a methodology (in the loosest sense of that term) ought to start and
>>| finish by addressing the two questions the senior business mamager asks
>>|
>>| 1) how can I tell whether a project is applying this methodology or not?
>>| 2) how will I know a year from now whether my projects are more or less
>>| succesful as a result of following this methodology?
>>|
>>| If we start out (as some in this list seem to do) by denying there can be
>>| objective ways to distinguish an Agile project from a non-Agile one, then we
>>| do not deserve to be taken seriously by business managers.
>>|
>>| I am a fan of simplicity in a methodology, but not to the point of
>>| vacuousness. I am fan of clarity, but not to the point of SBOs (statements
>>| of the bleeding obvious). Above all I am a fan of stating where the
>>| methodology stops, what its limits are, what situations it does not handle
>>| so well, what the trade offs are. If the Agile manifesto gave more space to
>>| these things, it would be immediately more persuasive.
>>|
>>|
>>| ----------
>>| >From: "Scott E. Preece" <***@urbana.css.mot.com>
>>| >To: ***@topica.com
>>| >Subject: Re: [AM] Unfounded assertion
>>| >Date: Wed, Jan 28, 2004, 2:36 pm
>>| >
>>|
>>| >
>>| >| From: <***@aol.com>
>>| >|
>>| >| In a message dated 01/27/2004 2:46:29 PM Pacific Standard Time,
>>| >| ***@objectmonkey.com writes:
>>| >|
>>| >| > I would take the manifesto with a pinch of salt. They're hardly the Ten
>>| >| > Commandments or Principa Mathematica. They're just stories about how other
>>| >| > people managed to adapt quickly to change on software projects. I
>treat them
>>| >| > like diet books or exercise regimes.
>>| >|
>>| >| Jason:
>>| >|
>>| >| Like anything else, some people get it, and others don't. Those that need
>>| >| hard and fast rules will turn their noses up at the Manifesto, those
>>| >| that don't might get it.
>>| >|
>>| >| Someone or other once told me that there are three kinds of people in the
>>| >| world:
>>| >| 1. Those that make things happen.
>>| >| 2. Those that watch things happen.
>>| >| 3. Those that wonder what happened.
>>| >---
>>| >
>>| >I think the problem is that we're sitting here, in a community that
>>| >talks about various aspects of agile methods, and none of can point to
>>| >a set of rules for defining what "an agile method" is. The Principles
>>| >are generally good rules, but they're too vague to be a measuring stick
>>| >for saying "This process is agile, that one isn't," at least, not in the
>>| >sense that XP's 12 rules let you say "This project used XP, that one
>>| >didn't."
>>| >
>>| >I think that's completely understandable, given their origins - the
>>| >alliance is a loose alliance that shares certain values and principles,
>>| >but not ALL values, principles, or rules. It's probably not possible to
>>| >strictly define the space of agile methods; that is naturally going to
>>| >be frustrating to the natural human desire to have such a definition for
>>| >an area one is interested in.
>>| >
>>| >The Principles are a good starting point for testing a new approach - if
>>| >it seems well-aligned with the Principles it is likely to share at least
>>| >some of the advantages claimed for agile methods; if the new approach
>>| >doesn't fit well with some of the Principles, the author would be
>>| >well-advised to ask why and think about the implications.
>>| >
>>| >Note, however, that it's perfectly possible to be in line with all the
>>| >Principles and fail (there's nothing in there about limits,
>>| >interrelationships, pathologies, etc.), just as it's perfectly possible
>>| >for non-agile processes to succeed at delivering software.
>>| >
>>| >
>>| >scott
>>| >--
>>| >scott preece
>>| >motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
>>| >e-mail: ***@urbana.css.mot.com fax: [phone]
>>| >phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com
>>| >
>>| >For more information about AM, visit the Agile Modeling Home Page at
>>| >www.agilemodeling.com
>>| >
>>| >
>>| >
>>|
>>| For more information about AM, visit the Agile Modeling Home Page at
>>www.agilemodeling.com
>>|
>>|
>>
>>
>>--
>>scott preece
>>motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
>>e-mail: ***@urbana.css.mot.com fax: [phone]
>>phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com
>>
>>For more information about AM, visit the Agile Modeling Home Page at
>>www.agilemodeling.com
>>
>>
>>
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Graham]

Scott,
I know what I'd recommend already. I am asking for others' recommendations.
Graham


----------
>From: Scott Ambler <***@ronin-intl.com>
>To: ***@topica.com
>Subject: Re: [AM] Unfounded assertion
>Date: Wed, Jan 28, 2004, 10:19 pm
>

>Like it or not, the job of management is to make decisions which aren't
>always clear cut, based on imprecise information.
>
>The recommendation would be to educate yourself as best as possible,
>identify several good candidates, and pick the one(s) that appear best for
>you. And you need to accept that you might get it wrong.
>
>- Scott
>
>
>At 10:02 PM 1/28/2004 +0000, you wrote:
>>You cannot cop out of answering such awkward questions when you are running
>>a business. You are indeed faced with exactly the same decision about
>>programming languages. I believe last year's answer was 50% Java, 50% C
>>sharp. Now, what would you recommend wrt Agile methods?
>>
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Paul Oldfield]

(responding to Graham)

>
>> Ah! As usual, all advice needs to be tailored to situations. You
>> might try looking at the stuff I've posted at
>> www.aptprocess.com/whitepapers/risk/RiskToPatternTable.htm
>> and let me know whether that sort of information is useful to you.
>
> (Graham)
> That's a nice assembly. It is presented from the point of view that
> specific Agile techniques reduce specific Risks.

I also include 'Traditional' techniques; they may often be of use.

> I'm feeling the lack of something that defines the Risks created by
> the Agile techniques.

Several of the techniques have specific "Contra-Indications"
sections, particularly prevalent on the more 'Agile' techniques.
I'm also trying to tie the ideas together to give more prescriptive
guidelines as to how one may work toward achieving an
appropriate process, that is "work in progress" for now.
I'm always interested in feedback, if you think there ought to
be specific extra 'contra-indications'. These will be
evaluated, and added to the next update cycle if they have
merit. It's probably not acceptable to discuss site-specific
topics on this forum, but I'm sure any relevant issues with the
ideas therein would be acceptable topics for discussion here.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Paul Oldfield]

(responding to Graham)

> That is by far the most useful advice I've had so far.
> Now, I wonder if a consensus could form around which
> one to choose?

Choose the one most appropriate to the situation.

At some point, you must decide whether you want a predefined
process or an agile process.

May I suggest that if you want a predefined process that is as
flexible as you can make it, you should consider RUP?

There are other balance points on the spectrum from
rigidly predefined to ultimately mutable. However, all
agile approaches tend toward the mutable end of the
spectrum. If you want your process predefined, you are
in effect saying you don't want an agile process.

If your message that you're trying to get across is that
our agile processes are too agile for your liking, then
go for something less agile.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Scott E. Preece]

I couldn't comment on whether Jason was being serious, facetious, or
sarcastic in comparing Agile to fad diets. However, that said, it would
still be wise to carry a certain degree of caveat emptor into deciding
whether to convert from process-based to agile methods.

(1) we may be doing a disservice by creating a notion of "agile methods"
as opposed to always referring to individual methods; there's no
guarantee that two methodologies share the same applicability or
potential just because they fall under the broad umbrella of "agile
methods"

(2) this discussion has been larded with comments about agile meaning
teams have the freedom to do the right thing; there's been less mention
of the direct corollary that they are also free to do the wrong thing;
it may be difficult for a client to tell whether the pitch is coming
from capable agile methodologists or code cowboys

(3) though I don't have references to share, I have heard from
colleagues that some of the early success stories were, in fact, less
successful that usually described and viewed afterwards by the client
failures; many of the articles in the anecdotal evidence files end up
saying that the client didn't continue using the practices (usually
attributed to organizational factors, but a sign that success wasn't
so obvious that it couldn't be denied)

(4) a lot of the rhetoric is couched as "agile vs process", but there is
nothing in the Agile Alliance Principles that couldn't be part of a
high-maturity defined process.

(5) a number of the Principles boldly state completely unproved
assertions; I have no problem with that in the context of taking them as
principles (statements of belief), but potential clients do need to be
consider whether the methodologits' belief is enough to go on.

I should say that I wholeheartedly agree with about 90% of what the
Principles say (the exceptions: "face-to-face conversation" is an
important part of communication, but it is rarely sufficient for
conveying technical information; and I know of NO justification for a
claim that "the best architectures..." emerge from self-organizing
team).

I have said to some other people that I believe XP, in particular, is
a highly conservative approach to software development. It is strongly
structured and focused on never taking on more than one-iteration's
worth of risk. My only real complaint with it is that it emphasizes
YAGNI while not making it clear that the team really does have a
continuing sense of the expected end-point of the project - not just for
the current iteration.

scott


| From: Jonathan Kern<***@comcast.net>
|
| Uhhh.
|
| Are you saying the Agile Manifesto principles are equivalent one-off,
| random, questionable statistical evidence as implied by your leather and
| running regimen "fad" example?
|
| Uhhh.
|
| -- jon
|
| > -----Original Message-----
| > From: Jason Gorman [mailto:***@objectmonkey.com]
| > Sent: Tuesday, January 27, 2004 1:23 PM
| > To: ***@topica.com
| > Subject: RE: [AM] Unfounded assertion
| >
| >
| > I would take the manifesto with a pinch of salt. They're hardly the Ten
| > Commandments or Principa Mathematica. They're just stories about how other
| > people managed to adapt quickly to change on software projects. I
| > treat them
| > like diet books or exercise regimes. Some minor celeb loses 20 lbs eating
| > nothing but leather and running up and down stairs with a cat on
| > their head,
| > and everybody says "you look great! What's your secret?" and
| > before you know
| > it they've got a book and a video out telling everybody "this is
| > how to lose
| > 20lbs"... XP is the Atkins Diet of software development methods. It worked
| > for Jennifer Aniston, but I hear Geri Halliwell's not too keen.
| >
| > Jason Gorman
| > http://www.objectmonkey.com
| >
| > -----Original Message-----
| > From: Graham [mailto:***@virgin.net]
| > Sent: 27 January 2004 17:02
| > To: ***@topica.com
| > Subject: [AM] Unfounded assertion
| >
| > "I mentioned to Graham several times that he should invest the
| > time to read
| > the values and principles at www.agilealliance.org, but he chose
| > not to. I
| > eventually posted the material to the DM discussion list, but the only
| > responses were to mock the concepts. Oh well."
| > ----------------------------------------------
| > Scott
| >
| > Please discontinue making unfounded assertions and implying I have done no
| > research into Agile methods. As to whether I am misinterpreting Agile...
| >
| > I long ago read the Agile manifesto, and indeed include it in
| > presentations
| > on Agile methods. I have gathered feedback from DSDM projects and
| > interviewed people from a team applying Extreme Programming in
| > close to its
| > pure form. (You think coding the unit test first is not a painful
| > discipline? You think everybody enjoys pair programming?)
| >
| > The agile values are mushy. The agile principles are more helpful, and you
| > ought to have noticed that I drew on them to formulate my list of 8 points
| > ------------------------------------------
| > 1 ensure sponsors and customers are commited to all of the following
| > principles
| >
| > 2 be flexibile about requirements and time or cash box your delivery
| > ³Welcome changing requirements, even late in development. Agile processes
| > harness change for the customer's competitive advantage.²
| >
| > 3 maintain continuous and close user involvement ³Business people and
| > developers must work together daily throughout the project.²
| >
| > 4 empower a small team (including users) to get on with it ³Build projects
| > around motivated individuals. Give them the environment and support they
| > need, and trust them to get the job done.²
| >
| > 5 focus on program code and tests rather than on specifications ³Working
| > software is the primary measure of progress.
| > The most efficient and effective method of conveying information to and
| > within a development team is face-to-face conversation.²
| >
| > 6 develop iteratively, driven by priorities ³Our highest priority is to
| > satisfy the customer through early and continuous delivery of valuable
| > software.
| > Deliver working software frequently, from a couple of weeks to a couple of
| > months, with a preference to the shorter timescale.²
| >
| > 7 iteratively refactor program structures and data structures built so far
| >
| > 8 use prototypes to tackle tricky design issues early
| > ------------------------------------------
| > I added one point at the beginning, which Agilists overlook at
| > their peril.
| >
| > I added two points at the end: 7 in deference to Martin Fowler
| > and yourself,
| > and 8 in deference to DSDM and UP/RUP.
| >
| > I left out principles at the bottom of the Agile list partly because they
| > did not seem to me so definitive, and partly to be more concise.
| > "Agile processes promote sustainable development. The sponsors,
| > developers,
| > and users should be able to maintain a constant pace indefinitely.
| > Continuous attention to technical excellence and good design enhances
| > agility.
| > Simplicity--the art of maximizing the amount of work not done--is
| > essential.
| > The best architectures, requirements, and designs emerge from
| > self-organizing teams.
| > At regular intervals, the team reflects on how to become more effective,
| > then tunes and adjusts its behavior accordingly."
| >
| > I won't explain all my rewordings, but ³Welcome changing
| > requirements, even
| > late in development" is simply untenable unless your customer has
| > agreed to
| > point 2 as I express it above.
| >
| > Graham
| >
| > For more information about AM, visit the Agile Modeling Home Page at
| > www.agilemodeling.com
| >
| > For more information about AM, visit the Agile Modeling Home Page
| > at www.agilemodeling.com
| >
| >
|
| For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
|
|
|
|

--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: [phone]
phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Patrick James Nelis]

This particular thread reminds me of the old problem of whether it
is better to centralize or decentralize IT. The only answer is
that, “It depends.” No two situations are identical, and the
approach must consider all the factors. But the arguments
continue, and the tide shifts back and forth, with some companies
decentralizing, while others, with a similar corporate structure,
centralize.

The issue of formal waterfall methodologies, versus more agile
approaches, also shifts back and forth. In the early days of
modern computers, coders were much more independent. Cowboys were
the norm. There were some formal guidelines and methodologies,
but generally the atmosphere was very loose. The cowboys crashed
many systems, but you could recover more easily in a batch
environment.

IMO the formal waterfall methodologies were a response to the
legal rulings in the 70’s and 80’s, when large development shops
were sued for not delivering on time and within budget. When
methodologies were less stringent, most bidders won the contract,
and made up any shortfall with the inevitable change requests, as
the clients began to define processes more precisely. Somewhere
in the 70’s, clients objected to this approach, and began to sue.
Enter the detailed formal methodologies. No one liked the rigid
step-by-step processes. Many organizations adopted the "one
methodology fits all" approach. The waterfall methodologies
really stifled initiative. But they were a safer approach. One
could set up a schedule of the waterfall steps, and predict an end
date. The organizations that wrote the multi-volume methodologies
were getting up to $100,000 for the books, and making a killing
selling training. Auditors also loved them, and shoved them down
the throats of many IT organizations.

By the late 80’s, the pendulum had swung so far to one side that
even very small projects were obliged to use the bloated
techniques. I observed a small organization in the West trying to
follow one of the waterfall approaches. Six weeks into the
project, there were two large (3”) binders full of specifications
that the user could not comprehend, but no code had been written.
The VP sat with a neighbor over one weekend, and coded the
application on a MAC. By Monday morning, his secretary was
entering data and getting meaningful results. Clearly, the
“agile” approach over the weekend was the more appropriate
methodology. But corporate policy dictated the formal waterfall
method. Even the CASE tools of the 80’s and early 90’s had little
impact on the problem.

The new programming platforms and techniques are orders of
magnitude more powerful than the tools available a decade or two
ago. But it is difficult for managers to let persons charge ahead
without some checkpoints along the way. I recently sat in a cube
next to a young gent who managed the content for a large web site.
He made a change to a basic routine, and the tests were not going
well. The language took me back to earlier days on the deck force
of a destroyer. Finally, there was a whoop of joy, as a test
passed. On the strength of that test, he decided to install the
new routine. He regretted that as they marched him out the door,
next day. There are still cowboys around who want to do things
their own way, and we need a methodology to prevent them from
creating disasters.

As you pointed out, IF USED PROPERLY, the Agile method is a very
good technique for avoiding risk, which seems to be at the heart
of this whole controversy. I particularly liked the suggestion
someone made, that one could build a series of iterative steps
into an MS Project chart, to create some semblance of a
predictable schedule. Perhaps that approach will encourage
clients to experiment with Agile techniques, and start the
pendulum back toward a more sane mix of development methodologies.
Then perhaps we can choose the approach that best fits, depending
on the situation.

Pat Nelis

-----Original Message-----
From: Scott E. Preece [mailto:***@urbana.css.mot.com]
Sent: Thursday, January 29, 2004 9:52 AM
To: ***@topica.com
Subject: Re: [AM] Unfounded assertion



I couldn't comment on whether Jason was being serious, facetious,
or sarcastic in comparing Agile to fad diets. However, that said,
it would still be wise to carry a certain degree of caveat emptor
into deciding whether to convert from process-based to agile
methods.

(1) we may be doing a disservice by creating a notion of "agile
methods" as opposed to always referring to individual methods;
there's no guarantee that two methodologies share the same
applicability or potential just because they fall under the broad
umbrella of "agile methods"

(2) this discussion has been larded with comments about agile
meaning teams have the freedom to do the right thing; there's been
less mention of the direct corollary that they are also free to do
the wrong thing; it may be difficult for a client to tell whether
the pitch is coming from capable agile methodologists or code
cowboys

(3) though I don't have references to share, I have heard from
colleagues that some of the early success stories were, in fact,
less successful that usually described and viewed afterwards by
the client failures; many of the articles in the anecdotal
evidence files end up saying that the client didn't continue using
the practices (usually attributed to organizational factors, but a
sign that success wasn't so obvious that it couldn't be denied)

(4) a lot of the rhetoric is couched as "agile vs process", but
there is nothing in the Agile Alliance Principles that couldn't be
part of a high-maturity defined process.

(5) a number of the Principles boldly state completely unproved
assertions; I have no problem with that in the context of taking
them as principles (statements of belief), but potential clients
do need to be consider whether the methodologits' belief is enough
to go on.

I should say that I wholeheartedly agree with about 90% of what
the Principles say (the exceptions: "face-to-face conversation" is
an important part of communication, but it is rarely sufficient
for conveying technical information; and I know of NO
justification for a claim that "the best architectures..." emerge
from self-organizing team).

I have said to some other people that I believe XP, in particular,
is a highly conservative approach to software development. It is
strongly structured and focused on never taking on more than
one-iteration's worth of risk. My only real complaint with it is
that it emphasizes YAGNI while not making it clear that the team
really does have a continuing sense of the expected end-point of
the project - not just for the current iteration.

scott


| From: Jonathan Kern<***@comcast.net>
|
| Uhhh.
|
| Are you saying the Agile Manifesto principles are equivalent
one-off,
| random, questionable statistical evidence as implied by your
leather
| and running regimen "fad" example?
|
| Uhhh.
|
| -- jon
|
| > -----Original Message-----
| > From: Jason Gorman [mailto:***@objectmonkey.com]
| > Sent: Tuesday, January 27, 2004 1:23 PM
| > To: ***@topica.com
| > Subject: RE: [AM] Unfounded assertion
| >
| >
| > I would take the manifesto with a pinch of salt. They're
hardly the
| > Ten Commandments or Principa Mathematica. They're just stories
about
| > how other people managed to adapt quickly to change on
software
| > projects. I treat them like diet books or exercise regimes.
Some
| > minor celeb loses 20 lbs eating nothing but leather and
running up
| > and down stairs with a cat on their head,
| > and everybody says "you look great! What's your secret?" and
| > before you know
| > it they've got a book and a video out telling everybody "this
is
| > how to lose
| > 20lbs"... XP is the Atkins Diet of software development
methods. It worked
| > for Jennifer Aniston, but I hear Geri Halliwell's not too
keen.
| >
| > Jason Gorman
| > http://www.objectmonkey.com
| >
| > -----Original Message-----
| > From: Graham [mailto:***@virgin.net]
| > Sent: 27 January 2004 17:02
| > To: ***@topica.com
| > Subject: [AM] Unfounded assertion
| >
| > "I mentioned to Graham several times that he should invest the
time
| > to read the values and principles at www.agilealliance.org,
but he
| > chose not to. I
| > eventually posted the material to the DM discussion list, but
the only
| > responses were to mock the concepts. Oh well."
| > ----------------------------------------------
| > Scott
| >
| > Please discontinue making unfounded assertions and implying I
have
| > done no research into Agile methods. As to whether I am
| > misinterpreting Agile...
| >
| > I long ago read the Agile manifesto, and indeed include it in
| > presentations on Agile methods. I have gathered feedback from
DSDM
| > projects and interviewed people from a team applying Extreme
| > Programming in close to its
| > pure form. (You think coding the unit test first is not a
painful
| > discipline? You think everybody enjoys pair programming?)
| >
| > The agile values are mushy. The agile principles are more
helpful,
| > and you ought to have noticed that I drew on them to formulate
my
| > list of 8 points
| > ------------------------------------------
| > 1 ensure sponsors and customers are commited to all of the
following
| > principles
| >
| > 2 be flexibile about requirements and time or cash box your
delivery
| > ³Welcome changing requirements, even late in development.
Agile
| > processes harness change for the customer's competitive
advantage.²
| >
| > 3 maintain continuous and close user involvement ³Business
people
| > and developers must work together daily throughout the
project.²
| >
| > 4 empower a small team (including users) to get on with it
³Build
| > projects around motivated individuals. Give them the
environment and
| > support they need, and trust them to get the job done.²
| >
| > 5 focus on program code and tests rather than on
specifications
| > ³Working software is the primary measure of progress. The most

| > efficient and effective method of conveying information to and

| > within a development team is face-to-face conversation.²
| >
| > 6 develop iteratively, driven by priorities ³Our highest
priority is
| > to satisfy the customer through early and continuous delivery
of
| > valuable software. Deliver working software frequently, from a

| > couple of weeks to a couple of months, with a preference to
the
| > shorter timescale.²
| >
| > 7 iteratively refactor program structures and data structures
built
| > so far
| >
| > 8 use prototypes to tackle tricky design issues early
| > ------------------------------------------
| > I added one point at the beginning, which Agilists overlook at
their
| > peril.
| >
| > I added two points at the end: 7 in deference to Martin Fowler
and
| > yourself, and 8 in deference to DSDM and UP/RUP.
| >
| > I left out principles at the bottom of the Agile list partly
because
| > they did not seem to me so definitive, and partly to be more
| > concise. "Agile processes promote sustainable development. The

| > sponsors, developers, and users should be able to maintain a
| > constant pace indefinitely. Continuous attention to technical
| > excellence and good design enhances agility.
| > Simplicity--the art of maximizing the amount of work not
done--is
| > essential.
| > The best architectures, requirements, and designs emerge from
| > self-organizing teams.
| > At regular intervals, the team reflects on how to become more
effective,
| > then tunes and adjusts its behavior accordingly."
| >
| > I won't explain all my rewordings, but ³Welcome changing
| > requirements, even late in development" is simply untenable
unless
| > your customer has agreed to
| > point 2 as I express it above.
| >
| > Graham
| >
| > For more information about AM, visit the Agile Modeling Home
Page at
| > www.agilemodeling.com
| >
| > For more information about AM, visit the Agile Modeling Home
Page at
| > www.agilemodeling.com
| >
| >
|
| For more information about AM, visit the Agile Modeling Home
Page at
| www.agilemodeling.com
|
|
|
|

--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign,
il 61820
e-mail: ***@urbana.css.mot.com fax: [phone]
phone: [phone] cell: 217-433-6114 pager:
***@msg.myvzw.com

For more information about AM, visit the Agile Modeling Home Page
at www.agilemodeling.com
-

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[p***@aol.com]

In a message dated 01/29/2004 6:52:40 AM Pacific Standard Time,
***@urbana.css.mot.com writes:

Scott:
>
> (2) this discussion has been larded with comments about agile meaning
> teams have the freedom to do the right thing; there's been less mention
> of the direct corollary that they are also free to do the wrong thing;
> it may be difficult for a client to tell whether the pitch is coming
> from capable agile methodologists or code cowboys

Unfortunately true, but it may be no more true for "agilists" than other
methodologists. As a card-carrying former member of the Mohogany Row group, I can
assure you that the ability of even the most well-known and respected
software development companies to deliver the desired project results is always an
open question.
>
> (3) though I don't have references to share, I have heard from
> colleagues that some of the early success stories were, in fact, less
> successful that usually described and viewed afterwards by the client
> failures; many of the articles in the anecdotal evidence files end up
> saying that the client didn't continue using the practices (usually
> attributed to organizational factors, but a sign that success wasn't
> so obvious that it couldn't be denied)

My experience has been slightly different from this. Almost without
exception, negative comments have originated from the IS group that either would
normally have been responsible for the project, or that had failed at conducting it
or other projects for the same customer. I'm sure that your assertion has
merit, but I wonder what an objective assessment of the results of these projects
would reveal.

>
> (5) a number of the Principles boldly state completely unproved
> assertions; I have no problem with that in the context of taking them as
> principles (statements of belief), but potential clients do need to be
> consider whether the methodologits' belief is enough to go on.

IMHE, the level of confidence that most customers have regarding software
development has put just about every approach in pretty much the same category.
Whether we ackowledge it or not, embarking upon a development process of any
consequence is cause for significant concern for customers, regardless of who's
doing the pitching. Unfortunately, regarding outside development resources,
the choice often comes down to which one has the most to lose if the project
goes to litigation.

>
> I should say that I wholeheartedly agree with about 90% of what the
> Principles say (the exceptions: "face-to-face conversation" is an
> important part of communication, but it is rarely sufficient for
> conveying technical information; and I know of NO justification for a
> claim that "the best architectures..." emerge from self-organizing
> team).

This may be putting too fine a point on this issue, but at the very least,
face-to-face is usually the last, and possibly most important, aspect of
concordance between participants in a project. This form of communication can yield
far more information regarding the state of things than any other. Emoticons
in emails, for example, are cute, but I have yet to see one that would convey
the rolling of one's eyes at the mention of a particularly ticklish topic. It
might be more appropriate to consider "face to face" as a metaphor for "clear,
concise and complete" communication. In the final analysis, it may not be
perfect, but it beats just about everything else.

As far as the architecture issue is concerned, this assertion may be one of
those for which the salt is recommended. Or maybe the term "assertions" should
be changed to "suggestions". The resolution of this issue might require some
face to face communications.

>
> I have said to some other people that I believe XP, in particular, is
> a highly conservative approach to software development. It is strongly
> structured and focused on never taking on more than one-iteration's
> worth of risk. My only real complaint with it is that it emphasizes
> YAGNI while not making it clear that the team really does have a
> continuing sense of the expected end-point of the project - not just for
> the current iteration.
>
I don't think there is anything in the Principles that precludes recognition
of, or communication regarding, the end point of a project. Focusing on the
current iteration, at the very least, is a means of preventing distractions and
fomenting the continuous delivery of value to the customer. On the other hand,
it might be well to remember that the end point is rarely fixed, except in
relative terms; it can change during the life of the project. If requirements
always change, as seems to be the case, so does the end point. The failure to
recognize this fact is one of the most significant factors contributing to the
failure of software development projects. Absent this fact, there would not be
the significant incentive there seems to be for finding a better way to build
software.

Regards,

Pete

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Randy Miller]

Hi Pat,


> On the strength of that test, he decided to install the
new routine. He regretted that as they marched him out the door,
next day. There are still cowboys around who want to do things
their own way, and we need a methodology to prevent them from
creating disasters.

Does methodology really prevent this? Would a review process or pair
programming have helped? What exactly did he do that caused him to be
expelled?

Thanks,
Randy Miller

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Patrick James Nelis]

The organization used a waterfall methodology. He violated it.
Ten tests failed. The eleventh worked. On the strength of that
one test, he installed a change to the content management system.
Clearly, he was an idiot. Having the methodology did not prevent
him from acting. Obviously there was a flaw in the control
mechanism.

The point is that there are still cowboys who think they can
operate on their own. They object to the strict and mind-numbing
processes in the formal waterfall approach. I can't blame them in
many cases. Most are not idiots and can be useful contributors,
if we can provide an environment in which they can work. They may
need a range of approaches with which they can live. IMHO, the
agile approach is a vital part of any shop's mix of available
methodologies.

Pat

-----Original Message-----
From: Randy Miller [mailto:***@borland.com]
Sent: Thursday, January 29, 2004 2:24 PM
To: ***@topica.com
Subject: RE: [AM] Unfounded assertion



Hi Pat,


> On the strength of that test, he decided to install the
new routine. He regretted that as they marched him out the door,
next day. There are still cowboys around who want to do things
their own way, and we need a methodology to prevent them from
creating disasters.

Does methodology really prevent this? Would a review process or
pair programming have helped? What exactly did he do that caused
him to be expelled?

Thanks,
Randy Miller

For more information about AM, visit the Agile Modeling Home Page
at www.agilemodeling.com
-

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Randy Miller]

I would add that 2004 is a very different environment that was the year 2000. We have some very different trends than those that were partially vanquished by the original AM. I do believe that an update would be reasonable.

Randy Miller

-----Original Message-----
From: Jason Gorman [mailto:***@objectmonkey.com]
Sent: Thursday, January 29, 2004 9:23 AM
To: ***@topica.com
Subject: RE: Validating Agility was RE: [AM] Unfounded assertion

I'd be up for that :-) When is Snowbird II?

Jason Gorman
http://www.objectmonkey.com


-----Original Message-----
From: Scott Ambler [mailto:***@ronin-intl.com]
Sent: 29 January 2004 13:18
To: ***@topica.com
Subject: Validating Agility was RE: [AM] Unfounded assertion

Perhaps at an upcoming conference it would be interesting to hold some sort
of workshop where the manifesto and principles are explored and potentially
validated based on experience since they were defined?

Snowbird II perhaps?

- Scott

At 11:17 PM 1/28/2004 -0500, you wrote:
>Uhhh.
>
>Are you saying the Agile Manifesto principles are equivalent one-off,
>random, questionable statistical evidence as implied by your leather
>and running regimen "fad" example?
>
>Uhhh.
>
>-- jon
>
>
>
> > -----Original Message-----
> > From: Jason Gorman [mailto:***@objectmonkey.com]
> > Sent: Tuesday, January 27, 2004 1:23 PM
> > To: ***@topica.com
> > Subject: RE: [AM] Unfounded assertion
> >
> >
> > I would take the manifesto with a pinch of salt. They're hardly the
> > Ten Commandments or Principa Mathematica. They're just stories about
> > how other people managed to adapt quickly to change on software
> > projects. I treat them like diet books or exercise regimes. Some
> > minor celeb loses 20 lbs eating nothing but leather and running up
> > and down stairs with a cat on their head, and everybody says "you
> > look great! What's your secret?" and before you know it they've got
> > a book and a video out telling everybody "this is how to lose
> > 20lbs"... XP is the Atkins Diet of software development methods. It
> > worked for Jennifer Aniston, but I hear Geri Halliwell's not too keen.
> >
> > Jason Gorman
> > http://www.objectmonkey.com
> >
> > -----Original Message-----
> > From: Graham [mailto:***@virgin.net]
> > Sent: 27 January 2004 17:02
> > To: ***@topica.com
> > Subject: [AM] Unfounded assertion
> >
> > "I mentioned to Graham several times that he should invest the time
> > to read the values and principles at www.agilealliance.org, but he
> > chose not to. I eventually posted the material to the DM discussion
> > list, but the only responses were to mock the concepts. Oh well."
> > ----------------------------------------------
> > Scott
> >
> > Please discontinue making unfounded assertions and implying I have
> > done no research into Agile methods. As to whether I am misinterpreting
Agile...
> >
> > I long ago read the Agile manifesto, and indeed include it in
> > presentations on Agile methods. I have gathered feedback from DSDM
> > projects and interviewed people from a team applying Extreme
> > Programming in close to its pure form. (You think coding the unit
> > test first is not a painful discipline? You think everybody enjoys
> > pair programming?)
> >
> > The agile values are mushy. The agile principles are more helpful,
> > and you ought to have noticed that I drew on them to formulate my
> > list of 8 points
> > ------------------------------------------
> > 1 ensure sponsors and customers are commited to all of the following
> > principles
> >
> > 2 be flexibile about requirements and time or cash box your delivery
> > ³Welcome changing requirements, even late in development. Agile
> > processes harness change for the customer's competitive advantage.²
> >
> > 3 maintain continuous and close user involvement ³Business people
> > and developers must work together daily throughout the project.²
> >
> > 4 empower a small team (including users) to get on with it ³Build
> > projects around motivated individuals. Give them the environment and
> > support they need, and trust them to get the job done.²
> >
> > 5 focus on program code and tests rather than on specifications
> > ³Working software is the primary measure of progress.
> > The most efficient and effective method of conveying information to
> > and within a development team is face-to-face conversation.²
> >
> > 6 develop iteratively, driven by priorities ³Our highest priority is
> > to satisfy the customer through early and continuous delivery of
> > valuable software.
> > Deliver working software frequently, from a couple of weeks to a
> > couple of months, with a preference to the shorter timescale.²
> >
> > 7 iteratively refactor program structures and data structures built
> > so far
> >
> > 8 use prototypes to tackle tricky design issues early
> > ------------------------------------------
> > I added one point at the beginning, which Agilists overlook at their
> > peril.
> >
> > I added two points at the end: 7 in deference to Martin Fowler and
> > yourself, and 8 in deference to DSDM and UP/RUP.
> >
> > I left out principles at the bottom of the Agile list partly because
> > they did not seem to me so definitive, and partly to be more concise.
> > "Agile processes promote sustainable development. The sponsors,
> > developers, and users should be able to maintain a constant pace
> > indefinitely.
> > Continuous attention to technical excellence and good design
> > enhances agility.
> > Simplicity--the art of maximizing the amount of work not done--is
> > essential.
> > The best architectures, requirements, and designs emerge from
> > self-organizing teams.
> > At regular intervals, the team reflects on how to become more
> > effective, then tunes and adjusts its behavior accordingly."
> >
> > I won't explain all my rewordings, but ³Welcome changing
> > requirements, even late in development" is simply untenable unless
> > your customer has agreed to point 2 as I express it above.
> >
> > Graham
> >
> > For more information about AM, visit the Agile Modeling Home Page at
> > www.agilemodeling.com
> >
> > For more information about AM, visit the Agile Modeling Home Page at
> > www.agilemodeling.com
> >
> >
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com

====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Randy Miller]

So would it be safe to say that 'agile' is about enablement? If you
enable an idiot, all you get is garbage. That waterfall is about
prevention (of mistakes)? If you have a bunch of idiots, waterfall
prevents them from doing too much damage (or anything at all)? In your
opinion, is process about enablement or prevention?

Randy

-----Original Message-----
From: Patrick James Nelis [mailto:***@nelis.com]
Sent: Thursday, January 29, 2004 2:47 PM
To: ***@topica.com
Subject: RE: [AM] Unfounded assertion

The organization used a waterfall methodology. He violated it.
Ten tests failed. The eleventh worked. On the strength of that
one test, he installed a change to the content management system.
Clearly, he was an idiot. Having the methodology did not prevent
him from acting. Obviously there was a flaw in the control
mechanism.

The point is that there are still cowboys who think they can
operate on their own. They object to the strict and mind-numbing
processes in the formal waterfall approach. I can't blame them in
many cases. Most are not idiots and can be useful contributors,
if we can provide an environment in which they can work. They may
need a range of approaches with which they can live. IMHO, the
agile approach is a vital part of any shop's mix of available
methodologies.

Pat

-----Original Message-----
From: Randy Miller [mailto:***@borland.com]
Sent: Thursday, January 29, 2004 2:24 PM
To: ***@topica.com
Subject: RE: [AM] Unfounded assertion



Hi Pat,


> On the strength of that test, he decided to install the
new routine. He regretted that as they marched him out the door,
next day. There are still cowboys around who want to do things
their own way, and we need a methodology to prevent them from
creating disasters.

Does methodology really prevent this? Would a review process or
pair programming have helped? What exactly did he do that caused
him to be expelled?

Thanks,
Randy Miller

For more information about AM, visit the Agile Modeling Home Page
at www.agilemodeling.com
-

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Patrick James Nelis]

Randy,

You are putting words in my mouth. They did not use an agile
process.
Neither process, by itself, prevents or enables garbage. An idiot
can screw up any system.
Processes should enable. Ideally, they also prevent accidents. I
don't see processes as an either/or proposition.

Pat

-----Original Message-----
From: Randy Miller [mailto:***@borland.com]
Sent: Thursday, January 29, 2004 2:55 PM
To: ***@topica.com
Subject: RE: [AM] Unfounded assertion


So would it be safe to say that 'agile' is about enablement? If
you enable an idiot, all you get is garbage. That waterfall is
about prevention (of mistakes)? If you have a bunch of idiots,
waterfall prevents them from doing too much damage (or anything at
all)? In your opinion, is process about enablement or prevention?

Randy

-----Original Message-----
From: Patrick James Nelis [mailto:***@nelis.com]
Sent: Thursday, January 29, 2004 2:47 PM
To: ***@topica.com
Subject: RE: [AM] Unfounded assertion

The organization used a waterfall methodology. He violated it.
Ten tests failed. The eleventh worked. On the strength of that
one test, he installed a change to the content management system.
Clearly, he was an idiot. Having the methodology did not prevent
him from acting. Obviously there was a flaw in the control
mechanism.

The point is that there are still cowboys who think they can
operate on their own. They object to the strict and mind-numbing
processes in the formal waterfall approach. I can't blame them in
many cases. Most are not idiots and can be useful contributors,
if we can provide an environment in which they can work. They may
need a range of approaches with which they can live. IMHO, the
agile approach is a vital part of any shop's mix of available
methodologies.

Pat

-----Original Message-----
From: Randy Miller [mailto:***@borland.com]
Sent: Thursday, January 29, 2004 2:24 PM
To: ***@topica.com
Subject: RE: [AM] Unfounded assertion



Hi Pat,


> On the strength of that test, he decided to install the
new routine. He regretted that as they marched him out the door,
next day. There are still cowboys around who want to do things
their own way, and we need a methodology to prevent them from
creating disasters.

Does methodology really prevent this? Would a review process or
pair programming have helped? What exactly did he do that caused
him to be expelled?

Thanks,
Randy Miller

For more information about AM, visit the Agile Modeling Home Page
at www.agilemodeling.com
-

For more information about AM, visit the Agile Modeling Home Page
at www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page
at www.agilemodeling.com
-

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Paul Oldfield]

(responding to Randy)

> So would it be safe to say that 'agile' is about enablement? If you
> enable an idiot, all you get is garbage. That waterfall is about
> prevention (of mistakes)? If you have a bunch of idiots, waterfall
> prevents them from doing too much damage (or anything at all)?
> In your opinion, is process about enablement or prevention?

Pardon me jumping in...

IMHO one of the main criteria for appropriateness is "Attainability",
whether or not the process can be enacted by the people
available. The way I put it is:

"The important thing is that the goals are met; the flexibility that
comes through fewer constraints on how the goals are met gives
the opportunity for an efficient solution to be found. Alternatively,
it gives the opportunity for an inexperienced team to go astray."

Or to mis-quote somebody else:

"A fool with a rule is still a fool".

If you have better people, you can attain a more agile process.
With certain approaches, you can use the few good people
you have to best effect, to facilitate the attaining of a more
agile process. But if you strive for more agility than you can
attain, bad things will happen. Yet you can strive to change
the situation, to make the people available get better faster.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Patrick James Nelis]

Thank you, Paul. Well said.

Pat

-----Original Message-----
From: Paul Oldfield [mailto:***@compuserve.com]
Sent: Thursday, January 29, 2004 5:34 PM
To: INTERNET:***@topica.com
Subject: RE: [AM] Unfounded assertion


(responding to Randy)

> So would it be safe to say that 'agile' is about enablement? If
you
> enable an idiot, all you get is garbage. That waterfall is about

> prevention (of mistakes)? If you have a bunch of idiots,
waterfall
> prevents them from doing too much damage (or anything at all)?
In your
> opinion, is process about enablement or prevention?

Pardon me jumping in...

IMHO one of the main criteria for appropriateness is
"Attainability", whether or not the process can be enacted by the
people available. The way I put it is:

"The important thing is that the goals are met; the flexibility
that
comes through fewer constraints on how the goals are met gives
the opportunity for an efficient solution to be found.
Alternatively,
it gives the opportunity for an inexperienced team to go astray."

Or to mis-quote somebody else:

"A fool with a rule is still a fool".

If you have better people, you can attain a more agile process.
With certain approaches, you can use the few good people you have
to best effect, to facilitate the attaining of a more agile
process. But if you strive for more agility than you can attain,
bad things will happen. Yet you can strive to change the
situation, to make the people available get better faster.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of Mentors
of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page
at www.agilemodeling.com
-

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Graham]

I'm not sure I understood that Paul

A non-agile process may be readily "attainable", may be enactable by the
people available, can be easier to understand and follow than an agile one.

Isn't that the reason managers cling to process flowcharts?


>
>-----Original Message-----
>From: Paul Oldfield [mailto:***@compuserve.com]
>Sent: Thursday, January 29, 2004 5:34 PM
>To: INTERNET:***@topica.com
>Subject: RE: [AM] Unfounded assertion
>
>
>(responding to Randy)
>
>> So would it be safe to say that 'agile' is about enablement? If
>you
>> enable an idiot, all you get is garbage. That waterfall is about
>
>> prevention (of mistakes)? If you have a bunch of idiots,
>waterfall
>> prevents them from doing too much damage (or anything at all)?
>In your
>> opinion, is process about enablement or prevention?
>
>Pardon me jumping in...
>
>IMHO one of the main criteria for appropriateness is
>"Attainability", whether or not the process can be enacted by the
>people available. The way I put it is:
>
>"The important thing is that the goals are met; the flexibility
>that
>comes through fewer constraints on how the goals are met gives
>the opportunity for an efficient solution to be found.
>Alternatively,
>it gives the opportunity for an inexperienced team to go astray."
>
>Or to mis-quote somebody else:
>
>"A fool with a rule is still a fool".
>
>If you have better people, you can attain a more agile process.
>With certain approaches, you can use the few good people you have
>to best effect, to facilitate the attaining of a more agile
>process. But if you strive for more agility than you can attain,
>bad things will happen. Yet you can strive to change the
>situation, to make the people available get better faster.
>
>
>Paul Oldfield
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>www.aptprocess.com
>
>any opinions expressed herein are not necessarily those of Mentors
>of Cally or the Appropriate Process Movement
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>For more information about AM, visit the Agile Modeling Home Page
>at www.agilemodeling.com
>-
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Paul Oldfield]

(responding to Graham)

> I'm not sure I understood that Paul
>
> A non-agile process may be readily "attainable", may be
> enactable by the people available, can be easier to understand
> and follow than an agile one.

With a robust, heavyweight process, things can still go wrong,
but there is more support to keep people on a track that
should lead to success, and more mechanisms in place to
detect straying from the track. People still stray from the track
because they, individually, have less ability to attain a
process. Overall, the safety nets do a better automated job
of detecting this and allowing the process as a whole to be
kept on track with fewer good people. One of the reasons
this works is because it slows everything down to a pace
where these fewer good people can keep up.

You still *need* some good people, or failure is almost
guaranteed. And of course, the progress is slower even
with more people, and as one adds more people, the
useful (i.e. value-adding) work each one does per unit time
decreases because they need to spend more time
writing documentation for the next person.

> Isn't that the reason managers cling to process flowcharts?

Where the manager is incompetent, the ability to blame
failures on the process rather than his own failings is a great
comfort. A good manager would recognise that the key
to success is getting good people to do the work, and
concentrate his efforts on obtaining more good people, and
ensuring the people he has available become better faster.
Having good people available, he would want to take
advantage of the opportunity by following a more agile
process.

Where a manager wants to prepare for failure, he will want
to keep big process. Where he wants to prepare for success,
he will strive for an efficient, adaptable approach. One is
limited, in choosing a process, to those one can attain.
However, one can work toward making a better process
attainable. There are two types of tool in the bag;
"Adapting to the situation", and "Changing the situation".


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Randy Miller]

Hi Pat,

Thanks for the clarification. Yes, I totally agree. I think that you
brought up an interesting idea. Some activities, like code reviews, are
clearly preventative. They keep people from making mistakes. Other
activities, like requirements gathering, help people build the right
system. Or maybe they prevent people from building the wrong system. I
found it interesting to look at an activity as a guidance mechanism
(with an enabling side and a prevention side) instead of something to
hold you down or prop you up. Your message provoke that line of thought.

Randy

-----Original Message-----
From: Patrick James Nelis [mailto:***@nelis.com]
Sent: Thursday, January 29, 2004 3:23 PM
To: ***@topica.com
Subject: RE: [AM] Unfounded assertion

Randy,

You are putting words in my mouth. They did not use an agile
process.
Neither process, by itself, prevents or enables garbage. An idiot
can screw up any system.
Processes should enable. Ideally, they also prevent accidents. I
don't see processes as an either/or proposition.

Pat

-----Original Message-----
From: Randy Miller [mailto:***@borland.com]
Sent: Thursday, January 29, 2004 2:55 PM
To: ***@topica.com
Subject: RE: [AM] Unfounded assertion


So would it be safe to say that 'agile' is about enablement? If
you enable an idiot, all you get is garbage. That waterfall is
about prevention (of mistakes)? If you have a bunch of idiots,
waterfall prevents them from doing too much damage (or anything at
all)? In your opinion, is process about enablement or prevention?

Randy

-----Original Message-----
From: Patrick James Nelis [mailto:***@nelis.com]
Sent: Thursday, January 29, 2004 2:47 PM
To: ***@topica.com
Subject: RE: [AM] Unfounded assertion

The organization used a waterfall methodology. He violated it.
Ten tests failed. The eleventh worked. On the strength of that
one test, he installed a change to the content management system.
Clearly, he was an idiot. Having the methodology did not prevent
him from acting. Obviously there was a flaw in the control
mechanism.

The point is that there are still cowboys who think they can
operate on their own. They object to the strict and mind-numbing
processes in the formal waterfall approach. I can't blame them in
many cases. Most are not idiots and can be useful contributors,
if we can provide an environment in which they can work. They may
need a range of approaches with which they can live. IMHO, the
agile approach is a vital part of any shop's mix of available
methodologies.

Pat

-----Original Message-----
From: Randy Miller [mailto:***@borland.com]
Sent: Thursday, January 29, 2004 2:24 PM
To: ***@topica.com
Subject: RE: [AM] Unfounded assertion



Hi Pat,


> On the strength of that test, he decided to install the
new routine. He regretted that as they marched him out the door,
next day. There are still cowboys around who want to do things
their own way, and we need a methodology to prevent them from
creating disasters.

Does methodology really prevent this? Would a review process or
pair programming have helped? What exactly did he do that caused
him to be expelled?

Thanks,
Randy Miller

For more information about AM, visit the Agile Modeling Home Page
at www.agilemodeling.com
-

For more information about AM, visit the Agile Modeling Home Page
at www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page
at www.agilemodeling.com
-

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Adrian Howard]

On Friday, January 30, 2004, at 08:41 pm, Randy Miller wrote:
[snip]
> Some activities, like code reviews, are
> clearly preventative. They keep people from making mistakes. Other
> activities, like requirements gathering, help people build the right
> system. Or maybe they prevent people from building the wrong system. I
> found it interesting to look at an activity as a guidance mechanism
> (with an enabling side and a prevention side) instead of something to
> hold you down or prop you up. Your message provoke that line of
> thought.
[snip]

Interesting point of view. Of course a lot depends on how the activity
is done.

The better code review sessions I've been involved were more about
building the right system than they were about preventing mistakes.
More "We can refactor that out into a new class" than "That will die
horribly on edge case foo".

I'm sure I'm not alone in having the experience of a large requirements
gathering process helping build the wrong system :-)

It's interesting that agile practices like TDD and pair programming
turn find-the-defect activities into drive-the-design activities by
tightening the feedback loop much as possible.

Adrian

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Hubert Matthews]

Adrian Howard wrote:

> The better code review sessions I've been involved were more about building the right system
> than they were about preventing mistakes. More "We can refactor that out into a new class"
> than "That will die horribly on edge case foo".

This seems contradictory to me. The first sentence implies an emphasis on the problem domain,
but the second one seems to value technical matters rather than problem domain. Can I ask you
to clarify, please?

--
Hubert Matthews http://www.oxyware.com/
Software Consultant ***@oxyware.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Adrian Howard]

On Monday, February 2, 2004, at 11:00 am, Hubert Matthews wrote:

> Adrian Howard wrote:
>
>> The better code review sessions I've been involved were more about
>> building the right system
>> than they were about preventing mistakes. More "We can refactor that
>> out into a new class"
>> than "That will die horribly on edge case foo".
>
> This seems contradictory to me. The first sentence implies an
> emphasis on the problem domain,
> but the second one seems to value technical matters rather than
> problem domain. Can I ask you
> to clarify, please?

Sorry, my poor communication skills again :-)

I was trying to say that better code review sessions often focus more
on problem domain stuff (refactoring, etc.) than bugs. Good code
reviews as much, if not more, about building the right system than
they are about spotting and preventing errors.

Clarified?

Adrian

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Jason Gorman]

Is refactoring "problem domain stuff"? I thought it was about improving the
technical design without changing what the system does. Surely refactoring
is "solution domain"?

Jason Gorman
http://www.objectmonkey.com

-----Original Message-----
From: Adrian Howard [mailto:***@quietstars.com]
Sent: 02 February 2004 15:10
To: ***@topica.com
Subject: Re: [AM] Unfounded assertion


On Monday, February 2, 2004, at 11:00 am, Hubert Matthews wrote:

> Adrian Howard wrote:
>
>> The better code review sessions I've been involved were more about
>> building the right system than they were about preventing mistakes.
>> More "We can refactor that out into a new class"
>> than "That will die horribly on edge case foo".
>
> This seems contradictory to me. The first sentence implies an
> emphasis on the problem domain, but the second one seems to value
> technical matters rather than problem domain. Can I ask you to
> clarify, please?

Sorry, my poor communication skills again :-)

I was trying to say that better code review sessions often focus more on
problem domain stuff (refactoring, etc.) than bugs. Good code reviews as
much, if not more, about building the right system than they are about
spotting and preventing errors.

Clarified?

Adrian

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Jonathan Kern]

Unfortunately, most refactoring is often thought of as low-level code fixes.
But, it should be more than that.

You should most definitely consider refactoring the problem domain when you
find out new requirements that "break" your model.

To not do this is to risk building up technical debt.

If a feature has to be "jammed" in to the object model, you are better off
refactoring.


-- jon



> -----Original Message-----
> From: Jason Gorman [mailto:***@objectmonkey.com]
> Sent: Monday, February 02, 2004 7:17 PM
> To: ***@topica.com
> Subject: RE: [AM] Unfounded assertion
>
>
> Is refactoring "problem domain stuff"? I thought it was about
> improving the
> technical design without changing what the system does. Surely refactoring
> is "solution domain"?
>
> Jason Gorman
> http://www.objectmonkey.com
>
> -----Original Message-----
> From: Adrian Howard [mailto:***@quietstars.com]
> Sent: 02 February 2004 15:10
> To: ***@topica.com
> Subject: Re: [AM] Unfounded assertion
>
>
> On Monday, February 2, 2004, at 11:00 am, Hubert Matthews wrote:
>
> > Adrian Howard wrote:
> >
> >> The better code review sessions I've been involved were more about
> >> building the right system than they were about preventing mistakes.
> >> More "We can refactor that out into a new class"
> >> than "That will die horribly on edge case foo".
> >
> > This seems contradictory to me. The first sentence implies an
> > emphasis on the problem domain, but the second one seems to value
> > technical matters rather than problem domain. Can I ask you to
> > clarify, please?
>
> Sorry, my poor communication skills again :-)
>
> I was trying to say that better code review sessions often focus more on
> problem domain stuff (refactoring, etc.) than bugs. Good code reviews as
> much, if not more, about building the right system than they are about
> spotting and preventing errors.
>
> Clarified?
>
> Adrian
>
> For more information about AM, visit the Agile Modeling Home Page at
> www.agilemodeling.com
>
> For more information about AM, visit the Agile Modeling Home Page
> at www.agilemodeling.com
>
>
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Jason Gorman]

But new requirements can't be handled by refactoring, surely? If you have
new requirements then aren't you changing the behaviour of the system?
Refactoring requires you to preserve requirements at that moment in time,
surely.

Jason Gorman
http://www.objectmonkey.com

-----Original Message-----
From: Jonathan Kern [mailto:***@comcast.net]
Sent: 03 February 2004 02:45
To: ***@topica.com
Subject: RE: [AM] Unfounded assertion

Unfortunately, most refactoring is often thought of as low-level code fixes.
But, it should be more than that.

You should most definitely consider refactoring the problem domain when you
find out new requirements that "break" your model.

To not do this is to risk building up technical debt.

If a feature has to be "jammed" in to the object model, you are better off
refactoring.


-- jon



> -----Original Message-----
> From: Jason Gorman [mailto:***@objectmonkey.com]
> Sent: Monday, February 02, 2004 7:17 PM
> To: ***@topica.com
> Subject: RE: [AM] Unfounded assertion
>
>
> Is refactoring "problem domain stuff"? I thought it was about
> improving the technical design without changing what the system does.
> Surely refactoring is "solution domain"?
>
> Jason Gorman
> http://www.objectmonkey.com
>
> -----Original Message-----
> From: Adrian Howard [mailto:***@quietstars.com]
> Sent: 02 February 2004 15:10
> To: ***@topica.com
> Subject: Re: [AM] Unfounded assertion
>
>
> On Monday, February 2, 2004, at 11:00 am, Hubert Matthews wrote:
>
> > Adrian Howard wrote:
> >
> >> The better code review sessions I've been involved were more about
> >> building the right system than they were about preventing mistakes.
> >> More "We can refactor that out into a new class"
> >> than "That will die horribly on edge case foo".
> >
> > This seems contradictory to me. The first sentence implies an
> > emphasis on the problem domain, but the second one seems to value
> > technical matters rather than problem domain. Can I ask you to
> > clarify, please?
>
> Sorry, my poor communication skills again :-)
>
> I was trying to say that better code review sessions often focus more
> on problem domain stuff (refactoring, etc.) than bugs. Good code
> reviews as much, if not more, about building the right system than
> they are about spotting and preventing errors.
>
> Clarified?
>
> Adrian
>
> For more information about AM, visit the Agile Modeling Home Page at
> www.agilemodeling.com
>
> For more information about AM, visit the Agile Modeling Home Page at
> www.agilemodeling.com
>
>
>

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Hubert Matthews]

Jason Gorman wrote:

> But new requirements can't be handled by refactoring, surely? If you have new requirements
> then aren't you changing the behaviour of the system? Refactoring requires you to preserve
> requirements at that moment in time, surely.

Refactoring is isofunctional - agreed. My view is that it should be done both before changing
the system so the new functionality is easier to add, and afterwards (to a lesser extent) to
tidy up once a correct solution approach has been found. The reason for the "lesser extent"
comment for post-change refactoring is because it is easy to keep fiddling with the code
without any obvious ending criteria.

--
Hubert Matthews http://www.oxyware.com/
Software Consultant ***@oxyware.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Jonathan Kern]

Jason,

> But new requirements can't be handled by refactoring, surely?

well... it depends

maybe we shouldn't pigeon-hole necessary changes as refactoring in that it
is only a first step.

That is, I always like to remind my teams that a "feature" should be easy to
add to the application. If it feels like you are jamming it in, then maybe
we need to alter the model/design.

So, you could alter the model (refactor), run the unit/acceptance tests to
ensure the app still works. Then, proceed to add the new feature.


So, maybe we can't call "adding new requirements" as "refactoring," but a
sense of fixing the model ahead of time to make the new feature "slip right
in" is how I like to work.

-- jon



> -----Original Message-----
> From: Jason Gorman [mailto:***@objectmonkey.com]
> Sent: Monday, February 02, 2004 9:48 PM
> To: ***@topica.com
> Subject: RE: [AM] Unfounded assertion
>
>
> But new requirements can't be handled by refactoring, surely? If you have
> new requirements then aren't you changing the behaviour of the system?
> Refactoring requires you to preserve requirements at that moment in time,
> surely.
>
> Jason Gorman
> http://www.objectmonkey.com
>
> -----Original Message-----
> From: Jonathan Kern [mailto:***@comcast.net]
> Sent: 03 February 2004 02:45
> To: ***@topica.com
> Subject: RE: [AM] Unfounded assertion
>
> Unfortunately, most refactoring is often thought of as low-level
> code fixes.
> But, it should be more than that.
>
> You should most definitely consider refactoring the problem
> domain when you
> find out new requirements that "break" your model.
>
> To not do this is to risk building up technical debt.
>
> If a feature has to be "jammed" in to the object model, you are better off
> refactoring.
>
>
> -- jon
>
>
>
> > -----Original Message-----
> > From: Jason Gorman [mailto:***@objectmonkey.com]
> > Sent: Monday, February 02, 2004 7:17 PM
> > To: ***@topica.com
> > Subject: RE: [AM] Unfounded assertion
> >
> >
> > Is refactoring "problem domain stuff"? I thought it was about
> > improving the technical design without changing what the system does.
> > Surely refactoring is "solution domain"?
> >
> > Jason Gorman
> > http://www.objectmonkey.com
> >
> > -----Original Message-----
> > From: Adrian Howard [mailto:***@quietstars.com]
> > Sent: 02 February 2004 15:10
> > To: ***@topica.com
> > Subject: Re: [AM] Unfounded assertion
> >
> >
> > On Monday, February 2, 2004, at 11:00 am, Hubert Matthews wrote:
> >
> > > Adrian Howard wrote:
> > >
> > >> The better code review sessions I've been involved were more about
> > >> building the right system than they were about preventing mistakes.
> > >> More "We can refactor that out into a new class"
> > >> than "That will die horribly on edge case foo".
> > >
> > > This seems contradictory to me. The first sentence implies an
> > > emphasis on the problem domain, but the second one seems to value
> > > technical matters rather than problem domain. Can I ask you to
> > > clarify, please?
> >
> > Sorry, my poor communication skills again :-)
> >
> > I was trying to say that better code review sessions often focus more
> > on problem domain stuff (refactoring, etc.) than bugs. Good code
> > reviews as much, if not more, about building the right system than
> > they are about spotting and preventing errors.
> >
> > Clarified?
> >
> > Adrian
> >
> > For more information about AM, visit the Agile Modeling Home Page at
> > www.agilemodeling.com
> >
> > For more information about AM, visit the Agile Modeling Home Page at
> > www.agilemodeling.com
> >
> >
> >
>
> For more information about AM, visit the Agile Modeling Home Page at
> www.agilemodeling.com
>
> For more information about AM, visit the Agile Modeling Home Page
> at www.agilemodeling.com
>
>
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[J. B. Rainsberger]

Adrian Howard wrote:

> On Friday, January 30, 2004, at 08:41 pm, Randy Miller wrote:
> [snip]
>
>> Some activities, like code reviews, are
>> clearly preventative. They keep people from making mistakes.

With respect, code reviews are the exact /opposite/ of preventative:
they are clearly post-mortem activities.

A code review happens after the code has been written. By definition, it
cannot be preventative. It can only hope to reduce the likelihood of a
particular class of mistake /recurring/.

Pair programming is preventative: it is a code review that occurs before
the code is even compiled, at a stage when the participants are actually
both willing and able to make changes.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Scott E. Preece]

The literature usually distinguishes between "reviews" and
"inspections".

Reviews are less-formal, less-technical exploration/explanation
meetings, aimed at exploring issues. These range from stakeholder
reviews, which typically give stakeholders an opportunity to look at
the proposed solution, check whether it appears to align with their
understanding of the need, and raise issues to test the solution, to
design reviews, which give the broader community a chance to look
at a design in detail and learn how it works, raise questions about
relationships of components, understand the role of their component
in the overall structure, etc. Reviews typically are larger and
broader, the discussion relatively free-ranging, and usually produce
action items and issues for subsequent reporting to the review team.

Inspections (Basili uses "reading") are narrowly focused on finding
defects in an artifact. They involve a smaller team (typically 3-6
people), the participants have defined roles, there is a moderator,
managers are not allowed to participate (unless they are also technical
contributors). Discussion is strictly limited (no exploration of
responses to an issue raised; even discussion of whether an issue is
actually a defect is deferred if there isn't immediate consensus. In
pure Fagan inspections there is a reader (not the author) who
paraphrases the artifact, line-by-line, to test understanding of the
intent. Defects are categorized for later root-cause analysis and
cataloged for resolution and verification. The participant roles may
include representing specific perspectives (user, tester, factory, etc.)
and readers may use checklists of common issues for the given kind of
artifact. The speed of preparation and inspection are recorded (for
code, 200 lines per hour is a typical target); the organization usually
tracks the rate and has defined control limits validated to maximize
defects found.

Reading the esay that Scott A pointed at a few days ago, what he
described was not a classical inspection, but some kind of cross between
an inspection and a review. A significant number of his issues would
not occur in a well-run Fagan inspection.

Note inspections are verification, not validation - they're not about
seeing whether you did the right thing, but about seeing whether you did
what you did right. Also, the emphasis is NOT on defect prevention, it
is on defect removal. The assumption is that people DO make mistakes.
There is substantial literature demonstrating that it is cheaper to find
defects by inspection than by testing. [As noted previously, most
organizations do still do some testing, so the overall cost needs to be
considered to see whether inspection is justified.]

In an agile methodology, verification would come through testing,
pair programming, collective ownership, and customer involvement.
I don't know of a study specifically looking at the relative merits
of inspection versus those mechanisms, as practice in XP. The XP
practices lean on each other and leverage each other in subtle ways that
make it hard to look at them in isolation. Also, agile methods depend
on iteration (and, implicitly, rework) for validation, so it may be
that using that mechanism for verification is another leverage. Or
not - the field is ripe for study.

scott

| From: Adrian Howard<***@quietstars.com>
| Date: Sun, 1 Feb 2004 20:32:52 +0000
|
| On Friday, January 30, 2004, at 08:41 pm, Randy Miller wrote:
| [snip]
| > Some activities, like code reviews, are
| > clearly preventative. They keep people from making mistakes. Other
| > activities, like requirements gathering, help people build the right
| > system. Or maybe they prevent people from building the wrong system. I
| > found it interesting to look at an activity as a guidance mechanism
| > (with an enabling side and a prevention side) instead of something to
| > hold you down or prop you up. Your message provoke that line of
| > thought.
| [snip]
|
| Interesting point of view. Of course a lot depends on how the activity
| is done.
|
| The better code review sessions I've been involved were more about
| building the right system than they were about preventing mistakes.
| More "We can refactor that out into a new class" than "That will die
| horribly on edge case foo".
|
| I'm sure I'm not alone in having the experience of a large requirements
| gathering process helping build the wrong system :-)
|
| It's interesting that agile practices like TDD and pair programming
| turn find-the-defect activities into drive-the-design activities by
| tightening the feedback loop much as possible.
|
| Adrian


--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: [phone]
phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Scott E. Preece]

Depends on your definition of "preventative" - the purpose of code
inspections is to prevent defects from escaping the phase (and,
ultimately, to the customer).

Presumably pair programming similarly doesn't keep defects from being
written, it just identifies them faster (the person typing is still
going to type the error before the person reading can see what was
typed). [I recognize that in some cases the pair will recognize the
defect in discussion before typing, but that kind of incidental save is
no more preventative than a single programmer re-reading her code before
submitting it for testing - some defects simply don't live long enough
to reach the metrics.]

Training and tools can be preventative in the sense of keeping defects
from occurring to begin with. Test-first coding might help in some
cases (if the coder is also writing the tests and learns in writing the
test what the code has to do to pass the test).

scott

| From: "J. B. Rainsberger" <***@rogers.com>
| 50 -0500
| Date: Mon, 02 Feb 2004 16:47:14 -0500
|
| Adrian Howard wrote:
|
| > On Friday, January 30, 2004, at 08:41 pm, Randy Miller wrote:
| > [snip]
| >
| >> Some activities, like code reviews, are
| >> clearly preventative. They keep people from making mistakes.
|
| With respect, code reviews are the exact /opposite/ of preventative:
| they are clearly post-mortem activities.
|
| A code review happens after the code has been written. By definition, it
| cannot be preventative. It can only hope to reduce the likelihood of a
| particular class of mistake /recurring/.
|
| Pair programming is preventative: it is a code review that occurs before
| the code is even compiled, at a stage when the participants are actually
| both willing and able to make changes.
| --
| J. B. Rainsberger,
| Diaspar Software Services
| http://www.diasparsoftware.com :: [phone]
| Let's write software that people understand
|
| For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
|
|


--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: [phone]
phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Scott Ambler]

Compensatory, not preventative, might be the word that everyone is looking
for. Reviews & inspections compensate for low-communication environments
where insufficient numbers of people work on the item being reviewed. In
high-communication, collective ownership, pairing/working with others type
environments this mistake isn't made and therefore there isn't much value
in compensating for it with an inspection/review.

- Scott

At 04:20 PM 2/2/2004 -0600, you wrote:

>Depends on your definition of "preventative" - the purpose of code
>inspections is to prevent defects from escaping the phase (and,
>ultimately, to the customer).
>
>Presumably pair programming similarly doesn't keep defects from being
>written, it just identifies them faster (the person typing is still
>going to type the error before the person reading can see what was
>typed). [I recognize that in some cases the pair will recognize the
>defect in discussion before typing, but that kind of incidental save is
>no more preventative than a single programmer re-reading her code before
>submitting it for testing - some defects simply don't live long enough
>to reach the metrics.]
>
>Training and tools can be preventative in the sense of keeping defects
>from occurring to begin with. Test-first coding might help in some
>cases (if the coder is also writing the tests and learns in writing the
>test what the code has to do to pass the test).
>
>scott
>
>| From: "J. B. Rainsberger" <***@rogers.com>
>| 50 -0500
>| Date: Mon, 02 Feb 2004 16:47:14 -0500
>|
>| Adrian Howard wrote:
>|
>| > On Friday, January 30, 2004, at 08:41 pm, Randy Miller wrote:
>| > [snip]
>| >
>| >> Some activities, like code reviews, are
>| >> clearly preventative. They keep people from making mistakes.
>|
>| With respect, code reviews are the exact /opposite/ of preventative:
>| they are clearly post-mortem activities.
>|
>| A code review happens after the code has been written. By definition, it
>| cannot be preventative. It can only hope to reduce the likelihood of a
>| particular class of mistake /recurring/.
>|
>| Pair programming is preventative: it is a code review that occurs before
>| the code is even compiled, at a stage when the participants are actually
>| both willing and able to make changes.
>| --
>| J. B. Rainsberger,
>| Diaspar Software Services
>| http://www.diasparsoftware.com :: [phone]
>| Let's write software that people understand
>|
>| For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>|
>|
>
>
>--
>scott preece
>motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
>e-mail: ***@urbana.css.mot.com fax: [phone]
>phone: [phone] cell: 217-433-6114 pager:
>***@msg.myvzw.com
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com

====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[J. B. Rainsberger]

Scott E. Preece wrote:
> Depends on your definition of "preventative" - the purpose of code
> inspections is to prevent defects from escaping the phase (and,
> ultimately, to the customer).

I'll buy that.

> Presumably pair programming similarly doesn't keep defects from being
> written, it just identifies them faster (the person typing is still
> going to type the error before the person reading can see what was
> typed). [I recognize that in some cases the pair will recognize the
> defect in discussion before typing, but that kind of incidental save is
> no more preventative than a single programmer re-reading her code before
> submitting it for testing - some defects simply don't live long enough
> to reach the metrics.]

Agreed: it's just a question of where we find the defect. I placed the
dividing line at "did we integrate yet?" which is releasing to the rest
of the team. You placed the dividing line at "did we release to the
customer yet?" I think there's a considerable difference between the two.

> Training and tools can be preventative in the sense of keeping defects
> from occurring to begin with. Test-first coding might help in some
> cases (if the coder is also writing the tests and learns in writing the
> test what the code has to do to pass the test).

I have never seen Pair Programming without TDD, although I've done TDD
without Pair Programming. I may implicitly assume that Pair Programming
implies TDD. :)
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Gaythorpe, Dagna]

Are both of these refactoring?

1. Split a field into two others (typically, Name into Forename and
Surname.)
2. The warehouse has an internal customer number, and looks up the original
system customer id on a cross reference table. But every report we produce
uses the original id (and a system id). So add the system of origin and the
original id to the customer table on the warehouse.

I wonder if 1 is a design change, and 2 is a refactoring (to save hammering
the cross-reference table, which is narrow, very deep and used in every
update and extract).

(BTW - jargon alert - if anyone wonders what I mean by 'narrow' and 'deep',
'narrow' is the width of a row, 'deep' is the number of rows - this type of
table can be the Marianas Trench of your database.)

But if the users want the name field split, don't waste time wondering what
to call it - that time would be better spent explaining to the person who
designed the database that they messed up and should have thought of this
one, and then finding out that they did, but the contents of Name are in no
clear format - surname + initials, forename + surname, initials + surname,
all in one field in the source system (which isn't this one)...

Regards,

Dagna

Dagna Gaythorpe
Data Architect
International IT
> tttt COLT TELECOM GROUP PLC
> Beaufort House, 15 St Botolph Street,
> London EC3A 7QN
t (+ 44) 020 7 390 7896
f (+ 44) 020 7 947 1176
e ***@colt-telecom.com



-----Original Message-----
From: Jason Gorman [mailto:***@objectmonkey.com
<mailto:***@objectmonkey.com> ]
Sent: 03 February 2004 00:17
To: ***@topica.com
Subject: RE: [AM] Unfounded assertion


Is refactoring "problem domain stuff"? I thought it was about improving the
technical design without changing what the system does. Surely refactoring
is "solution domain"?

Jason Gorman
http://www.objectmonkey.com <http://www.objectmonkey.com>



*************************************************************************************
COLT Telecommunications
Registered in England No. 2452736
Registered Office: Beaufort House, 15 St. Botolph Street, London, EC3A 7QN
Tel. [phone]


This message is subject to and does not create or vary any contractual
relationship between COLT Telecommunications, its subsidiaries or
affiliates ("COLT") and you. Internet communications are not secure
and therefore COLT does not accept legal responsibility for the
contents of this message. Any view or opinions expressed are those of
the author. The message is intended for the addressee only and its
contents and any attached files are strictly confidential. If you have
received it in error, please telephone the number above. Thank you.
*************************************************************************************

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Paul Oldfield]

(responding to J.B.)

> I have never seen Pair Programming without TDD, although I've
> done TDD without Pair Programming. I may implicitly assume
> that Pair Programming implies TDD. :)

Not necessarily.

The situation is complex, but to refactor in safety you need
a full set of regression tests (not necessarily TTD though).
To support Simple Design you need refactoring.
Yet Pair Programming can in theory be done without either
of these. Nice to know, in case you ever find yourself in
such a situation...


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[J. B. Rainsberger]

Paul Oldfield wrote:

> (responding to J.B.)
>
>>I have never seen Pair Programming without TDD, although I've
>>done TDD without Pair Programming. I may implicitly assume
>>that Pair Programming implies TDD. :)
>
> Not necessarily.
>
> The situation is complex, but to refactor in safety you need
> a full set of regression tests (not necessarily TTD though).
> To support Simple Design you need refactoring.
> Yet Pair Programming can in theory be done without either
> of these. Nice to know, in case you ever find yourself in
> such a situation...

I am not claiming that Pair Programming is impossible with TDD. I think
we all understand that that's obviously false. I /am/ mentioning that I
don't know of projects that Pair but do not practise TDD. I'm making an
observation of a correlation; and not describing a rule.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Paul Oldfield]

(responding to Dagna)

> Are both of these refactoring?
>
> 1. Split a field into two others (typically, Name into Forename
> and Surname.)

We're dealing with this in another thread. Names are horrendously
complicated things, with different conventions in different
cultures, then individuals who deliberately try to flout the
conventions, etc., etc., etc. In such an environment it may
be reasonable to expect people to put up with the oddities that
come out of the computer system. If enough people
complain, we could devise a standard name format and
issue them at birth. No, you're right, it will never happen.

The basic problem is that to split an existing name into
Forename/s and Surname, both parts must be there,
and we must know where one part starts and ends. At
present, that information is not held in the database.
Thus while splitting the fields may be a standard
refactoring, dealing with the data is not.

> 2. The warehouse has an internal customer number, and looks
> up the original system customer id on a cross reference table.
> But every report we produce uses the original id (and a system
> id). So add the system of origin and the original id to the customer
> table on the warehouse.
>
> I wonder if 1 is a design change, and 2 is a refactoring (to save
> hammering the cross-reference table, which is narrow, very deep
> and used in every update and extract).

1. is new functionality, not merely a design change; and new
data to support that new functionality. 2. I would class as a
refactoring; the functionality is the same, but the performance
is improved over some of that functionality (probably at the cost
of performance elsewhere?). Don't take that as gospel, that's
an opinion I may be persuaded to change.

> (BTW - jargon alert - if anyone wonders what I mean by 'narrow'
> and 'deep', 'narrow' is the width of a row, 'deep' is the number of
> rows - this type of table can be the Marianas Trench of your
> database.)

Thanks.

> But if the users want the name field split, don't waste time wondering
> what to call it - that time would be better spent explaining to the
> person who designed the database that they messed up and should
> have thought of this one, and then finding out that they did, but the
> contents of Name are in no clear format - surname + initials, forename
> + surname, initials + surname, all in one field in the source system
> (which isn't this one)...

Whatever you do with names, there's going to be the odd few
that just don't fit your assumptions. Your data is *always* going
to be slightly dirty.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Steven Gordon]

I am sorry, but this attitude that the designers of a database are responsible for anticipating the future requirements is a big contributor to making the data side of the enterprise so resistant to agility.

You cannot anticipate future requirements. A new set of users want what the users did not want it 5 years, so learn to live with change. The sin of the past was NOT that the database designers should have thought of this unstated requirement. The sin of the past was that the application developers used the database directly throughout their code. This tight coupling is what makes it hard to change either the database or the applications without changing the other.

Placing the blame on the database designers will just embolden data modelers to waste time trying to perfectly model the whole future of the enterprise before they will risk producing a database design or changing an existing one.

-----Original Message-----
From: Gaythorpe, Dagna [mailto:***@colt-telecom.com]
Sent: Tuesday, February 03, 2004 2:47 AM
To: '***@topica.com'
Subject: RE: [AM] Unfounded assertion


But if the users want the name field split, don't waste time wondering what to call it - that time would be better spent explaining to the person who designed the database that they messed up and should have thought of this one, and then finding out that they did, but the contents of Name are in no clear format - surname + initials, forename + surname, initials + surname, all in one field in the source system (which isn't this one)...
Regards,
Dagna
Dagna Gaythorpe
Data Architect
International IT
tttt COLT TELECOM GROUP PLC
Beaufort House, 15 St Botolph Street,
London EC3A 7QN
t (+ 44) 020 7 390 7896
f (+ 44) 020 7 947 1176
e ***@colt-telecom.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[J. B. Rainsberger]

Steven Gordon wrote:

> -----Original Message-----
> From: Gaythorpe, Dagna [mailto:***@colt-telecom.com]
> Sent: Tuesday, February 03, 2004 2:47 AM
> To: '***@topica.com'
> Subject: RE: [AM] Unfounded assertion
>
>
>> But if the users want the name field split, don't waste time wondering what to call it - that time would be better spent explaining to the person who designed the database that they messed up and should have thought of this one, and then finding out that they did, but the contents of Name are in no clear format - surname + initials, forename + surname, initials + surname, all in one field in the source system (which isn't this one)...

> You cannot anticipate future requirements.

Hear, hear! If we /could/ anticipate future requirements, we'd have each
won the bloody lottery by now and wouldn't be hanging around here, now
would we?!
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Scott E. Preece]

| From: "J. B. Rainsberger" <***@rogers.com>
|
| Scott E. Preece wrote:
| > Presumably pair programming similarly doesn't keep defects from being
| > written, it just identifies them faster (the person typing is still
| > going to type the error before the person reading can see what was
| > typed). [I recognize that in some cases the pair will recognize the
| > defect in discussion before typing, but that kind of incidental save is
| > no more preventative than a single programmer re-reading her code before
| > submitting it for testing - some defects simply don't live long enough
| > to reach the metrics.]
|
| Agreed: it's just a question of where we find the defect. I placed the
| dividing line at "did we integrate yet?" which is releasing to the rest
| of the team. You placed the dividing line at "did we release to the
| customer yet?" I think there's a considerable difference between the two.
---

I'm missing what you're trying to say here - inspections would normally
be done before integration (that is, before the code branch switches
from private to public).

scott
--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: [phone]
phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[J. B. Rainsberger]

Scott E. Preece wrote:
> | From: "J. B. Rainsberger" <***@rogers.com>
> |
> | Scott E. Preece wrote:
> | > Presumably pair programming similarly doesn't keep defects from being
> | > written, it just identifies them faster (the person typing is still
> | > going to type the error before the person reading can see what was
> | > typed). [I recognize that in some cases the pair will recognize the
> | > defect in discussion before typing, but that kind of incidental save is
> | > no more preventative than a single programmer re-reading her code before
> | > submitting it for testing - some defects simply don't live long enough
> | > to reach the metrics.]
> |
> | Agreed: it's just a question of where we find the defect. I placed the
> | dividing line at "did we integrate yet?" which is releasing to the rest
> | of the team. You placed the dividing line at "did we release to the
> | customer yet?" I think there's a considerable difference between the two.
> ---
>
> I'm missing what you're trying to say here - inspections would normally
> be done before integration (that is, before the code branch switches
> from private to public).

"Code branch"?! I don't want to get into a discussion of code branches.

It appears that you're saying we inspect code before we integrate it.
That's already several times per day on my projects. If we're inspecting
code that often, we might as well do it continuously: the
context-switching costs of running three-to-five code separate
inspections per programmer per day are quite high.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Paul Oldfield]

(responding to Steven)

> I am sorry, but this attitude that the designers of a database
> are responsible for anticipating the future requirements is a
> big contributor to making the data side of the enterprise so
> resistant to agility.
>
> You cannot anticipate future requirements...

You can, but not reliably. Okay, I'm being picky.

> ... A new set of users want what the users did not want it 5
> years, so learn to live with change. The sin of the past
> was NOT that the database designers should have
> thought of this unstated requirement. The sin of the past
> was that the application developers used the database
> directly throughout their code.

One of the sins... Okay, I'm being picky.

> This tight coupling is what makes it hard to change either
> the database or the applications without changing the
> other.
>
> Placing the blame on the database designers will just
> embolden data modelers to waste time trying to perfectly
> model the whole future of the enterprise before they will risk
> producing a database design or changing an existing one.

Agreed, if we take that line, we risk that result. Don't throw
blame about; what we need are ways forward. Stop doing
the bad things, start fixing the problems with the bad things that
have been done. Learn how to make change easier and
cheaper.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[M***@Graybill.com]

Your assertion is a bit absolute. Even in
high-communication environments, mistakes can be made -
simply because of a difference in a recent experience
for instance, which primes the developers' thought
processes in such a way information is lost.

There are many objectives in and motivations for code
reviews - such would have to be defined, depending on
the complexity of the system before any such statements
can be made. Also, I suspect the veracity of such a
statement even if both programmers are experts in the
domain and technology, which in my experience is seldom
the case.

For instance, both in a development-pair team can be
slack on standards requirements for code, if they exist
(e.g. FAA, FDA); or inexperienced with a specialty in
the problem domain or technical domain.

Code reviews can bring experts in to catch such things
while potentially shedding light on details missed just
because we are human.

Even if we were connected to the Borg Collective of a
super efficient software development Tiger team, we can
still get in the way.

Mark.

On Tue, 03 Feb 2004 07:57:38 -0500, Scott Ambler wrote:

>
>
> Compensatory, not preventative, might be the word that
> everyone is looking
> for. Reviews & inspections compensate for
> low-communication environments
> where insufficient numbers of people work on the item
> being reviewed. In
> high-communication, collective ownership,
> pairing/working with others type
> environments this mistake isn't made and therefore
> there isn't much value
> in compensating for it with an inspection/review.
>
> - Scott
>
> At 04:20 PM 2/2/2004 -0600, you wrote:
>
> >Depends on your definition of "preventative" - the
> purpose of code
> >inspections is to prevent defects from escaping the
> phase (and,
> >ultimately, to the customer).
> >
> >Presumably pair programming similarly doesn't keep
> defects from being
> >written, it just identifies them faster (the person
> typing is still
> >going to type the error before the person reading can
> see what was
> >typed). [I recognize that in some cases the pair will
> recognize the
> >defect in discussion before typing, but that kind of
> incidental save is
> >no more preventative than a single programmer
> re-reading her code before
> >submitting it for testing - some defects simply don't
> live long enough
> >to reach the metrics.]
> >
> >Training and tools can be preventative in the sense
of
> keeping defects
> >from occurring to begin with. Test-first coding
might
> help in some
> >cases (if the coder is also writing the tests and
> learns in writing the
> >test what the code has to do to pass the test).
> >
> >scott
> >
> >| From: "J. B. Rainsberger" <***@rogers.com>
> >| 50 -0500
> >| Date: Mon, 02 Feb 2004 16:47:14 -0500
> >|
> >| Adrian Howard wrote:
> >|
> >| > On Friday, January 30, 2004, at 08:41 pm, Randy
> Miller wrote:
> >| > [snip]
> >| >
> >| >> Some activities, like code reviews, are
> >| >> clearly preventative. They keep people from
> making mistakes.
> >|
> >| With respect, code reviews are the exact /opposite/
> of preventative:
> >| they are clearly post-mortem activities.
> >|
> >| A code review happens after the code has been
> written. By definition, it
> >| cannot be preventative. It can only hope to reduce
> the likelihood of a
> >| particular class of mistake /recurring/.
> >|
> >| Pair programming is preventative: it is a code
> review that occurs before
> >| the code is even compiled, at a stage when the
> participants are actually
> >| both willing and able to make changes.
> >| --
> >| J. B. Rainsberger,
> >| Diaspar Software Services
> >| http://www.diasparsoftware.com :: [phone]
> >| Let's write software that people understand
> >|
> >| For more information about AM, visit the Agile
> Modeling Home Page at
> >www.agilemodeling.com
> >|
> >|
> >
> >
> >--
> >scott preece
> >motorola urbana design center (il67), 1800 s. oak
st.,
> champaign, il 61820
> >e-mail: ***@urbana.css.mot.com fax:
> 217-384-8550
> >phone: [phone] cell: 217-433-6114
pager:
> >***@msg.myvzw.com
> >
> >For more information about AM, visit the Agile
> Modeling Home Page at
> >www.agilemodeling.com
>
> ====================================================
> Scott W. Ambler
> Senior Consultant, Ronin International, Inc.
> www.ronin-intl.com/company/scottAmbler.html
>
> www.agiledata.org
> www.agilemodeling.com
> www.ambysoft.com
> www.enterpriseunifiedprocess.info
> www.modelingstyle.info
> www.ronin-intl.com
>
> For more information about AM, visit the Agile
Modeling
> Home Page at www.agilemodeling.com
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"The significant problems we face cannot be solved at
the same level of thinking we were at when we created
them." - Albert Einstein

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Stephen Cohen]

The benefits of code reviews can go beyond simply finding bugs in the
product. It is a chance to extend the boundaries of collective
ownership. Reviews provide an opportunity for the team to identify and
promote good work from a project up to an enterprise repository. Like
wise, it allows the project teams to cross-pollinate lessons learned and
techniques.

Of course there is the potential of public humiliation but that too can
net broadly positive results if handled gently "-)

-- Stephen

-----Original Message-----
From: Scott Ambler [mailto:***@ronin-intl.com]
Sent: Tuesday, February 03, 2004 7:58 AM
To: ***@topica.com
Subject: Re: [AM] Code reviews preventative?


Compensatory, not preventative, might be the word that everyone is
looking
for. Reviews & inspections compensate for low-communication
environments
where insufficient numbers of people work on the item being reviewed.
In
high-communication, collective ownership, pairing/working with others
type
environments this mistake isn't made and therefore there isn't much
value
in compensating for it with an inspection/review.

- Scott

At 04:20 PM 2/2/2004 -0600, you wrote:

>Depends on your definition of "preventative" - the purpose of code
>inspections is to prevent defects from escaping the phase (and,
>ultimately, to the customer).
>
>Presumably pair programming similarly doesn't keep defects from being
>written, it just identifies them faster (the person typing is still
>going to type the error before the person reading can see what was
>typed). [I recognize that in some cases the pair will recognize the
>defect in discussion before typing, but that kind of incidental save is
>no more preventative than a single programmer re-reading her code
before
>submitting it for testing - some defects simply don't live long enough
>to reach the metrics.]
>
>Training and tools can be preventative in the sense of keeping defects
>from occurring to begin with. Test-first coding might help in some
>cases (if the coder is also writing the tests and learns in writing the
>test what the code has to do to pass the test).
>
>scott
>
>| From: "J. B. Rainsberger" <***@rogers.com>
>| 50 -0500
>| Date: Mon, 02 Feb 2004 16:47:14 -0500
>|
>| Adrian Howard wrote:
>|
>| > On Friday, January 30, 2004, at 08:41 pm, Randy Miller wrote:
>| > [snip]
>| >
>| >> Some activities, like code reviews, are
>| >> clearly preventative. They keep people from making mistakes.
>|
>| With respect, code reviews are the exact /opposite/ of preventative:
>| they are clearly post-mortem activities.
>|
>| A code review happens after the code has been written. By definition,
it
>| cannot be preventative. It can only hope to reduce the likelihood of
a
>| particular class of mistake /recurring/.
>|
>| Pair programming is preventative: it is a code review that occurs
before
>| the code is even compiled, at a stage when the participants are
actually
>| both willing and able to make changes.
>| --
>| J. B. Rainsberger,
>| Diaspar Software Services
>| http://www.diasparsoftware.com :: [phone]
>| Let's write software that people understand
>|
>| For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>|
>|
>
>
>--
>scott preece
>motorola urbana design center (il67), 1800 s. oak st., champaign, il
61820
>e-mail: ***@urbana.css.mot.com fax: [phone]
>phone: [phone] cell: 217-433-6114 pager:
>***@msg.myvzw.com
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com

====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[J. B. Rainsberger]

Stephen Cohen wrote:

> The benefits of code reviews can go beyond simply finding bugs in the
> product. It is a chance to extend the boundaries of collective
> ownership. Reviews provide an opportunity for the team to identify and
> promote good work from a project up to an enterprise repository. Like
> wise, it allows the project teams to cross-pollinate lessons learned and
> techniques.

All agreed. I suppose Promiscuous Pair Programming is the practice I
prefer to use in order to gain the benefits you describe. I have had
good and bad experiences with each, but I find pairing provides more
gain precisely because it is continuous -- it is easier to heed the
advice given, precisely because it is timely.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Steven Gordon]

Yes, team code reviews are useful for many things, including
- the promotion (or possible refinement) of standards,
- the identification of code smells (especially duplication that no one person is aware of),
- awareness of code some people might have not worked with yet, and
- the identification of objects or patterns that are reusable or relevant to upcoming stories.

In the context of a culture/metholodgy that promotes collective ownership, there is no reason for public humiliation. Simply review the code. We want intensional code, so the code should be able to speak for itself. The author of the code is the team, not the person/pair who wrote a fragment of it first or modified it last. Doing this will help reenforce collective ownership.

Steven Gordon
http://sf.asu.edu/

-----Original Message-----
From: Stephen Cohen [mailto:***@microsoft.com]
Sent: Tue 2/3/2004 8:42 PM
To: ***@topica.com
Cc:
Subject: RE: [AM] Code reviews preventative?

The benefits of code reviews can go beyond simply finding bugs in the
product. It is a chance to extend the boundaries of collective
ownership. Reviews provide an opportunity for the team to identify and
promote good work from a project up to an enterprise repository. Like
wise, it allows the project teams to cross-pollinate lessons learned and
techniques.

Of course there is the potential of public humiliation but that too can
net broadly positive results if handled gently "-)

-- Stephen

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Gaythorpe, Dagna]

This one got me all fired up...

A database designer won't be able to anticipate all the future requirements,
at least not until Oracle TM comes out. (TM - Telepathic Module, that does
it all automagically). But we can (or, at least, I can, and I don't think I
am that unusual!) work out that if a field is made up of compound data (like
initials + surname, or quantity multiplied by price to give net value), then
someone is going to look at it and want to get at the elements. (The price
per unit.) What the designer must do is to catch the compound stuff early
and either break it down, or explain to the business clearly, and written in
blood (theirs) that this field may look like a compound field, but it isn't
and the only way they can break it out in the future is to get the data
quality team to fix the underlying data. (And if they don't have a DQ team
(even a team of one person), then they may be in more trouble than they
realise.)

If the database is going to be getting stuff in from other systems in the
future (maybe you are building a warehouse), and you know what they are (or
should be, or may be) and what is in them, then it is a good idea to design
your early phases with the later stuff in mind - like other customer types,
or fancy stuff with taxes and levies that will come in with the commercial
customers once you have the domestic data nailed. (I used to work for a
large utility company.)

My design may not cope with the way the company does business in five years.
In five years, the processes will have changed, and so will the business.
And that is normal, expected, and why new systems get written. The old ones
keep on running, because while we are doing new stuff, we still sell the
original product. (Five years is a very long time - unless the business has
a hugely long product development cycle.) But if my design falls over within
six months because my basic analysis was sloppy, or because I didn't listen
when I sat with the users and they showed me how they do their jobs, then I
am sloppy, incompetent, and maybe need a refresher basic data analysis
course. And a kicking from my manager.

I don't model the future of the enterprise. I model an enterprise that can
change without too much pain. If your data people have the quaint belief
that the enterprise is a solid, monolithic thing that will never change,
then encourage them to wake up and join the real world. They could start by
going to a presentation by John Zachman, on how the enterprise will change,
no-one knows how (not even the people running it), and how it can survive.
(His presentations tend to leave the audience feeling pretty breathless).
And if your enterprise is a solid, monolithic thing that will never change,
then get on as many training courses as you can, keep your cv (resume) up to
date, and wait for the redundancy payoff.

We can't anticipate change, but we must design to allow it.

(Another option is to hire me at a suitably immense salary... <g>)

Regards,

Dagna

> -----Original Message-----
> From: Steven Gordon [mailto:***@asu.edu]
> Sent: 03 February 2004 18:54
> To: ***@topica.com
> Subject: RE: [AM] Unfounded assertion
>
>
> I am sorry, but this attitude that the designers of a
> database are responsible for anticipating the future
> requirements is a big contributor to making the data side of
> the enterprise so resistant to agility.
>
> You cannot anticipate future requirements. A new set of
> users want what the users did not want it 5 years, so learn
> to live with change. The sin of the past was NOT that the
> database designers should have thought of this unstated
> requirement. The sin of the past was that the application
> developers used the database directly throughout their code.
> This tight coupling is what makes it hard to change either
> the database or the applications without changing the other.
>
> Placing the blame on the database designers will just
> embolden data modelers to waste time trying to perfectly
> model the whole future of the enterprise before they will
> risk producing a database design or changing an existing one.
>
> -----Original Message-----
> From: Gaythorpe, Dagna [mailto:***@colt-telecom.com]
> Sent: Tuesday, February 03, 2004 2:47 AM
> To: '***@topica.com'
> Subject: RE: [AM] Unfounded assertion
>
>
> But if the users want the name field split, don't waste time
> wondering what to call it - that time would be better spent
> explaining to the person who designed the database that they
> messed up and should have thought of this one, and then
> finding out that they did, but the contents of Name are in no
> clear format - surname + initials, forename + surname,
> initials + surname, all in one field in the source system
> (which isn't this one)...
> Regards,
> Dagna
> Dagna Gaythorpe
> Data Architect
> International IT
> tttt COLT TELECOM GROUP PLC
> Beaufort House, 15 St Botolph Street,
> London EC3A 7QN
> t (+ 44) 020 7 390 7896
> f (+ 44) 020 7 947 1176
> e ***@colt-telecom.com
>
> For more information about AM, visit the Agile Modeling Home
> Page at www.agilemodeling.com
>


*************************************************************************************
COLT Telecommunications
Registered in England No. 2452736
Registered Office: Beaufort House, 15 St. Botolph Street, London, EC3A 7QN
Tel. [phone]


This message is subject to and does not create or vary any contractual
relationship between COLT Telecommunications, its subsidiaries or
affiliates ("COLT") and you. Internet communications are not secure
and therefore COLT does not accept legal responsibility for the
contents of this message. Any view or opinions expressed are those of
the author. The message is intended for the addressee only and its
contents and any attached files are strictly confidential. If you have
received it in error, please telephone the number above. Thank you.
*************************************************************************************

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Scott Ambler]

At 10:43 AM 2/4/2004 +0000, you wrote:

>This one got me all fired up...
>
>A database designer won't be able to anticipate all the future
>requirements, at least not until Oracle TM comes out. (TM - Telepathic
>Module, that does it all automagically). But we can (or, at least, I can,
>and I don't think I am that unusual!) work out that if a field is made up
>of compound data (like initials + surname, or quantity multiplied by price
>to give net value), then someone is going to look at it and want to get at
>the elements. (The price per unit.)

What you can do is suggest the new requirement, to deal with it as a
compound field, and see what your stakeholders say. If it's a good idea,
and it often is, then they'll go for it. If not, I wouldn't overbuild the
software.


> What the designer must do is to catch the compound stuff early and
> either break it down, or explain to the business clearly, and written in
> blood (theirs) that this field may look like a compound field, but it
> isn't and the only way they can break it out in the future is to get the
> data quality team to fix the underlying data. (And if they don't have a
> DQ team (even a team of one person), then they may be in more trouble
> than they realise.)
>
>If the database is going to be getting stuff in from other systems in the
>future (maybe you are building a warehouse), and you know what they are
>(or should be, or may be) and what is in them, then it is a good idea to
>design your early phases with the later stuff in mind - like other
>customer types, or fancy stuff with taxes and levies that will come in
>with the commercial customers once you have the domestic data nailed. (I
>used to work for a large utility company.)

Once again, I'd avoid overbuilding it. If your database is easy to change,
then you don't need to overbuild. If it isn't easy to change, I'd start
refactoring it and the things that touch it so that it becomes easy to change.

Worst case I'd incrementally add the features that I need and let the
legacy data sources constrain me as you imply (raising my development
costs). But I wouldn't try to do it all at once.



>My design may not cope with the way the company does business in five
>years. In five years, the processes will have changed, and so will the
>business. And that is normal, expected, and why new systems get written.
>The old ones keep on running, because while we are doing new stuff, we
>still sell the original product. (Five years is a very long time - unless
>the business has a hugely long product development cycle.) But if my
>design falls over within six months because my basic analysis was sloppy,
>or because I didn't listen when I sat with the users and they showed me
>how they do their jobs, then I am sloppy, incompetent, and maybe need a
>refresher basic data analysis course. And a kicking from my manager.

Yes, you need to take legacy concerns into account. Your architecture
should take potential future concerns, perhaps by exploring change cases
(http://www.agilemodeling.com/artifacts/changeCase.htm), into account but
that doesn't mean you need to overbuild. You need to find the sweet spot
between taking no constraints into account and doing BDUF. Different
projects, different answer to this question.



>I don't model the future of the enterprise.

Perhaps you can, check out the URL above.

> I model an enterprise that can change without too much pain. If your
> data people have the quaint belief that the enterprise is a solid,
> monolithic thing that will never change, then encourage them to wake up
> and join the real world. They could start by going to a presentation by
> John Zachman, on how the enterprise will change, no-one knows how (not
> even the people running it), and how it can survive. (His presentations
> tend to leave the audience feeling pretty breathless). And if your
> enterprise is a solid, monolithic thing that will never change, then get
> on as many training courses as you can, keep your cv (resume) up to date,
> and wait for the redundancy payoff.
>
>We can't anticipate change, but we must design to allow it.

Exactly what changes cases help you to do.


>(Another option is to hire me at a suitably immense salary... <g>)
>
>Regards,
>
>Dagna


- Scott

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[J. B. Rainsberger]

Gaythorpe, Dagna wrote:

<snip />
> But we can (or, at least, I
> can, and I don't think I am that unusual!) work out that if a field is
> made up of compound data (like initials + surname, or quantity
> multiplied by price to give net value), then someone is going to look at
> it and want to get at the elements. (The price per unit.)

On this the Agile community and those generally outside the Agile
community disagree and will likely always disagree. One of the
fundamental differences between Agile practitioners and everyone else
/seems to be/ that Agile practitioners treat speculative design as a
liability, whereas others treat speculative design as an asset.

On an unrelated note, it is a commonly-held belief that one's home is an
asset, even while there is a mortgage to be paid; whereas a minority of
people view it as a liability until the mortgage is paid in full. I only
mention this because the preceding paragraph made me think about it.
Meditate on the potential analogy as you see fit.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Jonathan Kern]

> /seems to be/ that Agile practitioners treat speculative design as a
> liability, whereas others treat speculative design as an asset.

Hmmm. I hope not. Maybe I misunderstand "speculative design?" Do you mean
inquisitive or speculative in the investment sense?

I view having an agile model and environment such that one can absorb and
react to change in a rapid manner.

-- jon



> -----Original Message-----
> From: J. B. Rainsberger [mailto:***@rogers.com]
> Sent: Wednesday, February 04, 2004 12:33 PM
> To: ***@topica.com
> Subject: Re: [AM] Unfounded assertion
>
>
> Gaythorpe, Dagna wrote:
>
> <snip />
> > But we can (or, at least, I
> > can, and I don't think I am that unusual!) work out that if a field is
> > made up of compound data (like initials + surname, or quantity
> > multiplied by price to give net value), then someone is going
> to look at
> > it and want to get at the elements. (The price per unit.)
>
> On this the Agile community and those generally outside the Agile
> community disagree and will likely always disagree. One of the
> fundamental differences between Agile practitioners and everyone else
> /seems to be/ that Agile practitioners treat speculative design as a
> liability, whereas others treat speculative design as an asset.
>
> On an unrelated note, it is a commonly-held belief that one's home is an
> asset, even while there is a mortgage to be paid; whereas a minority of
> people view it as a liability until the mortgage is paid in full. I only
> mention this because the preceding paragraph made me think about it.
> Meditate on the potential analogy as you see fit.
> --
> J. B. Rainsberger,
> Diaspar Software Services
> http://www.diasparsoftware.com :: [phone]
> Let's write software that people understand
>
> For more information about AM, visit the Agile Modeling Home Page
> at www.agilemodeling.com
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[J. B. Rainsberger]

Jonathan Kern wrote:

>>/seems to be/ that Agile practitioners treat speculative design as a
>>liability, whereas others treat speculative design as an asset.
>
> Hmmm. I hope not. Maybe I misunderstand "speculative design?" Do you mean
> inquisitive or speculative in the investment sense?

By "speculative design" I refer to design elements that do not solve the
problem as we know it today, but rather are focused on solving parts of
the problem that we guess are coming. These are design elements that
address problems or features about whose future existence we speculate.

> I view having an agile model and environment such that one can absorb and
> react to change in a rapid manner.

I was referring to speculation in the sense of anticipating change,
possibly with no actual sign that such change may be forthcoming.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Jonathan Kern]

> I was referring to speculation in the sense of anticipating change,
> possibly with no actual sign that such change may be forthcoming.

Ahh. It is a fine line... You should properly model your system in the best
manner possible for your known requirements. You can apply some guesswork
about possible future direction. When doing so, this usually has the effect
about swaying your design one way or another -- with little difference in
current cost.

If it costs you nothing to design one way that gives a probable future
feature an easy time of coming to life in a least disruptive manner, this is
a good thing. It relies on your sense that this probably future feature is a
good bet. It also relies on the cost of going down Path A is nor more than
Path B.

To go down Path C that costs a fortune and has very little likelihood of
coming to fruition, this is irresponsible.


-- jon



> -----Original Message-----
> From: J. B. Rainsberger [mailto:***@rogers.com]
> Sent: Monday, February 09, 2004 3:02 PM
> To: ***@topica.com
> Subject: Re: Use change strategically was RE: [AM] Unfounded assertion
>
>
> Jonathan Kern wrote:
>
> >>/seems to be/ that Agile practitioners treat speculative design as a
> >>liability, whereas others treat speculative design as an asset.
> >
> > Hmmm. I hope not. Maybe I misunderstand "speculative design?"
> Do you mean
> > inquisitive or speculative in the investment sense?
>
> By "speculative design" I refer to design elements that do not solve the
> problem as we know it today, but rather are focused on solving parts of
> the problem that we guess are coming. These are design elements that
> address problems or features about whose future existence we speculate.
>
> > I view having an agile model and environment such that one can
> absorb and
> > react to change in a rapid manner.
>
> I was referring to speculation in the sense of anticipating change,
> possibly with no actual sign that such change may be forthcoming.
> --
> J. B. Rainsberger,
> Diaspar Software Services
> http://www.diasparsoftware.com :: [phone]
> Let's write software that people understand
>
> For more information about AM, visit the Agile Modeling Home Page
> at www.agilemodeling.com
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[J. B. Rainsberger]

Jonathan Kern wrote:

>>I was referring to speculation in the sense of anticipating change,
>>possibly with no actual sign that such change may be forthcoming.
>
> Ahh. It is a fine line... You should properly model your system in the best
> manner possible for your known requirements. You can apply some guesswork
> about possible future direction. When doing so, this usually has the effect
> about swaying your design one way or another -- with little difference in
> current cost.

That is not my experience.

> If it costs you nothing to design one way that gives a probable future
> feature an easy time of coming to life in a least disruptive manner, this is
> a good thing.

If I knew which features my customer really needed ahead of time, I'd
quit, buy a lottery ticket and relax. Since my customer doesn't even
know which features he'll need, what chance do I have?

(The implication is correct, but I doubt the hypothesis.)
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Hubert Matthews]

"J. B. Rainsberger" wrote:

> On this the Agile community and those generally outside the Agile community disagree and
> will likely always disagree. One of the fundamental differences between Agile practitioners
> and everyone else /seems to be/ that Agile practitioners treat speculative design as a
> liability, whereas others treat speculative design as an asset.

If you define an asset as something that puts money in your pocket, then agility is doing only
those things the customer is prepared to pay for now. Manufacturing businesses have for a
long time recognised that work-in-progress (i.e. inventory) is undesirable, despite how
accountants like to label things. Design-in-progress, i.e. unbilled-for work, is even more
likely to lose its value so let's do only those things for which we can send out an invoice.
Until it's sold it's an expense.

It's all about improving your cashflow and therefore staying in business.

--
Hubert Matthews http://www.oxyware.com/
Software Consultant ***@oxyware.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Scott E. Preece]

By "code branch" I mean a private view of the code (which would be
shared by people working together on the code). By "integrate" I mean
"release for use by others with a promise that it is known to work".
In our environment (ClearCase) that would mean moving the code to
the main line.

"Integration" may mean different things to different people. Our process
would typically involve (a) the developer working with the code on a
private branch, (b) the developer unit testing the code on that branch,
(c) the developer synching the branch with the main line by merging any
main line changes down into the development branch (pre-integrating),
(d) the user building the whole system and running a defined set of
integration tests, (e) the user moving the code to the main branch, (f)
the user doing a system build and running the integration tests again,
(g) the configuration management team moving the label to the new
version. We would call (g) "Integrated". Inspections would usually
happen between after (c) and before (e), the exact point depending on
the project and the specifics of the development (based on an evaluation
of the risks involved).

Note that going to smaller cycles reduces the time spent in steps (a)
and (b) (and, therefore, the probability of interfering integrations
requiring merging), but if ALL the developers are doing several
integrations a day, that drives the risk or interference right back up.

Our rule is that code is never allowed on the main line (where others
will pick it up in their builds) until it has been inspected and built
on the development branch. Breaking the build is a major sin.

If you're really integrating several times a day, then the integrations
must be small, so the inspections would also be small. You could also
batch the inspections (have one group of inspectors do several small
readings in one session).

scott



| From: "J. B. Rainsberger" <***@rogers.com>
| 50 -0500
| Date: Tue, 03 Feb 2004 18:36:11 -0500
|
| Scott E. Preece wrote:
| > | From: "J. B. Rainsberger" <***@rogers.com>
| > |
| > | Scott E. Preece wrote:
| > | > Presumably pair programming similarly doesn't keep defects from being
| > | > written, it just identifies them faster (the person typing is still
| > | > going to type the error before the person reading can see what was
| > | > typed). [I recognize that in some cases the pair will recognize the
| > | > defect in discussion before typing, but that kind of incidental save is
| > | > no more preventative than a single programmer re-reading her code before
| > | > submitting it for testing - some defects simply don't live long enough
| > | > to reach the metrics.]
| > |
| > | Agreed: it's just a question of where we find the defect. I placed the
| > | dividing line at "did we integrate yet?" which is releasing to the rest
| > | of the team. You placed the dividing line at "did we release to the
| > | customer yet?" I think there's a considerable difference between the two.
| > ---
| >
| > I'm missing what you're trying to say here - inspections would normally
| > be done before integration (that is, before the code branch switches
| > from private to public).
|
| "Code branch"?! I don't want to get into a discussion of code branches.
|
| It appears that you're saying we inspect code before we integrate it.
| That's already several times per day on my projects. If we're inspecting
| code that often, we might as well do it continuously: the
| context-switching costs of running three-to-five code separate
| inspections per programmer per day are quite high.
| --
| J. B. Rainsberger,
| Diaspar Software Services
| http://www.diasparsoftware.com :: [phone]
| Let's write software that people understand
|
| For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
|
|


--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: [phone]
phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Stephen Cohen]

I haven't spent a lot of time pair programming ...
How do you share approaches or warn of identified issues, across
projects? How is the knowledge circulated though out an enterprise?

I am accustomed to working on large programs with many concurrent
projects. While high-communication methods work very well within a
project I have found it difficult to maintain across an entire program.

-- Stephen
-----Original Message-----
From: J. B. Rainsberger [mailto:***@rogers.com]
Sent: Wednesday, February 04, 2004 12:28 PM
To: ***@topica.com
Subject: Re: [AM] Code reviews preventative?

Stephen Cohen wrote:

> The benefits of code reviews can go beyond simply finding bugs in the
> product. It is a chance to extend the boundaries of collective
> ownership. Reviews provide an opportunity for the team to identify
and
> promote good work from a project up to an enterprise repository. Like
> wise, it allows the project teams to cross-pollinate lessons learned
and
> techniques.

All agreed. I suppose Promiscuous Pair Programming is the practice I
prefer to use in order to gain the benefits you describe. I have had
good and bad experiences with each, but I find pairing provides more
gain precisely because it is continuous -- it is easier to heed the
advice given, precisely because it is timely.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[J. B. Rainsberger]

Stephen Cohen wrote:

> I haven't spent a lot of time pair programming ...
> How do you share approaches or warn of identified issues, across
> projects? How is the knowledge circulated though out an enterprise?

Either by formal presentations or by rotating individuals across teams.

> I am accustomed to working on large programs with many concurrent
> projects. While high-communication methods work very well within a
> project I have found it difficult to maintain across an entire program.

I'm not convinced that communication across projects is so important:
each project has its own local conditions, including the specific people
involved, the tools, the schedule... so much so that I doubt there is
much of practical use that straddles multiple teams.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone]
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Jason Gorman]

Port and cigars?

-----Original Message-----
From: J. B. Rainsberger [mailto:***@rogers.com]
Sent: 06 February 2004 23:19
To: ***@topica.com
Subject: [AM] Sharing information across the enterprise

Stephen Cohen wrote:

> I haven't spent a lot of time pair programming ...
> How do you share approaches or warn of identified issues, across
> projects? How is the knowledge circulated though out an enterprise?

Either by formal presentations or by rotating individuals across teams.

> I am accustomed to working on large programs with many concurrent
> projects. While high-communication methods work very well within a
> project I have found it difficult to maintain across an entire program.

I'm not convinced that communication across projects is so important:
each project has its own local conditions, including the specific people
involved, the tools, the schedule... so much so that I doubt there is much
of practical use that straddles multiple teams.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone] Let's write software that
people understand

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Steven Gordon]

I have not worked on a product line since well before discovering agility, but ever since then I have been wanting to try out the following strategy when I get the right opportunity:

1. You have project teams and one product line team.
2. The product line team consists of a pool of senior developers, each of whom:
- Is an active member of one of the projects teams (perhaps rotating among the project teams every month or 2).
- Meets for a few hours every week with the other members of the product line team to talk about global issues and solutions.
- Looks for components, patterns, practices, etc. in their project that should be shared with the other projects.
- Promotes the reuse in their project of the things that have been accumulated from the other projects.
3. If the shared components get large and complex enough, it could be worth considering having a separate project team or a subset of the product line team refactor them into an appropriate framework.

Replace "product line" with "enterprise", if you like.

Steven A. Gordon, Ph.D.
Manager, Software Factory
Arizona State University
PO Box 875506
Tempe, AZ 85287-9509
http://sf.asu.edu
(480)-727-6271


-----Original Message-----
From: J. B. Rainsberger [mailto:***@rogers.com]
Sent: 06 February 2004 23:19
To: ***@topica.com
Subject: [AM] Sharing information across the enterprise

Stephen Cohen wrote:

> I haven't spent a lot of time pair programming ...
> How do you share approaches or warn of identified issues, across
> projects? How is the knowledge circulated though out an enterprise?

Either by formal presentations or by rotating individuals across teams.

> I am accustomed to working on large programs with many concurrent
> projects. While high-communication methods work very well within a
> project I have found it difficult to maintain across an entire program.

I'm not convinced that communication across projects is so important:
each project has its own local conditions, including the specific people
involved, the tools, the schedule... so much so that I doubt there is much
of practical use that straddles multiple teams.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: [phone] Let's write software that
people understand

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Scott Ambler]

Sounds really close to what I talk about at
http://www.agiledata.org/essays/enterpriseArchitecture.html and
www.agilemodeling.com/essays/agileArchitecture.htm.

Other solutions, as Jason implied, include:
1. Getting together and talking with other people over drinks, or at a
softball game, ...
2. Your informal network of people.
3. The "less effective" forms of communication, such as email, documents, ...

- Scott

At 04:54 PM 2/6/2004 -0700, you wrote:
>I have not worked on a product line since well before discovering agility,
>but ever since then I have been wanting to try out the following strategy
>when I get the right opportunity:
>
>1. You have project teams and one product line team.
>2. The product line team consists of a pool of senior developers, each of
>whom:
>- Is an active member of one of the projects teams (perhaps rotating among
>the project teams every month or 2).
>- Meets for a few hours every week with the other members of the product
>line team to talk about global issues and solutions.
>- Looks for components, patterns, practices, etc. in their project that
>should be shared with the other projects.
>- Promotes the reuse in their project of the things that have been
>accumulated from the other projects.
>3. If the shared components get large and complex enough, it could be
>worth considering having a separate project team or a subset of the
>product line team refactor them into an appropriate framework.
>
>Replace "product line" with "enterprise", if you like.
>
>Steven A. Gordon, Ph.D.
>Manager, Software Factory
>Arizona State University
>PO Box 875506
>Tempe, AZ 85287-9509
>http://sf.asu.edu
>(480)-727-6271
>
>
>-----Original Message-----
>From: J. B. Rainsberger [mailto:***@rogers.com]
>Sent: 06 February 2004 23:19
>To: ***@topica.com
>Subject: [AM] Sharing information across the enterprise
>
>Stephen Cohen wrote:
>
> > I haven't spent a lot of time pair programming ...
> > How do you share approaches or warn of identified issues, across
> > projects? How is the knowledge circulated though out an enterprise?
>
>Either by formal presentations or by rotating individuals across teams.
>
> > I am accustomed to working on large programs with many concurrent
> > projects. While high-communication methods work very well within a
> > project I have found it difficult to maintain across an entire program.
>
>I'm not convinced that communication across projects is so important:
>each project has its own local conditions, including the specific people
>involved, the tools, the schedule... so much so that I doubt there is much
>of practical use that straddles multiple teams.
>--
>J. B. Rainsberger,
>Diaspar Software Services
>http://www.diasparsoftware.com :: [phone] Let's write software that
>people understand
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com

====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Stephen Cohen]

J. B. Rainsberger wrote:

I'm not convinced that communication across projects is so important:
each project has its own local conditions, including the specific people

involved, the tools, the schedule... so much so that I doubt there is
much of practical use that straddles multiple teams.

========================
In an enterprise where architecture defines more than standards but
creates governance so that many projects work together over time, cross
project integration is much more a mandate than a target of opportunity.


Consider the need for a cohesive identity management scheme. If each
project determines its own authentication/authorization mechanism you
will have many wheels re-invented, variances in capabilities, and
nightmarish regression testing issues (not to mention really annoyed
users).

Extend this to issues specific to a domain, say managing shipments of
completed products, and you may miss a better idea identified by a
single project team who broke the political code to integrate with a
package handling system, or for lack of communications across projects
you may find the various approaches implemented end up costing the
customer more and fail to improve the customers overall business.

--Stephen

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Stephen Cohen]

I strongly agree with Scott's enterprise architecture essay
[http://www.agiledata.org/essays/enterpriseArchitecture.html].

I believe we are moving from the open plain of the wild, wild, west to
an era where we are fencing in the code cowboys. No longer free to
roam, many will be in fight or flight mode. Our challenge is to create
an environment where multiple software products can both co-exist and
compete for a place in the business. Allowing the software that most
effectively aids the business in the performance of its mission to win
out.

This however, requires an even playing field defined by rules/laws, and
enforced by some authority.

-- Stephen

-----Original Message-----
From: Scott Ambler [mailto:***@ronin-intl.com]
Sent: Friday, February 06, 2004 10:00 PM
To: ***@topica.com
Subject: RE: [AM] Sharing information across the enterprise


Sounds really close to what I talk about at
http://www.agiledata.org/essays/enterpriseArchitecture.html and
www.agilemodeling.com/essays/agileArchitecture.htm.

Other solutions, as Jason implied, include:
1. Getting together and talking with other people over drinks, or at a
softball game, ...
2. Your informal network of people.
3. The "less effective" forms of communication, such as email,
documents, ...

- Scott

At 04:54 PM 2/6/2004 -0700, you wrote:
>I have not worked on a product line since well before discovering
agility,
>but ever since then I have been wanting to try out the following
strategy
>when I get the right opportunity:
>
>1. You have project teams and one product line team.
>2. The product line team consists of a pool of senior developers, each
of
>whom:
>- Is an active member of one of the projects teams (perhaps rotating
among
>the project teams every month or 2).
>- Meets for a few hours every week with the other members of the
product
>line team to talk about global issues and solutions.
>- Looks for components, patterns, practices, etc. in their project that

>should be shared with the other projects.
>- Promotes the reuse in their project of the things that have been
>accumulated from the other projects.
>3. If the shared components get large and complex enough, it could be
>worth considering having a separate project team or a subset of the
>product line team refactor them into an appropriate framework.
>
>Replace "product line" with "enterprise", if you like.
>
>Steven A. Gordon, Ph.D.
>Manager, Software Factory
>Arizona State University
>PO Box 875506
>Tempe, AZ 85287-9509
>http://sf.asu.edu
>(480)-727-6271
>
>
>-----Original Message-----
>From: J. B. Rainsberger [mailto:***@rogers.com]
>Sent: 06 February 2004 23:19
>To: ***@topica.com
>Subject: [AM] Sharing information across the enterprise
>
>Stephen Cohen wrote:
>
> > I haven't spent a lot of time pair programming ...
> > How do you share approaches or warn of identified issues, across
> > projects? How is the knowledge circulated though out an enterprise?
>
>Either by formal presentations or by rotating individuals across teams.
>
> > I am accustomed to working on large programs with many concurrent
> > projects. While high-communication methods work very well within a
> > project I have found it difficult to maintain across an entire
program.
>
>I'm not convinced that communication across projects is so important:
>each project has its own local conditions, including the specific
people
>involved, the tools, the schedule... so much so that I doubt there is
much
>of practical use that straddles multiple teams.
>--
>J. B. Rainsberger,
>Diaspar Software Services
>http://www.diasparsoftware.com :: [phone] Let's write software
that
>people understand
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com

====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Steven Gordon]

Unfortunately, in most enterprises, when you try to make the right things happen via rules and authority, you end up with a form of command and control that sharply reduces agility.

-----Original Message-----
From: Stephen Cohen [mailto:***@microsoft.com]
Sent: Sat 2/7/2004 8:39 AM
To: ***@topica.com
Cc:
Subject: RE: [AM] Sharing information across the enterprise



I strongly agree with Scott's enterprise architecture essay
[http://www.agiledata.org/essays/enterpriseArchitecture.html].

I believe we are moving from the open plain of the wild, wild, west to
an era where we are fencing in the code cowboys. No longer free to
roam, many will be in fight or flight mode. Our challenge is to create
an environment where multiple software products can both co-exist and
compete for a place in the business. Allowing the software that most
effectively aids the business in the performance of its mission to win
out.

This however, requires an even playing field defined by rules/laws, and
enforced by some authority.

-- Stephen

-----Original Message-----
From: Scott Ambler [mailto:***@ronin-intl.com]
Sent: Friday, February 06, 2004 10:00 PM
To: ***@topica.com
Subject: RE: [AM] Sharing information across the enterprise


Sounds really close to what I talk about at
http://www.agiledata.org/essays/enterpriseArchitecture.html and
www.agilemodeling.com/essays/agileArchitecture.htm.

Other solutions, as Jason implied, include:
1. Getting together and talking with other people over drinks, or at a
softball game, ...
2. Your informal network of people.
3. The "less effective" forms of communication, such as email,
documents, ...

- Scott

At 04:54 PM 2/6/2004 -0700, you wrote:
>I have not worked on a product line since well before discovering
agility,
>but ever since then I have been wanting to try out the following
strategy
>when I get the right opportunity:
>
>1. You have project teams and one product line team.
>2. The product line team consists of a pool of senior developers, each
of
>whom:
>- Is an active member of one of the projects teams (perhaps rotating
among
>the project teams every month or 2).
>- Meets for a few hours every week with the other members of the
product
>line team to talk about global issues and solutions.
>- Looks for components, patterns, practices, etc. in their project that

>should be shared with the other projects.
>- Promotes the reuse in their project of the things that have been
>accumulated from the other projects.
>3. If the shared components get large and complex enough, it could be
>worth considering having a separate project team or a subset of the
>product line team refactor them into an appropriate framework.
>
>Replace "product line" with "enterprise", if you like.
>
>Steven A. Gordon, Ph.D.
>Manager, Software Factory
>Arizona State University
>PO Box 875506
>Tempe, AZ 85287-9509
>http://sf.asu.edu
>(480)-727-6271
>
>
>-----Original Message-----
>From: J. B. Rainsberger [mailto:***@rogers.com]
>Sent: 06 February 2004 23:19
>To: ***@topica.com
>Subject: [AM] Sharing information across the enterprise
>
>Stephen Cohen wrote:
>
> > I haven't spent a lot of time pair programming ...
> > How do you share approaches or warn of identified issues, across
> > projects? How is the knowledge circulated though out an enterprise?
>
>Either by formal presentations or by rotating individuals across teams.
>
> > I am accustomed to working on large programs with many concurrent
> > projects. While high-communication methods work very well within a
> > project I have found it difficult to maintain across an entire
program.
>
>I'm not convinced that communication across projects is so important:
>each project has its own local conditions, including the specific
people
>involved, the tools, the schedule... so much so that I doubt there is
much
>of practical use that straddles multiple teams.
>--
>J. B. Rainsberger,
>Diaspar Software Services
>http://www.diasparsoftware.com :: [phone] Let's write software
that
>people understand
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com

====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com







For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Paul Oldfield]

(responding to Steven, Stephen)


>> (Stephen C)
>> I believe we are moving from the open plain of the wild, wild,
>> west to an era where we are fencing in the code cowboys.
>> No longer free to roam, many will be in fight or flight mode.
>> Our challenge is to create an environment where multiple
>> software products can both co-exist and compete for a place
>> in the business. Allowing the software that most effectively
>> aids the business in the performance of its mission to win
>> out.

>> This however, requires an even playing field defined by
>> rules/laws, and enforced by some authority.

> (Steven G)
> Unfortunately, in most enterprises, when you try to make the
> right things happen via rules and authority, you end up with
> a form of command and control that sharply reduces agility.

Certainly there needs to be some communication;
communication that produces a coherent whole out of the
potentially disparate and conflicting features of individual
projects.

Centralised command and control is one approach, but
there are alternatives that might work. Self-organisation
is one approach, whereby the projects communicate
among themselves to progress co-operatively rather
than competitively.

There still needs to be some overall vision toward which
all projects are progressing, and the degree to which
this is derived internally or supplied from outside will
probably be determined by the degree of business
awareness held within the team of teams. The more
abstract the goal that is handed down from above, the
more potential for agility there will be when working to
fulfil that goal.

I recall people talking about a "Scrum of Scrums" that
dealt with inter-team co-ordination; I believe the Scrum
Masters from each team gathered to hold their own
Scrum meetings.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Stephen Cohen]

Paul Oldfield wrote;

There still needs to be some overall vision toward which
all projects are progressing, and the degree to which
this is derived internally or supplied from outside will
probably be determined by the degree of business
awareness held within the team of teams. The more
abstract the goal that is handed down from above, the
more potential for agility there will be when working to
fulfil that goal.

==================================
I agree that a strong vision and abstract top-down goals are essential.


Generally the success of an individual project has been determined by
how well its requirements were met. However the larger enterprise is
better served if great care was taken to determine what will be "best"
for the enterprise and how the individual project fits within the larger
community of projects prior to the projects start. This is not to say
bottom up projects don't provide great value, or that only the
authoritative enterprise knows what is best. Instead I am proposing
that collaboration between the projects and the enterprise is essential
for automation to continually add value.

Two side-effects from automation are driving individual projects into
collaboration with the enterprise;

1- Many software solutions solve a problem for its users but create
problems when commingled with other software.
2- Some enterprises are looking to move from reactive development to
proactive management in such a way that makes IT an equal partner in
long term planning.

We are well beyond developing software to solve a discrete business
problem. It is so common and so easy to apply software that we now
compete for data ownership, realms of responsibility, and money right
along with other parts of the enterprise. (Consider the loss of
control, funding, and head-count an HR department has to cope with when
employees are provided a self-service portal.)

It is possible for an enterprise to benefit from Agility much as
individual projects have; the only difference being the focus and scope
need to be equally outward facing as they have been inward focused.

--Stephen

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Scott E. Preece]

We work some of these issues by having "community of practice" groups
that span the enterprise; these are formed as simple e-mail lists
(anybody can subscribe); some of them have active core groups that
organize meetings, manage archives of discussions and research, etc.

We also have an annual enterprise-wide software symposium, run like an
IEEE conference, with refereed papers, industry guest speakers, etc., as
well as a number of smaller, discipline-specific symposia run more like
workshops, with lighterweight papers and more time for discussion and
networking.

However, I think these are orthogonal to the notion of product lines.
I think Scott A's essay is closer to what's needed than Jason's note -
the product line team needs dedicated staff and needs to own the
interfaces to the common archtiecture, so that the project teams can
build conforming components and expect them to work across the product
line with only nominal adaptation required.

scott

| From: Scott Ambler<***@ronin-intl.com>
| Date: Fri, 06 Feb 2004 22:00:07 -0500
|
|
| Sounds really close to what I talk about at
| http://www.agiledata.org/essays/enterpriseArchitecture.html and
| www.agilemodeling.com/essays/agileArchitecture.htm.
|
| Other solutions, as Jason implied, include:
| 1. Getting together and talking with other people over drinks, or at a
| softball game, ...
| 2. Your informal network of people.
| 3. The "less effective" forms of communication, such as email, documents, ...
|
| - Scott
|
| At 04:54 PM 2/6/2004 -0700, you wrote:
| >I have not worked on a product line since well before discovering agility,
| >but ever since then I have been wanting to try out the following strategy
| >when I get the right opportunity:
| >
| >1. You have project teams and one product line team.
| >2. The product line team consists of a pool of senior developers, each of
| >whom:
| >- Is an active member of one of the projects teams (perhaps rotating among
| >the project teams every month or 2).
| >- Meets for a few hours every week with the other members of the product
| >line team to talk about global issues and solutions.
| >- Looks for components, patterns, practices, etc. in their project that
| >should be shared with the other projects.
| >- Promotes the reuse in their project of the things that have been
| >accumulated from the other projects.
| >3. If the shared components get large and complex enough, it could be
| >worth considering having a separate project team or a subset of the
| >product line team refactor them into an appropriate framework.
| >
| >Replace "product line" with "enterprise", if you like.
| >
| >Steven A. Gordon, Ph.D.
| >Manager, Software Factory
| >Arizona State University
| >PO Box 875506
| >Tempe, AZ 85287-9509
| >http://sf.asu.edu
| >(480)-727-6271
| >
| >
| >-----Original Message-----
| >From: J. B. Rainsberger [mailto:***@rogers.com]
| >Sent: 06 February 2004 23:19
| >To: ***@topica.com
| >Subject: [AM] Sharing information across the enterprise
| >
| >Stephen Cohen wrote:
| >
| > > I haven't spent a lot of time pair programming ...
| > > How do you share approaches or warn of identified issues, across
| > > projects? How is the knowledge circulated though out an enterprise?
| >
| >Either by formal presentations or by rotating individuals across teams.
| >
| > > I am accustomed to working on large programs with many concurrent
| > > projects. While high-communication methods work very well within a
| > > project I have found it difficult to maintain across an entire program.
| >
| >I'm not convinced that communication across projects is so important:
| >each project has its own local conditions, including the specific people
| >involved, the tools, the schedule... so much so that I doubt there is much
| >of practical use that straddles multiple teams.
| >--
| >J. B. Rainsberger,
| >Diaspar Software Services
| >http://www.diasparsoftware.com :: [phone] Let's write software that
| >people understand
| >
| >For more information about AM, visit the Agile Modeling Home Page at
| >www.agilemodeling.com
| >
| >For more information about AM, visit the Agile Modeling Home Page at
| >www.agilemodeling.com
| >
| >For more information about AM, visit the Agile Modeling Home Page at
| >www.agilemodeling.com
|
| ====================================================
| Scott W. Ambler
| Senior Consultant, Ronin International, Inc.
| www.ronin-intl.com/company/scottAmbler.html
|
| www.agiledata.org
| www.agilemodeling.com
| www.ambysoft.com
| www.enterpriseunifiedprocess.info
| www.modelingstyle.info
| www.ronin-intl.com
|
| For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
|
|
|
|


--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: [phone]
phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------

[Scott E. Preece]

I think self-organization is much more likely to work if you're starting
a new organization, with a common goal, than if you are handing a common
goal to an existing set of teams. My experience is that running teams
tend to be very proprietary and subject to NIH (resisting things
from other teams just because they're from other teams). A good
shuffling would probably help.

scott

| From: Paul Oldfield<***@compuserve.com>
| Date: Sun, 8 Feb 2004 07:56:57 -0500
|
| (responding to Steven, Stephen)
|
|
| >> (Stephen C)
| >> I believe we are moving from the open plain of the wild, wild,
| >> west to an era where we are fencing in the code cowboys.
| >> No longer free to roam, many will be in fight or flight mode.
| >> Our challenge is to create an environment where multiple
| >> software products can both co-exist and compete for a place
| >> in the business. Allowing the software that most effectively
| >> aids the business in the performance of its mission to win
| >> out.
|
| >> This however, requires an even playing field defined by
| >> rules/laws, and enforced by some authority.
|
| > (Steven G)
| > Unfortunately, in most enterprises, when you try to make the
| > right things happen via rules and authority, you end up with
| > a form of command and control that sharply reduces agility.
|
| Certainly there needs to be some communication;
| communication that produces a coherent whole out of the
| potentially disparate and conflicting features of individual
| projects.
|
| Centralised command and control is one approach, but
| there are alternatives that might work. Self-organisation
| is one approach, whereby the projects communicate
| among themselves to progress co-operatively rather
| than competitively.
|
| There still needs to be some overall vision toward which
| all projects are progressing, and the degree to which
| this is derived internally or supplied from outside will
| probably be determined by the degree of business
| awareness held within the team of teams. The more
| abstract the goal that is handed down from above, the
| more potential for agility there will be when working to
| fulfil that goal.
|
| I recall people talking about a "Scrum of Scrums" that
| dealt with inter-team co-ordination; I believe the Scrum
| Masters from each team gathered to hold their own
| Scrum meetings.
|
|
| Paul Oldfield

--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: [phone]
phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------