I was curious as to what form of documentation people's requirements
take that are included in the backlogs. Does anyone prefer a common
template such as the XP Story Card, or Use Cases, or something custom
driven?

I know scrum does not mention a specific format for the documentation
of requirements, but I am curious as to what people use and how
effective they find specific documentation formats to be in a SCRUM-
based management environment.

B.

Hi Guys,

The nice folks at STQE have sent me a pdf of the article that appeared in
their latest issue on Agile Meetings.

www.lindarising.org

Click on Articles.

Enjoy!




Linda

Linda,
An excellent article that captures the spirit of the short daily Scrums. I
particularly liked when "poof" happened.
Ken

-----Original Message-----
From: Linda Rising [mailto:risingl@...]
Sent: Monday, June 03, 2002 12:23 PM
To: Scrum
Subject: [scrumdevelopment] Agile Meetings article


Hi Guys,

The nice folks at STQE have sent me a pdf of the article that appeared in
their latest issue on Agile Meetings.

www.lindarising.org

Click on Articles.

Enjoy!




Linda




To Post a message, send it to:   scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Poof is good :-)!



Linda


Ken Schwaber wrote:

>Linda,
>An excellent article that captures the spirit of the short daily Scrums. I
>particularly liked when "poof" happened.
>Ken
>
>-----Original Message-----
>From: Linda Rising [mailto:risingl@...]
>Sent: Monday, June 03, 2002 12:23 PM
>To: Scrum
>Subject: [scrumdevelopment] Agile Meetings article
>
>
>Hi Guys,
>
>The nice folks at STQE have sent me a pdf of the article that appeared in
>their latest issue on Agile Meetings.
>
>www.lindarising.org
>
>Click on Articles.
>
>Enjoy!
>
>
>
>
>Linda
>
>
>
>
>To Post a message, send it to:   scrumdevelopment@eGroups.com
>To Unsubscribe, send a blank message to:
>scrumdevelopment-unsubscribe@eGroups.com
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>To Post a message, send it to:   scrumdevelopment@eGroups.com
>To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

bryan_zarnett wrote:

  > I was curious as to what form of documentation people's requirements
  > take that are included in the backlogs. Does anyone prefer a common
  > template such as the XP Story Card, or Use Cases, or something custom
  > driven?

Our Product Owner/Customer wrote the requirements as light weight use
cases (similar to Constantine's essential use cases or Cockburn's
casual format).  These contained each use case, and the various
scenarios of each that were considered important.  They were written
incrementally by the PO, collaborating with the stakeholders and
testers and developers to get just enough detail for estimating and
testing and developing at each point in the process.

The use cases were just written in MS Word, with each use case getting
it's own "chapter."  The use cases were used to communicate the
requirements across the group of stakeholders, and were constantly
referred to by different groups, so we needed something that could
be easily duplicated and passed around as well as having permanence
to the medium.

The use cases were not, however, a "work unit" for development.  I
hate to call a work unit a "story" because I don't think we viewed
them the same as an XP story, even though we called them "stories" in
our culture.  They were a token for a unit of work that the PO wanted
done to the system, but they were not the requirements.  They were
not a use case.  Some might call them a change request.  The backlog
was a collection of these work units, prioritized.

The work units mapped to the use cases by specifying the overall
functionality that was needed (the use case), the "breadth" of the
functionality (the scenarios that were targeted), and the "depth" of
the functionality (the amount of detail for the targeted scenarios).

For example, we might target a use case of "Shopping Cart Checkout."
The work unit might specify that we're only handling the positive path
scenario this time.  And it might specify that we're leaving out the
calculation of taxes and fees right now.  So the work unit kind of
picks out the parts of the use case that the PO wants implemented for
this iteration.

The PO entered the work units into our issue tracking system
(StarTeam) as change requests.  We didn't really use them for cross-
group communication or permanence, just for directing the short-term
iteration work.  Once they were marked complete by the testers, they
weren't referred to much.  I think the PO looked at them from time to
time to remind himself what had been completed.  In retrospect, we
could have just as easily used index cards on a cork board, but we'd
already laid out thousands of $$$ on StarTeam, so maybe we felt
obligated to use it.  ;-)

The PO marked the work units with a priority, based on how they
mapped to the particular goals at the time (reducing customer service
calls, revenue gains, etc.), and just pulled enough off the top of
the backlog to fill the next iteration.  We had a pretty fluid dot-
com business, so the backlog changed priorities a lot, and longer-
term release plans (anything out more than a couple of months), while
done from time to time to get a feel for potential longer-term
progress, didn't have as much importance.

To clarify how we used use cases and work units, the collection of
use cases represented the overall functionality of the system (as it
was known at a given point in time, not BDUF'ed).  The work units
represented how we were going to implement all that functionality.
The work units were the puzzle pieces that were incrementally placed
in the overall use case puzzle.

This sounds a bit more formal than it was in practice.  We kept
things pretty light weight and it flowed pretty easily with the
process.  It was a smaller team -- one Product Owner, one Tester,
one Coach/Manager, and four to six Developers.  There were a group
of stakeholders, ranging from end-user customers, to CSRs, to back
office folks, so the PO had some challenges in building a single
product vision from them all.  I was involved with the project for
about a year, it had some great success, and it's still ongoing.

I'm sorry if that was too long-winded.  Questions/comments welcome.

Regards,
Paul
-----
Paul Hodgetts -- Principal Consultant
Agile Logic -- www.agilelogic.com
Training, Mentoring, Development -- Agile Processes, XP, Java, J2EE, C++
-----
Don't miss XP/Agile Universe, August 4-7, 2002 -- www.xpuniverse.com
See our tutorial -- Beyond the Customer: Agile Business Practices for XP

I'm going to try to organize user groups in Boston and New York City
this summer, to start up in the fall. I'm looking for interested
people or organizations in these cities. Any suggestions?
Ken Schwaber

I will be out of the office starting  06/07/2002 and will not return until
06/10/2002.

I will be picking up email in the evenings of 6/07 and periodically through
the wekend.   Should you need something immediately - Please contact Danny
Harris-Mayo at 804-697-8613 or dandrea.harris-mayo@....

Please enjoy your day!

Hi,
My name is Ken Schwaber. I'm trying to form, or reform, or integrate with an
existing, agile user group in New England, primarily based in the Boston
area.

I have a consulting practice that specializes in agile methods, I am one of
the developers of the Scrum agile process, and I'm program director of the
AgileAlliance User Group program (www.agilealliance.com). Part of my work
with the agilealliance is to help spread agile processes, and specifically
to help setup user groups. The New England user group is dear to my heart
since I live in Lexington, Massachusetts.

You received this email either because I know you, someone else told me you
might be interested, or you were part of a group that was active in the
past.

I'd like to get together with anyone who is available and is interested in a
New England Agile User Group after work on Monday, July 22nd. I'm open to
either Burlington (MA) or Cambridge (MA), whichever works best for the
majority. The purpose of the meeting is work out the necessary details for
the first regular meeting, which I'd like to hold in September when
vacations are over.

Let me know if your are interested and can make a meeting on July 22 (and
whether you'd prefer Burlington or Cambridge), if you are interested but
can't make the meeting, or you don't want to be on this mailing list. Also,
if you know of someone who might be interested, forward this email to them.

Thanks for your time,

Ken Schwaber

Some in this list may be interested in this workshop:

	 "Self-Organisation and Evolution of Social Behaviour."
	 http://www.ifi.unizh.ch/events/monteverita2002/

The research presented in this conference is very relevant to
understanding agility, imo,

- Mike

http://www.hipaaccelerator.com

http://www.agilescrum.com
http://www.xbreed.net

(I know most of the people subscribed to this list belong to
the Extreme Programming mailing list, but just in case some
of you missed this posting at the Extreme mailing list.....
here it is.  My apologies included if you have received multiple
copies of this message.)

Dear agileers,

It troubles me that the _fundamental differences_  between
traditional and agile processes are not highlighted,
either by, we, the creators and supporters of the Agile movement,
or by traditional software development figure-heads.

Because if we don't highlight the differences of why Agile
Software Development processes we run the danger of hearing
and, worse, accepting that:

	 there is nothing really all that new with
	 Agile Software Development processes

This will relinquish Agile Software Development as "one"
of many other compatible worldviews, and soon Agility will be
muddled into oblivion.

Don't take me wrong, I admire and respect the contributions
of people like Humphrey, Paulk, Parnas, Boehm, Constantine,
Booch, Jacobson, Gilb, Jackson, Yourdon, etc.; but I think in our
desperate effort to make sense of Agility, we will find
that many important concepts are forgotten if we try to equate them
with their traditional software development counterparts.  And that
misconceptions and misunderstandings will be created like:

	 The CMM is compatible with agile processes, or
	 XP can be an instance of RUP

In my opinion, there are radical and fundamental _differences_
that make Agile Software Development Processes and Traditional Software
Development Processes two very different ways of developing software
from the perspective of the nature of their underlying processes:

	 Traditional Software Development Processes advocate and
	 eventually prescribe a _defined_ and _repeatable software
	 engineering process, as well as many other _defined_ and
	 _repeatable_ processes that correspond to different
	 "process areas".  And they are based on the erroneous belief,
	 in my opinion, that software can be "manufactured".

But,

	 Agile Software Development Processes, on the other hand,
	 use inspection/adaptation feedback cycles that "generate"
	 a process by people that self-organize based on the
	 application of a set of practices, or patterns really,
	 that in an Alexandrian way lead to the emergence of
	 an organization and a process.  This is stated directly
	 in the Agile Principles:

	 "The best architectures, requirements, and designs
	 emerge from self-organizing teams."
	 http://www.agilemanifesto.org/principles.html

	 Therefore Agile Software Development Process more
	 closely resembles a New Product development process
	 like the one described in:

	 [NonakaTakeuchi] Takeuchi H. and Nonaka I., The New New Product
	 Development Game, Harvard Business Review (January 1986),
	 pp. 137-146, 1986.

In my opinion, this is an important, radical and fundamental
_difference_, that subtly changes the underlying assumptions
of why and how things work in a software development process.

How does this difference affects the people that work on an
Agile Software Development Process?

It is this feature of Agility that brings out these essential
characteristics in an Agile Software Development Process:


	 1) Greater Liberty and Freedom

	 People in an Agile Software project feel more liberated
	 because they feel _free_ to do whatever it takes
	 to achieve their goal:

		 talk to the customer, think, imagine, code, test, refactor,

	 in any order, as many times as they need/want, and as often as
	 they need to.


	 2) Required Learning, Knowledge Creation and Knowledge Sharing

	 People in an Agile Software project are constantly learning,
	 and sharing knowledge because by definition Agility is
	 based on continuous short feedback cycles of:

		 inspection --> adaptation

	 where we learn from the customers, from other team members,
	 from practitioners in the field, and even from ourselves
	 on a daily basis.


	 3) A More Enjoyable and Humane Work Environment

	 People in an Agile Software project participate in a more
	 human "fun-like" way because the more human and intellectual
	 activities of research, understanding, imagination,
	 creativity, cooperation and sharing are encouraged and required;
	 as opposed to being considered just "another station in
	 a production line".


	 4) A Hyper-productive Cooperative Work Mode

	 People in an Agile Software project work in teams that
	 exhibit a mode of cooperation that leads to hyper-productivity --
	 the dynamic pull-system way that Nonaka and Takeuchi describe in the
	 Knowledge Creating Company as the "hypertext" organization.

	 This mode of cooperation, taps into the collective
	 intelligence and collective knowledge and memory stored
	 in the distributed mind of the team and the organization
	 as a whole.


	 5) The Quality of Life

	 Agile Software projects work under the assumption and
	 expectation that "emergent" behavior is the only way to
	 confront uncertainty.  Agile Software projects openly
	 accept that it is impossible to:

		 outline what tasks are going to be needed
		 to complete a software project up-front, and

		 get all the requirements up-front, and/or
		 design an architecture up-front.

	 Rather, the plan, the requirements and the architecture
	 of the project, gradually emerge, by constant feedback cycles,
	 research and creativity, and constant interaction among
	 the participants of the project and the customer.

	 This is what gives Agile Software Development teams
	 the distinctive feature of "ordered chaos" that
	 Life itself uses to accomplish its miraculous chores.

	 And therefore, this is what literally makes teams
	 more "alive", because teams more closely resemble
	 living systems like ant or bee colonies,
	 brains, or rugby/soccer/football teams.

	 etc.

For these reasons, which are not all, I hereby declare the
beginning of a new era in software development, and I therefore
proclaim officially that the creation of the Agile Manifesto:

	 http://www.agilemanifesto.org/

and its principles:

	 http://www.agilemanifesto.org/principles.html

mark unequivocally the beginning of the:

	 Agile Software Development Revolution

which was created, sponsored and supported by all of
you brave souls that dared the world by practicing and
advocating a _new_ Agile way, that makes software development
different, more productive, more humane and therefore
clearly better, in my opinion.

Don't find yourself muddled out by figure-heads ... stay Agile!

- Mike

http://www.agilescrum.com
http://www.xbreed.net

Mike,
I congratulate your focus. We are in danger of this being thought and
whittled to death. Like the movie, "Death by a Thousand Blows." I had a
similar feeling at XP2002, which caused my to get up in a rather testy mood
and give the attached speech to the attendees.
Ken

-----Original Message-----
From: Mike Beedle [mailto:beedlem@...]
Sent: Monday, July 08, 2002 7:16 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] RE: Agile Software Development Revolution



(I know most of the people subscribed to this list belong to
the Extreme Programming mailing list, but just in case some
of you missed this posting at the Extreme mailing list.....
here it is.  My apologies included if you have received multiple
copies of this message.)

Dear agileers,

It troubles me that the _fundamental differences_  between
traditional and agile processes are not highlighted,
either by, we, the creators and supporters of the Agile movement,
or by traditional software development figure-heads.

Because if we don't highlight the differences of why Agile
Software Development processes we run the danger of hearing
and, worse, accepting that:

	 there is nothing really all that new with
	 Agile Software Development processes

This will relinquish Agile Software Development as "one"
of many other compatible worldviews, and soon Agility will be
muddled into oblivion.

Don't take me wrong, I admire and respect the contributions
of people like Humphrey, Paulk, Parnas, Boehm, Constantine,
Booch, Jacobson, Gilb, Jackson, Yourdon, etc.; but I think in our
desperate effort to make sense of Agility, we will find
that many important concepts are forgotten if we try to equate them
with their traditional software development counterparts.  And that
misconceptions and misunderstandings will be created like:

	 The CMM is compatible with agile processes, or
	 XP can be an instance of RUP

In my opinion, there are radical and fundamental _differences_
that make Agile Software Development Processes and Traditional Software
Development Processes two very different ways of developing software
from the perspective of the nature of their underlying processes:

	 Traditional Software Development Processes advocate and
	 eventually prescribe a _defined_ and _repeatable software
	 engineering process, as well as many other _defined_ and
	 _repeatable_ processes that correspond to different
	 "process areas".  And they are based on the erroneous belief,
	 in my opinion, that software can be "manufactured".

But,

	 Agile Software Development Processes, on the other hand,
	 use inspection/adaptation feedback cycles that "generate"
	 a process by people that self-organize based on the
	 application of a set of practices, or patterns really,
	 that in an Alexandrian way lead to the emergence of
	 an organization and a process.  This is stated directly
	 in the Agile Principles:

	 "The best architectures, requirements, and designs
	 emerge from self-organizing teams."
	 http://www.agilemanifesto.org/principles.html

	 Therefore Agile Software Development Process more
	 closely resembles a New Product development process
	 like the one described in:

	 [NonakaTakeuchi] Takeuchi H. and Nonaka I., The New New Product
	 Development Game, Harvard Business Review (January 1986),
	 pp. 137-146, 1986.

In my opinion, this is an important, radical and fundamental
_difference_, that subtly changes the underlying assumptions
of why and how things work in a software development process.

How does this difference affects the people that work on an
Agile Software Development Process?

It is this feature of Agility that brings out these essential
characteristics in an Agile Software Development Process:


	 1) Greater Liberty and Freedom

	 People in an Agile Software project feel more liberated
	 because they feel _free_ to do whatever it takes
	 to achieve their goal:

		 talk to the customer, think, imagine, code, test, refactor,

	 in any order, as many times as they need/want, and as often as
	 they need to.


	 2) Required Learning, Knowledge Creation and Knowledge Sharing

	 People in an Agile Software project are constantly learning,
	 and sharing knowledge because by definition Agility is
	 based on continuous short feedback cycles of:

		 inspection --> adaptation

	 where we learn from the customers, from other team members,
	 from practitioners in the field, and even from ourselves
	 on a daily basis.


	 3) A More Enjoyable and Humane Work Environment

	 People in an Agile Software project participate in a more
	 human "fun-like" way because the more human and intellectual
	 activities of research, understanding, imagination,
	 creativity, cooperation and sharing are encouraged and required;
	 as opposed to being considered just "another station in
	 a production line".


	 4) A Hyper-productive Cooperative Work Mode

	 People in an Agile Software project work in teams that
	 exhibit a mode of cooperation that leads to hyper-productivity --
	 the dynamic pull-system way that Nonaka and Takeuchi describe in the
	 Knowledge Creating Company as the "hypertext" organization.

	 This mode of cooperation, taps into the collective
	 intelligence and collective knowledge and memory stored
	 in the distributed mind of the team and the organization
	 as a whole.


	 5) The Quality of Life

	 Agile Software projects work under the assumption and
	 expectation that "emergent" behavior is the only way to
	 confront uncertainty.  Agile Software projects openly
	 accept that it is impossible to:

		 outline what tasks are going to be needed
		 to complete a software project up-front, and

		 get all the requirements up-front, and/or
		 design an architecture up-front.

	 Rather, the plan, the requirements and the architecture
	 of the project, gradually emerge, by constant feedback cycles,
	 research and creativity, and constant interaction among
	 the participants of the project and the customer.

	 This is what gives Agile Software Development teams
	 the distinctive feature of "ordered chaos" that
	 Life itself uses to accomplish its miraculous chores.

	 And therefore, this is what literally makes teams
	 more "alive", because teams more closely resemble
	 living systems like ant or bee colonies,
	 brains, or rugby/soccer/football teams.

	 etc.

For these reasons, which are not all, I hereby declare the
beginning of a new era in software development, and I therefore
proclaim officially that the creation of the Agile Manifesto:

	 http://www.agilemanifesto.org/

and its principles:

	 http://www.agilemanifesto.org/principles.html

mark unequivocally the beginning of the:

	 Agile Software Development Revolution

which was created, sponsored and supported by all of
you brave souls that dared the world by practicing and
advocating a _new_ Agile way, that makes software development
different, more productive, more humane and therefore
clearly better, in my opinion.

Don't find yourself muddled out by figure-heads ... stay Agile!

- Mike

http://www.agilescrum.com
http://www.xbreed.net


To Post a message, send it to:   scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Ken:

What a joy to read your XP 2002 speech.  I wish I would have been there.
It is certainly inspiring, provocative and gets the point across:

        Agile is certainly different and revolutionary

and your speech explains why -- that's important.  (I beg you to
offer your Speech as a download from your website, and to publish it,
or a variation of it, in Software Development magazine, or a
similar widely read publication.)

You should find interesting that what provoked me to write my note to
Extreme Programming, was a similar feeling of dissatisfaction with the
several discussions I was holding and hearing at the time at
the list that orbited around 1) comparing agile processes with
traditional processes, 2)  exploratory metaphors to explain
agile processes, and 3) about techniques from other domains to improve
and explain agile processes.

All of these discussions are interesting and productive but somehow
managed to leave out what I consider they _key differences_
of agility.

Superficially, everything that glitters can be confused with
precious stones.  But we get to know as we understand more,
that there is a difference between zirconias and diamonds i.e.
between the "real" thing and something that superficially '
looks like it.

At times, I often feel that's were we are as a community --
there is not enough understanding as to why agile is a diamond.

Clearly statements like:

	 XP can be an instance of RUP

ignore the latent, seldom-unspoken but _fundamental_
nature of agile processes,

- Mike



-----Original Message-----
From: Ken Schwaber [mailto:ken.schwaber@...]
Sent: Monday, July 08, 2002 7:55 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] RE: Agile Software Development Revolution


Mike,
I congratulate your focus. We are in danger of this being thought and
whittled to death. Like the movie, "Death by a Thousand Blows." I had a
similar feeling at XP2002, which caused my to get up in a rather testy mood
and give the attached speech to the attendees.
Ken

-----Original Message-----
From: Mike Beedle [mailto:beedlem@...]
Sent: Monday, July 08, 2002 7:16 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] RE: Agile Software Development Revolution



(I know most of the people subscribed to this list belong to
the Extreme Programming mailing list, but just in case some
of you missed this posting at the Extreme mailing list.....
here it is.  My apologies included if you have received multiple
copies of this message.)

Dear agileers,

It troubles me that the _fundamental differences_  between
traditional and agile processes are not highlighted,
either by, we, the creators and supporters of the Agile movement,
or by traditional software development figure-heads.

Because if we don't highlight the differences of why Agile
Software Development processes we run the danger of hearing
and, worse, accepting that:

       there is nothing really all that new with
       Agile Software Development processes

This will relinquish Agile Software Development as "one"
of many other compatible worldviews, and soon Agility will be
muddled into oblivion.

Don't take me wrong, I admire and respect the contributions
of people like Humphrey, Paulk, Parnas, Boehm, Constantine,
Booch, Jacobson, Gilb, Jackson, Yourdon, etc.; but I think in our
desperate effort to make sense of Agility, we will find
that many important concepts are forgotten if we try to equate them
with their traditional software development counterparts.  And that
misconceptions and misunderstandings will be created like:

       The CMM is compatible with agile processes, or
       XP can be an instance of RUP

In my opinion, there are radical and fundamental _differences_
that make Agile Software Development Processes and Traditional Software
Development Processes two very different ways of developing software
from the perspective of the nature of their underlying processes:

       Traditional Software Development Processes advocate and
       eventually prescribe a _defined_ and _repeatable software
       engineering process, as well as many other _defined_ and
       _repeatable_ processes that correspond to different
       "process areas".  And they are based on the erroneous belief,
       in my opinion, that software can be "manufactured".

But,

       Agile Software Development Processes, on the other hand,
       use inspection/adaptation feedback cycles that "generate"
       a process by people that self-organize based on the
       application of a set of practices, or patterns really,
       that in an Alexandrian way lead to the emergence of
       an organization and a process.  This is stated directly
       in the Agile Principles:

       "The best architectures, requirements, and designs
       emerge from self-organizing teams."
       http://www.agilemanifesto.org/principles.html

       Therefore Agile Software Development Process more
       closely resembles a New Product development process
       like the one described in:

       [NonakaTakeuchi] Takeuchi H. and Nonaka I., The New New Product
       Development Game, Harvard Business Review (January 1986),
       pp. 137-146, 1986.

In my opinion, this is an important, radical and fundamental
_difference_, that subtly changes the underlying assumptions
of why and how things work in a software development process.

How does this difference affects the people that work on an
Agile Software Development Process?

It is this feature of Agility that brings out these essential
characteristics in an Agile Software Development Process:


       1) Greater Liberty and Freedom

       People in an Agile Software project feel more liberated
       because they feel _free_ to do whatever it takes
       to achieve their goal:

             talk to the customer, think, imagine, code, test, refactor,

       in any order, as many times as they need/want, and as often as
       they need to.


       2) Required Learning, Knowledge Creation and Knowledge Sharing

       People in an Agile Software project are constantly learning,
       and sharing knowledge because by definition Agility is
       based on continuous short feedback cycles of:

             inspection --> adaptation

       where we learn from the customers, from other team members,
       from practitioners in the field, and even from ourselves
       on a daily basis.


       3) A More Enjoyable and Humane Work Environment

       People in an Agile Software project participate in a more
       human "fun-like" way because the more human and intellectual
       activities of research, understanding, imagination,
       creativity, cooperation and sharing are encouraged and required;
       as opposed to being considered just "another station in
       a production line".


       4) A Hyper-productive Cooperative Work Mode

       People in an Agile Software project work in teams that
       exhibit a mode of cooperation that leads to hyper-productivity --
       the dynamic pull-system way that Nonaka and Takeuchi describe in the
       Knowledge Creating Company as the "hypertext" organization.

       This mode of cooperation, taps into the collective
       intelligence and collective knowledge and memory stored
       in the distributed mind of the team and the organization
       as a whole.


       5) The Quality of Life

       Agile Software projects work under the assumption and
       expectation that "emergent" behavior is the only way to
       confront uncertainty.  Agile Software projects openly
       accept that it is impossible to:

             outline what tasks are going to be needed
             to complete a software project up-front, and

             get all the requirements up-front, and/or
             design an architecture up-front.

       Rather, the plan, the requirements and the architecture
       of the project, gradually emerge, by constant feedback cycles,
       research and creativity, and constant interaction among
       the participants of the project and the customer.

       This is what gives Agile Software Development teams
       the distinctive feature of "ordered chaos" that
       Life itself uses to accomplish its miraculous chores.

       And therefore, this is what literally makes teams
       more "alive", because teams more closely resemble
       living systems like ant or bee colonies,
       brains, or rugby/soccer/football teams.

       etc.

For these reasons, which are not all, I hereby declare the
beginning of a new era in software development, and I therefore
proclaim officially that the creation of the Agile Manifesto:

       http://www.agilemanifesto.org/

and its principles:

       http://www.agilemanifesto.org/principles.html

mark unequivocally the beginning of the:

       Agile Software Development Revolution

which was created, sponsored and supported by all of
you brave souls that dared the world by practicing and
advocating a _new_ Agile way, that makes software development
different, more productive, more humane and therefore
clearly better, in my opinion.

Don't find yourself muddled out by figure-heads ... stay Agile!

- Mike

http://www.agilescrum.com
http://www.xbreed.net


To Post a message, send it to:   scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



To Post a message, send it to:   scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

-----Original Message-----
From: Mike Cohn [mailto:mike@...]
Sent: Monday, July 08, 2002 11:00 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] RE: Agile Software Development Revolution

A huge problem results from software developers (and certainly development managers) having been trained over the past 20 years or so to want to write down a list of meta-tasks that must be performed on every project. With agile processes there just isn’t as much to write down—we see this in the size of Ken’s and Mike’s wonderful Scrum book and in the XP series. There are probably fewer words in all those books than in The Unified Software Development Process book. And even at that each of the XP books after the first two added very little. RUP does take 500 dense pages to describe, though.

 

In organizations filled with people who have been trained to write down their methodologies they look to write down the steps of an agile process—and on the surface that doesn’t seem so evil but it just completely misses the point. I envision organizations with Gantt charts with items like:

 

Task 3: Have team self-organize, 3 days

Task 4: Allow requirements to emerge, 5 days

 

I remember when I first read the Rational article on how RUP could really be XP (http://www.rational.com/media/products/rup/tp183.pdf). I thought it was a joke at first. First, how could any “unified process” be agile? Agile processes have to be ones that adapt to the organizations using them. RUP will always feel like RUP even with some activities removed. The thing that really scared about RUP = XP was that Bob Martin seemed to be endorsing it with his dX process: http://www.objectmentor.com/resources/articles/RUPvsXP.pdf. At least with his paper I couldn’t be sure if he was truly endorsing that as a way to proceed or if he’d written the paper as a thought experiment to see if it really was possible “ to do XP within RUP.”

 

I remember almost two years ago joking with Ward Cunningham that I was going to come out with an “Extreme Management” methodology which would be centered around the belief that “pair managing” was appropriate and that I would assign two managers to sit at the keyboard with each programmer. Now of course there is something called “Extreme Project Management” from Rob Thomsett (http://www.cutter.com/freestuff/epmr0102.html). I go back and forth on whether this is agile or not—the article appears to be pro-agile (except for odd comments like (XPM Rule 2: The less the project manager knows about the technical issues of the project, the better, which completely scares me!) but his book seems far less so (admittedly I’ve not yet finished reading it).

 

We’ve also got things like Feature-Driven Development from Togethersoft that appear (to me at least) to be masquerading as agile. I don’t see anything in FDD that is agile—unless you consider delivering software within 4 month sprints agile.

 

I’ve had the feeling for a few months that while momentum continues in favor of agile methodologies those supplying the momentum are of the “we’re already doing that” variety mentioned in Ken’s XP2002 speech earlier in this thread.

 

We somehow have to keep at the forefront of the discussion of agile methods that these approaches are revolutionary and that they are not just a different set of tasks to be performed.

 

--Mike

 

 

-----Original Message-----
From: Mike Beedle [mailto:beedlem@...]
Sent: Monday, July 08, 2002 7:38 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] RE: Agile Software Development Revolution

 

Ken:

What a joy to read your XP 2002 speech.  I wish I would have been there.
It is certainly inspiring, provocative and gets the point across:

       Agile is certainly different and revolutionary

and your speech explains why -- that's important.  (I beg you to
offer your Speech as a download from your website, and to publish it,
or a variation of it, in Software Development magazine, or a
similar widely read publication.)

You should find interesting that what provoked me to write my note to
Extreme Programming, was a similar feeling of dissatisfaction with the
several discussions I was holding and hearing at the time at
the list that orbited around 1) comparing agile processes with
traditional processes, 2)  exploratory metaphors to explain
agile processes, and 3) about techniques from other domains to improve
and explain agile processes.

All of these discussions are interesting and productive but somehow
managed to leave out what I consider they _key differences_
of agility.

Superficially, everything that glitters can be confused with
precious stones.  But we get to know as we understand more,
that there is a difference between zirconias and diamonds i.e.
between the "real" thing and something that superficially '
looks like it.

At times, I often feel that's were we are as a community --
there is not enough understanding as to why agile is a diamond.

Clearly statements like:

      XP can be an instance of RUP

ignore the latent, seldom-unspoken but _fundamental_
nature of agile processes,

- Mike



-----Original Message-----
From: Ken Schwaber [mailto:ken.schwaber@...]
Sent: Monday, July 08, 2002 7:55 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] RE: Agile Software Development Revolution


Mike,
I congratulate your focus. We are in danger of this being thought and
whittled to death. Like the movie, "Death by a Thousand Blows." I had a
similar feeling at XP2002, which caused my to get up in a rather testy mood
and give the attached speech to the attendees.
Ken

-----Original Message-----
From: Mike Beedle [mailto:beedlem@...]
Sent: Monday, July 08, 2002 7:16 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] RE: Agile Software Development Revolution



(I know most of the people subscribed to this list belong to
the Extreme Programming mailing list, but just in case some
of you missed this posting at the Extreme mailing list.....
here it is.  My apologies included if you have received multiple
copies of this message.)

Dear agileers,

It troubles me that the _fundamental differences_  between
traditional and agile processes are not highlighted,
either by, we, the creators and supporters of the Agile movement,
or by traditional software development figure-heads.

Because if we don't highlight the differences of why Agile
Software Development processes we run the danger of hearing
and, worse, accepting that:

      there is nothing really all that new with
      Agile Software Development processes

This will relinquish Agile Software Development as "one"
of many other compatible worldviews, and soon Agility will be
muddled into oblivion.

Don't take me wrong, I admire and respect the contributions
of people like Humphrey, Paulk, Parnas, Boehm, Constantine,
Booch, Jacobson, Gilb, Jackson, Yourdon, etc.; but I think in our
desperate effort to make sense of Agility, we will find
that many important concepts are forgotten if we try to equate them
with their traditional software development counterparts.  And that
misconceptions and misunderstandings will be created like:

      The CMM is compatible with agile processes, or
      XP can be an instance of RUP

In my opinion, there are radical and fundamental _differences_
that make Agile Software Development Processes and Traditional Software
Development Processes two very different ways of developing software
from the perspective of the nature of their underlying processes:

      Traditional Software Development Processes advocate and
      eventually prescribe a _defined_ and _repeatable software
      engineering process, as well as many other _defined_ and
      _repeatable_ processes that correspond to different
      "process areas".  And they are based on the erroneous belief,
      in my opinion, that software can be "manufactured".

But,

      Agile Software Development Processes, on the other hand,
      use inspection/adaptation feedback cycles that "generate"
      a process by people that self-organize based on the
      application of a set of practices, or patterns really,
      that in an Alexandrian way lead to the emergence of
      an organization and a process.  This is stated directly
      in the Agile Principles:

      "The best architectures, requirements, and designs
      emerge from self-organizing teams."
      http://www.agilemanifesto.org/principles.html

      Therefore Agile Software Development Process more
      closely resembles a New Product development process
      like the one described in:

      [NonakaTakeuchi] Takeuchi H. and Nonaka I., The New New Product
      Development Game, Harvard Business Review (January 1986),
      pp. 137-146, 1986.

In my opinion, this is an important, radical and fundamental
_difference_, that subtly changes the underlying assumptions
of why and how things work in a software development process.

How does this difference affects the people that work on an
Agile Software Development Process?

It is this feature of Agility that brings out these essential
characteristics in an Agile Software Development Process:


      1) Greater Liberty and Freedom

      People in an Agile Software project feel more liberated
      because they feel _free_ to do whatever it takes
      to achieve their goal:

            talk to the customer, think, imagine, code, test, refactor,

      in any order, as many times as they need/want, and as often as
      they need to.


      2) Required Learning, Knowledge Creation and Knowledge Sharing

      People in an Agile Software project are constantly learning,
      and sharing knowledge because by definition Agility is
      based on continuous short feedback cycles of:

            inspection --> adaptation

      where we learn from the customers, from other team members,
      from practitioners in the field, and even from ourselves
      on a daily basis.


      3) A More Enjoyable and Humane Work Environment

      People in an Agile Software project participate in a more
      human "fun-like" way because the more human and intellectual
      activities of research, understanding, imagination,
      creativity, cooperation and sharing are encouraged and required;
      as opposed to being considered just "another station in
      a production line".


      4) A Hyper-productive Cooperative Work Mode

      People in an Agile Software project work in teams that
      exhibit a mode of cooperation that leads to hyper-productivity --
      the dynamic pull-system way that Nonaka and Takeuchi describe in the
      Knowledge Creating Company as the "hypertext" organization.

      This mode of cooperation, taps into the collective
      intelligence and collective knowledge and memory stored
      in the distributed mind of the team and the organization
      as a whole.


      5) The Quality of Life

      Agile Software projects work under the assumption and
      expectation that "emergent" behavior is the only way to
      confront uncertainty.  Agile Software projects openly
      accept that it is impossible to:

            outline what tasks are going to be needed
            to complete a software project up-front, and

            get all the requirements up-front, and/or
            design an architecture up-front.

      Rather, the plan, the requirements and the architecture
      of the project, gradually emerge, by constant feedback cycles,
      research and creativity, and constant interaction among
      the participants of the project and the customer.

      This is what gives Agile Software Development teams
      the distinctive feature of "ordered chaos" that
      Life itself uses to accomplish its miraculous chores.

      And therefore, this is what literally makes teams
      more "alive", because teams more closely resemble
      living systems like ant or bee colonies,
      brains, or rugby/soccer/football teams.

      etc.

For these reasons, which are not all, I hereby declare the
beginning of a new era in software development, and I therefore
proclaim officially that the creation of the Agile Manifesto:

      http://www.agilemanifesto.org/

and its principles:

      http://www.agilemanifesto.org/principles.html

mark unequivocally the beginning of the:

      Agile Software Development Revolution

which was created, sponsored and supported by all of
you brave souls that dared the world by practicing and
advocating a _new_ Agile way, that makes software development
different, more productive, more humane and therefore
clearly better, in my opinion.

Don't find yourself muddled out by figure-heads ... stay Agile!

- Mike

http://www.agilescrum.com
http://www.xbreed.net


To Post a message, send it to:   scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



To Post a message, send it to:   scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

To Post a message, send it to:   scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

To Post a message, send it to:   scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Mike:

Well said:

	 the intellectual baggage of _defined_ processes
	 carried over from previous lives, projects, related
	 experience, and education causes for most
	 metaphor-block and dysfunctional translation.
	 (What a challenge we have ahead of us!!!)

That's why it is so important to have good mentors,
experienced Scrum masters, and experienced developers,
that understand, at least in a tacit way that there
is a _fundamental_ difference of Agile vs. Traditional
(defined) software development.

Also, just like Ken said, I'll have to add these ones
to the next Gantt chart I see:

	 Task 3: Have teams self-organize, 3 days
	 Task 4: Allow requirements to emerge, 5 days

:-) :-) ;-)

And I'll eve add a few more:

	 Task 5: Turn the Management pyramid upside down
	 Task 6: Adopt Agile Values

More relevant to Scrum, and to continue the parody above,
I often see trained Team Leaders and Managers
walking into the Scrum meeting assigning tasks and
expecting direct reports like (to continue the parody):

	 "Your _assigned_ task yesterday was to adopt the
	 Agile Values, were you able to do that?

	 No?!!

	 _You are having issues again_.  _Report_
	 to me your any progress you are able to make
	 by tomorrow."

They think that management _asigns_ tasks, that it
is developers who have issues to resolve, and that
developers should _report_ back to them in the morning.

What we mean in Scrum is:

	 Let me hear how things went and see how we, the
	 team, can help you

	 Let me hear any issues you have that go beyond
	 your control so I can help you

	 and

	 Let me hear what new tasks _you are choosing_ to
	 work on next and see how we, the team, can help you

instead of:

	 I assign tasks to you every day

	 you must tell me the issues you may have and
	 solve them

	 and

	 you report to me every day

	 (Definitely NOT the spirit of Scrum)

Attitude for the most part is what makes Scrum different than
micromanagement and Master/Slave direct management and
reporting,

- Mike

Mike, Mike, Everybody:

I like these. Can't someone put together a nice article that describe these,
and similar, in length? As an anti-pattern (of course :-) ) for adaption of
agile. I think it's a good way to describe how agile is different.

Regards,
Jonas

>       Task 3: Have teams self-organize, 3 days
>       Task 4: Allow requirements to emerge, 5 days
>       Task 5: Turn the Management pyramid upside down
>       Task 6: Adopt Agile Values

Ken wrote:
> Barry Boehm and a lot of other respected people like
> him are the worst thing that could happen to agile.
> They don't get it; they think agile is a task3, task4
> thing that is really "lightweight", but not something
> radically new. They are part of the problem, not
> part of the solution. And it seems that the more we
> work with them, the more we lose our focus and
> they redefine agile into "just a small change."

Ken:

I didn't have the courage to put it quite on these words,
but yes, I wholeheartedly agree.  If people hear believable
misconceptions, half truths, or just plain ole illed advice
from figure heads like:

	 * XP can be an instance or RUP

	 * Agile processes are _defined_ ETVX processes and
	 are CMM compatible

	 * Agile processes are just lightweight processes

	 * We've done _all_ of this for the last 30 years

	 etc.

Agile will be reduced to whatever else they want and it
to be, and the agile concept will be so muddled and garbled
that it will be hard to tell, specially for new comers,
what Software Agility really is or is not.

An old quote comes to mind, in 1982, Tim Rentsch said:

" ...object oriented programming will be in the 1980's
what structured programming was in the 1970's. Everyone
will be in favor of it. Every manufacturer will promote
his products as supporting it. Every manager will pay
lip service to it. Every programmer will practice it
(differently). And no one will know just what it is."

[Rentsch82]
Nguyen, Van and Hailpern, Brent "A Generalized Object Model",
ACM SIGPLAN NOTICES, v17, n9 Ed: G. Richard Wexelblat,
September 1982

So let me translate it to the agile software development:

" ...Agile Software Development will be in the 2000's
what Defined-Process Software Development was in the 1980's.
Everyone will be in favor of it. Every manufacturer will promote
his products as supporting it. Every manager will pay
lip service to it. Every programmer will practice it
(differently). And no one will know just what it is."

The scary part is that Rentsch's observations were valid
also in the 1990's, so if history repeats itself, we are
talking about an absorption rate of 20-30 years or so,

- Mike

MIke,
Linda Rising is the bard and songstress of agile. I hope she takes these
from village to village so people understand better.
Ken

-----Original Message-----
From: Mike Beedle [mailto:beedlem@...]
Sent: Tuesday, July 09, 2002 4:50 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] RE: Agile Software Development
Revolution



Mike:

Well said:

	 the intellectual baggage of _defined_ processes
	 carried over from previous lives, projects, related
	 experience, and education causes for most
	 metaphor-block and dysfunctional translation.
	 (What a challenge we have ahead of us!!!)

That's why it is so important to have good mentors,
experienced Scrum masters, and experienced developers,
that understand, at least in a tacit way that there
is a _fundamental_ difference of Agile vs. Traditional
(defined) software development.

Also, just like Ken said, I'll have to add these ones
to the next Gantt chart I see:

	 Task 3: Have teams self-organize, 3 days
	 Task 4: Allow requirements to emerge, 5 days

:-) :-) ;-)

And I'll eve add a few more:

	 Task 5: Turn the Management pyramid upside down
	 Task 6: Adopt Agile Values

More relevant to Scrum, and to continue the parody above,
I often see trained Team Leaders and Managers
walking into the Scrum meeting assigning tasks and
expecting direct reports like (to continue the parody):

	 "Your _assigned_ task yesterday was to adopt the
	 Agile Values, were you able to do that?

	 No?!!

	 _You are having issues again_.  _Report_
	 to me your any progress you are able to make
	 by tomorrow."

They think that management _asigns_ tasks, that it
is developers who have issues to resolve, and that
developers should _report_ back to them in the morning.

What we mean in Scrum is:

	 Let me hear how things went and see how we, the
	 team, can help you

	 Let me hear any issues you have that go beyond
	 your control so I can help you

	 and

	 Let me hear what new tasks _you are choosing_ to
	 work on next and see how we, the team, can help you

instead of:

	 I assign tasks to you every day

	 you must tell me the issues you may have and
	 solve them

	 and

	 you report to me every day

	 (Definitely NOT the spirit of Scrum)

Attitude for the most part is what makes Scrum different than
micromanagement and Master/Slave direct management and
reporting,

- Mike


To Post a message, send it to:   scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@eGroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

I have a couple of observations.

Observation 1:

Every movement I know of – Just-in-Time, Quality, Lean
Manufacturing, Theory of Constraints, you name it – has been
misunderstood and misapplied by people who size on a piece of the
message.  People looking for a formula or sliver bullet always
seem to miss the fundamentals.  At the core, every one of these
movements focuses on team empowerment, providing customer value, and
moving from a parochial to a holistic view of the system.  In every
case, these `movements' emphasize that the manager must act
as a coach, provide training, and help the team understand and
achieve overall business value.

If these very worthy paradigm shifts are mis-applied more often than
used correctly, why would we think that agile development would be
immune from the same fate?

Observation 2:

I worry about stereotyping managers as people who assign tasks and
check that they are done.  I know many managers who understand their
role to be coaching, training, supporting, and providing a valuable
business mission to an empowered team.  Okay, so most of them are in
operations or product development, but that just goes to show the
JIT/TQM/Lean/TOC movements have had some positive impact.

We can't influence people who feel we do not respect them.

Mary Poppendieck
www.LeanProgramming.com

Grady Booch wrote:
> [egb> ] This reality of the breadth of software is what tempers a
> lot of my comments about process in this forum. Fundamentally, building
better
> software faster is hard. No one size fits all - there are just so
> many kinds of domains and development cultures out there. My goodness, we
> as an industry can't even agree upon a common vocabulary for the most
basic of
> things like "requirement" or "architecture" or "component" (take a look at
> what the SWEBOK did and didn't achieve). That being said, I therefore rant
> against any radical claims of revolution in this space from any
> source. The entire history of software engineering is one of raising
levels of
> abstraction - but what primarily limits us as an industry from building
> great software is not this technical dimension, but the human one.

Grady:

(Thanks for your response when I wrote the first "Agile Software Development
Revolution" and "Agile Rentschian articles, this is the kind of discussions
that I had in mind, but serendipity took us to coffee spills, sex, and
"dirty politics".  Fun threads, btw. :-)

Here are some comments.

1) No size fits all.  I agree that even including the space of
Agile Software Development "no size fits all".  Defined-process methods
cope with this problem by adding more processes, more artifacts, more
roles and hierarchy and more tools.

And agile methods follow the same trend, we add more, except we add
more Agile practices instead of more processes, artifacts, etc..  In
Agile methods, we believe _practices_, which are really patterns
in most cases, generate the processes.  We see process as a second
order effect.

Let me give you an example of how different agile practices apply to
different team sizes, in teams of 3-5 or above,  Pair Programming applies;
but in projects of hundreds or even thousands of developers or above,
practices like Scrum of Scrums, or like the Shared Resources team that
I describe in XBreed apply.  (A multi-project agile method that fuses
Scrum, XP and Reusability, Alexanderian and Open Source ideas, which
main goal is to scale agile methods.)

So there is an agile adjustment for size:  we use more generative
agile practices.


2) Building Software faster.  There are many core Agile Practices
that deal directly with "developing software faster".  For example:

	 * hiring top talent,
	 * practicing test driven development,
	 * constantly getting feedback from the customer,
	 * minimizing excessive documentation or generating it faster
	 * avoiding an assembly line process that creates dependencies
	 on finished products like plans, requirements and architecture.
	 etc.

In general, Agile methods, adjust quality, size, scope and schedule
by making adjustments on agile practices, and accepting that there
are bounds on what can be controlled.


3) Agile Revolution or not?.  However, even though there may be
adjustments agile practices there is a fundamental difference in
doing Agile Development.  The different is so pervasive that I
think it deserves by its own merits to be granted at least the
possibility of being a true paradigm shift.  But only time
will tell.  In fact, Kuhn reminds us that the success of a
paradigm shift and a revolution is typically guided by
many factors including strong personalities.  (In this case
we beg your endorsement.... )

I believe that this paradigm shift is rooted at its very core in
self-organization, because this is the essence or the difference.

This is the generative quality that leads to many other things like:

1. Management pyramid is inverted
2. Greater Liberty and Freedom to accomplish the task at hand
3. Constant Learning, Knowledge Creation and Knowledge Sharing
4. A More Enjoyable and Humane Work Environment
5. A Hyper-productive Cooperative Work Mode
6. Emergent Planning, Architecture and Requirements
7. New values that generate a cooperative culture
8. The Quality of Life

More on this at: http://c2.com/cgi-bin/wiki?AgileRevolution

Grady Booch wrote:
> [egb> ] I find it telling to note that, if you look at some of
> the hard core methodologists from the previous and contemporary
> generations of analysis and design methods - Ed Yourdon, Larry
Constantine,
> Tom DeMarco, Kent, myself, and others - virtually all of that group
> have morphed to confronting the human issue of development. That's not
> to say that tools and methods are irrelevant - they can amplify human
> ability, eliminate errors, help us better reason about complex things -
> rather, it's the social dynamics among individuals, within small teams,
> and among teams of teams that are deeply critical in pushing out
> great software.

Here I agree completely.  In fact the Agile Manifesto is very clearly
in saying that:

	 We are uncovering better ways of developing
	 software by doing it and helping others do it.
	 Through this work we have come to value:

		 Individuals and interactions over processes and tools
		 Working software over comprehensive documentation
		 Customer collaboration over contract negotiation
		 Responding to change over following a plan

	 That is, while there is value in the items on
	 the right, we value the items on the left more.

The operative memes being "we have come to value" and "over",

- Mike

Laurent Bossavit wrote:
> I'm also reminded of Kent's admonition to CS researches to find
> ways to measure XP that aren't myopically focused on the
> practices. That, or so it seems to me, amounts to saying that *our*
> observations of software development tend to be just as theory-
> laden.

Imo, it goes both ways.  It is a self-constant solution in the
mathematical meaning, an a Gestalt like solution in the cognitive sense:

	 Practices (patterns) generate values, values generate practices
	 (patterns) etc.

Except there are other dynamical relationships:

	 Practices generate dynamic processes and organizations, dynamic
	 processes and organizations reinforce practices, etc.


Laurent Bossavit wrote:
> To me, this suggests that the competing conceptions of software
> development out there fit at least one of Kuhn's characteristic
> features of "paradigms" : they appear to be incommensurable
> among themselves.


You've got it.  These are the so-called "anomalies".  When a
paradigm repeatedly fails to explain anomalies, a "crisis"
ensues and alternative theories must be developed. Agile Software
Development presents such an alternative and attempts to
explain these or other anomalies.  In time, this alternative
can replace the old paradigm by completing a "scientific
revolution" in the field of software development.

But again, Kuhn warns that it the new paradigm needs to be
perceived as "better" by the majority of people with power and
influence.

(We talked about this before, remember?)

Laurent Bossavit wrote:
> I'm still wary of applying Kuhn's theory to software development
> philosophies, though; as Kuhn himself noted, his was a theory of
> scientific theories, and not meant to apply to other areas of
> knowledge.

Granted.  But do we have a better model to understand what's going on?


Laurent Bossavit wrote:
> I'm also wary of the word "revolution", which itself carries a lot of
> baggage. All of Mike's postings on the topic clearly imply that Agile
> thinking will eventually carry the day because it is "better"; that, if
> you will, the collapse of traditional development philosophy under
> the weight of its own contradictions is as historically inevitable as
> was the collapse of capitalism, and its dialectical resolution in a
> dictatorship of the proletariat. We've seen how that last actually
> played out.

I agree.  I use the word revolution because it comes from the Kuhnian
line of thinking.  However, I do like that word.  We need a revolution.
There _is_ a software crisis.  Far too many projects fail and go out
of control, far too much money is spent in failures, and being
a developer in most cases feels like being on a frying pan.

This is my invitation:

	 let's change the world, let's make it an "agile" world!
	 http://c2.com/cgi-bin/wiki?AgileRevolution

Undoubtedly, even if successful, agile will not the last revolution
in software development, but I think it definitely offers many valuable
things above and beyond Defined-Process methods.

I think the ultimate driver for the success of the revolution
will be ROI (return on investment):

	 If companies and projects find Agile Software Development
	 useful and valuable by generating lower cost, high value,
	 on-time software with adjustments in scope --
	 which is what Agile for the most part means,

I think this will ultimately drive its absorption into the
mainstream.  This is the value of the competitive dynamics of
capitalism.


Laurent Bossavit wrote:
> What will the world look like after 20 years of Agile / Extreme / Lean
> etc ? To me, this is the key question. And I hope that it will look
> rather different, which does make me something of a "revolutionary"
> in the traditional sense - but I will accept the label only to that
> extent, of wanting the world to be very different from what it is.

If not for any other reason... that is good enough for me as well,

- Mike

I wrote:
> Imo, it goes both ways.  It is a self-constant solution in the
> mathematical meaning, an a Gestalt like solution in the cognitive sense:

But I meant "self-consistent" not "self-constant" ...

Self-consistent solutions of course depend on rapid feedback
of inspection --> adaptation,

- Mike

> I believe that this paradigm shift is rooted at its very core in
> self-organization, because this is the essence or the difference.

[egb> ] The power of self-organizing systems does indeed have an interesting
basis of theory behind it. I've followed with great interest the work on
chaos theory at the Santa Fe Institute (see Waldrop's "Complexity"),
Camazine et al's work in "Self-Organization in Biological Systems,"
Buchanan's "Nexus", Johnson's "Emergence", and work by cognitive scientists,
especially Minsky's seminal "Society of Mind" all of which are relevant
here. Oh, there's also Brook's excellent work on subsumption architectures
which he first mentions in his classic paper "Fast, Cheap, and Out of
Control."

[egb> ] The point of all this is that it is clear that positive behavior can
emerge from a set of simple rules. As I read your posts, this seems to be
your premise, wherein the basic practices of agile stuff can lead "to many
other things" as you say.

[egb> ] However, self-organization is decidedly a very fragile thing, as
virtually all the researchers I list above observe. For such emergence to
occur, you have to have a) the right, sufficient, and necessary set of
rules, b) you have to have the right set of initial conditions, and c)
there's hysterisis in the process.

[egb> ] Does the current state of agile stuff meet these criteria? No, not
yet.

[egb> ] To begin, are the elements of the Agile Manifesto (and its
manifestation in the 12-ish Agile principles) right (probably, but not in
all cases), sufficient (decidedly not - there is much about software
development that is simply not touched upon, and the discussions of
tailoring in this thread alone point out that we've not yet codified the
meta rules of agilism), and necessary (no...people here have pointed out
situations where you can ignore/vastly morph some of the agile principles).

[egb> ] With regard to having the right set of initial conditions, this is a
hard one, for processes, like the parable of the seeds, sometimes fall on
hard ground and fail to flourish...that's not a fault of the process, but a
consequence of the culture into which that process is injected.

[egb >] Finally, self-organization takes time and energy. Systems that
operate within the laws of physics self-organize in relative real time;
systems that operate within the laws of chemical interactions take a bit
more time; systems that operate within the laws of biology take a long time
(evolution); systems that operate within the laws of human psychology take a
wide range of time (social interactions at a cocktail party versus global
cultural trends). Agilism, IMO, operates at the speed of human interaction.

[egb> ] So, I'm just cautioning you about distinguishing the value of
agilism based upon the self-organization of systems: it's a fragile thing,
easily disturbed by a variety of influences outside the control of the agile
principles.

[egb> ] I have been a part of and have also observed several software
development teams for which the experience was magical, but more often than
not, it is less than magical. Perhaps all process work is about finding a
way to recreate that magic over and over again - but experience has shown
that such magic is a very elusive thing.

Grady Booch wrote:
> [egb> ] However, self-organization is decidedly a very fragile thing, as
> virtually all the researchers I list above observe. For such emergence to
> occur, you have to have a) the right, sufficient, and necessary set of
> rules, b) you have to have the right set of initial conditions, and c)
> there's hysterisis in the process.

Grady:

I disagree.  I have been running Scrum teams for 6 years and
about 2 years of Scrum and XP mixed together, and I have never felt
stronger, and more certain in running software projects.  All of my projects
are based on self-organization and are not a "very fragile thing".

But I do get to see a lot of defined-process and RUP failures -- they
appear fragile to me, and I have a large set of anecdotal experience to
illustrate my views.


Grady Booch wrote:
> [egb> ] Does the current state of agile stuff meet these criteria? No, not
> yet.

Well, it all depends, which "agile" we are talking about.

From the Scrum and XP perspective I think they _do_ meet the
criteria.

Have you ever run an XP or a Scrum project, btw?  You would know if
you had.


Grady Booch wrote:
> [egb> ] To begin, are the elements of the Agile Manifesto (and its
> manifestation in the 12-ish Agile principles) right (probably, but not in
> all cases), sufficient (decidedly not - there is much about software
> development that is simply not touched upon, and the discussions of
> tailoring in this thread alone point out that we've not yet codified the
> meta rules of agilism), and necessary (no...people here have pointed out
> situations where you can ignore/vastly morph some of the agile
> principles).

The Agile Manifesto simply contains a summary of the agile principles
17 guys could articulate in 2 days.  It is a good start, but do not
reflect all of the rules, values, practices, patterns, and principles,
that are embedded into each of the agile methods.


Grady Booch wrote:
> [egb> ] With regard to having the right set of initial
> conditions, this is a hard one, for processes, like the parable of
> the seeds, sometimes fall on hard ground and fail to flourish...that's
> not a fault of the process, but a consequence of the culture into
> which that process is injected.

Sounds like a "process" crisis to me, in the sense that you are trying
to control through process things that are above and beyond its
capability.


Grady Booch wrote:
> [egb >] Finally, self-organization takes time and energy. Systems that
> operate within the laws of physics self-organize in relative real time;
> systems that operate within the laws of chemical interactions take a bit
> more time; systems that operate within the laws of biology take a
> long time (evolution); systems that operate within the laws of human
> psychology take a wide range of time (social interactions at
> a cocktail party versus global cultural trends). Agilism, IMO,
> operates at the speed of human interaction.

It works in practice.  If you ran Scrum or XP projects you would know.

Just ask the practitioners in this list.


Grady Booch wrote:
> [egb> ] So, I'm just cautioning you about distinguishing the value of
> agilism based upon the self-organization of systems: it's a fragile thing,
> easily disturbed by a variety of influences outside the control
> of the agile principles.

I disagree on two counts:  a) it doesn't feel fragile in practice, and b)
the agile principles are not the only thing at play.

Grady Booch wrote:
> [egb> ] I have been a part of and have also observed several software
> development teams for which the experience was magical, but more
> often than not, it is less than magical. Perhaps all process work
> is about finding a way to recreate that magic over and over
> again - but experience has shown that such magic is a very elusive thing.


Perhaps is about thinking out of the "process" box :-)

- Mike