I won't attempt to answer your question because I'm kind of wondering
the same thing (except that my version is 'Isn't the XP planning game
just a scaled-down version of Scrum?')

I would like to make a few comments in support of Scrum however:

1.  Scrum is scalable.  There are precedents for having Scrums of
Scrums of Scrums, which is critical if you want to use agile methods
across an organization, or on very large teams.

2.  I think the Scrum concept of a backlog is more sophisticated than
anything on the XP side.  The flow from Product Backlog to Version
Backlog to Sprint Backlog gives you a nice clean way to manage a
product roadmap without sacrificing flexibility.

3.  Scrum is something that professional managers can relate to.
These guys don't care about continuous integration or unit testing.
XP is largely outside of their world, which means that they will have
a hard time relating to development.  Scrum is something they can
sink their teeth into, and it can act as a 'contract' between them
and development that both sides can understand.

4.  Like you said, Scrum can be an easier way to "go agile" than XP.
If you're walking into an environment with no unit tests, no
continuous integration and developers that break out in hives at the
mention of pair programming, you can still implement Scrum fairly
easily.

My impression is that both XP and Scrum have crude 'stubs' of each
other built into them, which suggests that they were meant to be used
together - which begs the question, "Is Scrum going to end up just
being part of XP?"

--- In scrumdevelopment@y..., Lowell Lindstrom <lindstrom@o...> wrote:
> I can't seem to find a substantial difference between the XP
Planning Game
> and Scrum.  There are subtle differences, but if the team is
adapting their
> work as they proceed, I can't see why I starting with one versus
the other
> would have make any difference in the outcome of the project.
>
> I can see how Scrum would be a way to move towards XP in a "non-XP-
friendly"
> environment or simply a way to be Agile, if I not using XP
programming
> practices.
>
> If I am in an "XP-friendly" environment, I would not want to
complicate
> things by introducing Scrum terminology for project management,
which is
> largely redundant to the Planning Game.
>
>
>
> > -----Original Message-----
> > From: kschwaber [mailto:ken.schwaber@v...]
> > Sent: Monday, May 13, 2002 2:00 PM
> > To: extremeprogramming@y...
> > Subject: [XP] Scrum and XP
> >
> >
> > On May 12, Ron Jefferies wrote:
> >
> > >> What does Scrum seem to have that XP does not? It seems to me
that
> > >> Scrum is a subset of XP.
> >
> > I used to think that XP was a subset of Scrum until I understood
XP
> > better. Then I understood that Scrum is a set of business and
project
> > management practices, XP is a set of engineering practices. They
both
> > use iterations, increments, emergence, self-organization, and
> > collaboration, so I've been able to use each of them to make up
for
> > what the other doesn't address.
> >
> > Ken Schwaber
> >

Lowell Lindstrom wrote:
> I can't seem to find a substantial difference between
> the XP Planning Game and Scrum.  There are subtle
> differences, but if the team is adapting their
> work as they proceed, I can't see why I starting
> with one versus the other would have make any
> difference in the outcome of the project.

Lowell:

Your assessment is correct.  However, there is a glitch:
the planning game is like Scrum, but Scrum has a larger
scope than the planning game.  Let me explain.

Kent Beck, which invented the "planning game", by his own
account got a lot of inspiration from Scrum.  (Kent if you
are lurking can you please comment?)  So, yes, there is
a great deal of overlap.  And a lot of credit should go
to Kent for "borrowing" things from Scrum.  After all,
he had the hard job to find and choose the
"simplest thing that worked for management". And he did,
he found and chose Scrum, after looking at hundreds if
not thousands of "management frameworks" over the years.

However, the Product Backlog in Scrum includes much more
than the functional user stories.  And it is for this
reason that XP (with the planning game) is different than
practicing Scrum + XP -- because Scrum includes _all_
activities, not only the functional software stories.

So for example, business analysis, business design,
training, integration, CM, System Test, product upgrades,
business changes, and _any_ other activities are all part
of the Scrum Product Backlog, but they wouldn't be part of
the XP stories.

For example, Martine Devos and I have used it for in
the past for BPR (business process reengineering),
and Jeff and Ken have used it for a myriad of other
activities related and unrelated to software development.

In fact, when Ken and I wrote "Agile Software Development
with Scrum" we made the conscious decision to not mix
any other software development practices in explaining
Scrum, because we didn't want people to confuse Scrum
with being "just another software development method".

Instead, we wanted to make the statement that Scrum is
"agile management" and it works for any activity,
not only software development.  In contrast XP minus
the planning game, is a collection of practices or
patterns for "agile software engineering".

You should also know that in our meeting last year at
Snowbird UT, which got the agilealliance.org started, Kent
was the most vocal advocate in having a Scrum book written,
because as he stated, and I am paraphrasing:  there weren't
any reference materials he could quote (with ISBN numbers).

The only thing available at the time were a few websites:
http://www.controlchaos.com
http://www.jeffsutherland.com
etc.

and he felt that websites unfortunately are fairly volatile.

Now of course there is that book, "Agile Software Development
with Scrum", written by a couple of software rebels
(with a cause).

Lowell Lindstrom wrote:
> I can see how Scrum would be a way to move
> towards XP in a "non-XP-friendly" environment or
> simply a way to be Agile, if I not using XP programming
> practices.
> If I am in an "XP-friendly" environment, I would
> not want to complicate things by introducing Scrum
> terminology for project management, which is
> largely redundant to the Planning Game.

But just remember there _is_ a difference between XP's
planning game and Scrum.  When the sources of change
are contained within the functional user stories you
should be ok with XP.

However, when all sort of things start to change, it is probably
best to move to Scrum because Scrum provides and agile
management framework to manage _all_ of the activities
of many related projects at all levels of the organization.

How can this be beneficial?  Well, there are weird
examples of Scrum being applied in cases where the
development tools change in the middle of development
(databases, IDEs, programming languages, etc.), or
when _radical_ business changes change the architecture
of a large system, or when there are issues about coordinating
the activities of multiple teams: Application teams,
Testing, CM/Integration, Systems Support, etc.

In all cases, Scrum continues to deliver through the
realization of Product Backlog items.

This difference is in fact the source of inspiration
for what we practice at Hipaa Accelerator and e-Architects:
XBreed, which is Scrum for management, XP for engineering,
Alexanderian ideas, and a few new original ideas mixed
throughout.

More on XBreed at: http://www.xbreed.net

Btw, the name XBreed, means "cross breed" and it represents
the genetic combination of Scrum and XP (the combination of patterns).
And as nature would have it, it represents the survival of
the strongest genes from cross-breeding three already very
strong animals:

	 Scrum, XP, and Alexanderian Patterns theory/philosophy.

- Mike

http://www.hipaaccelerator.com
We are hiring Java Developers, architects and project managers.
http://www.e-architects.com

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

http://www.agilealliance.org

Scrum is for any development project (we even used it for marketing
programs), including software development. XP is for software engineering.
Scrum and XP work together great on software engineering projects, where
neither work that well by themselves. Scrum is going to reengineer IT in
organizations, from over the wall projects owned by IT, to projects owned by
users that are staffed by responsible XP trained IT teams. XP is a subset of
Scrum. XP@Scrum.
Ken

-----Original Message-----
From: andycirillo [mailto:acirillo@...]
Sent: Wednesday, May 15, 2002 2:37 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Re: [XP] Scrum and XP


I won't attempt to answer your question because I'm kind of wondering
the same thing (except that my version is 'Isn't the XP planning game
just a scaled-down version of Scrum?')

I would like to make a few comments in support of Scrum however:

1.  Scrum is scalable.  There are precedents for having Scrums of
Scrums of Scrums, which is critical if you want to use agile methods
across an organization, or on very large teams.

2.  I think the Scrum concept of a backlog is more sophisticated than
anything on the XP side.  The flow from Product Backlog to Version
Backlog to Sprint Backlog gives you a nice clean way to manage a
product roadmap without sacrificing flexibility.

3.  Scrum is something that professional managers can relate to.
These guys don't care about continuous integration or unit testing.
XP is largely outside of their world, which means that they will have
a hard time relating to development.  Scrum is something they can
sink their teeth into, and it can act as a 'contract' between them
and development that both sides can understand.

4.  Like you said, Scrum can be an easier way to "go agile" than XP.
If you're walking into an environment with no unit tests, no
continuous integration and developers that break out in hives at the
mention of pair programming, you can still implement Scrum fairly
easily.

My impression is that both XP and Scrum have crude 'stubs' of each
other built into them, which suggests that they were meant to be used
together - which begs the question, "Is Scrum going to end up just
being part of XP?"

--- In scrumdevelopment@y..., Lowell Lindstrom <lindstrom@o...> wrote:
> I can't seem to find a substantial difference between the XP
Planning Game
> and Scrum.  There are subtle differences, but if the team is
adapting their
> work as they proceed, I can't see why I starting with one versus
the other
> would have make any difference in the outcome of the project.
>
> I can see how Scrum would be a way to move towards XP in a "non-XP-
friendly"
> environment or simply a way to be Agile, if I not using XP
programming
> practices.
>
> If I am in an "XP-friendly" environment, I would not want to
complicate
> things by introducing Scrum terminology for project management,
which is
> largely redundant to the Planning Game.
>
>
>
> > -----Original Message-----
> > From: kschwaber [mailto:ken.schwaber@v...]
> > Sent: Monday, May 13, 2002 2:00 PM
> > To: extremeprogramming@y...
> > Subject: [XP] Scrum and XP
> >
> >
> > On May 12, Ron Jefferies wrote:
> >
> > >> What does Scrum seem to have that XP does not? It seems to me
that
> > >> Scrum is a subset of XP.
> >
> > I used to think that XP was a subset of Scrum until I understood
XP
> > better. Then I understood that Scrum is a set of business and
project
> > management practices, XP is a set of engineering practices. They
both
> > use iterations, increments, emergence, self-organization, and
> > collaboration, so I've been able to use each of them to make up
for
> > what the other doesn't address.
> >
> > Ken Schwaber
> >



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/

-----Original Message-----
From: andycirillo [mailto:acirillo@...]
Sent: Wednesday, May 15, 2002 1:37 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Re: [XP] Scrum and XP

I won't attempt to answer your question because I'm kind of wondering
the same thing (except that my version is 'Isn't the XP planning game
just a scaled-down version of Scrum?')

I would like to make a few comments in support of Scrum however:

1.  Scrum is scalable.  There are precedents for having Scrums of
Scrums of Scrums, which is critical if you want to use agile methods
across an organization, or on very large teams.

2.  I think the Scrum concept of a backlog is more sophisticated than
anything on the XP side.  The flow from Product Backlog to Version
Backlog to Sprint Backlog gives you a nice clean way to manage a
product roadmap without sacrificing flexibility.

3.  Scrum is something that professional managers can relate to. 
These guys don't care about continuous integration or unit testing. 
XP is largely outside of their world, which means that they will have
a hard time relating to development.  Scrum is something they can
sink their teeth into, and it can act as a 'contract' between them
and development that both sides can understand.

4.  Like you said, Scrum can be an easier way to "go agile" than XP. 
If you're walking into an environment with no unit tests, no
continuous integration and developers that break out in hives at the
mention of pair programming, you can still implement Scrum fairly
easily.

My impression is that both XP and Scrum have crude 'stubs' of each
other built into them, which suggests that they were meant to be used
together - which begs the question, "Is Scrum going to end up just
being part of XP?"

--- In scrumdevelopment@y..., Lowell Lindstrom <lindstrom@o...> wrote:
> I can't seem to find a substantial difference between the XP
Planning Game
> and Scrum.  There are subtle differences, but if the team is
adapting their
> work as they proceed, I can't see why I starting with one versus
the other
> would have make any difference in the outcome of the project.
>
> I can see how Scrum would be a way to move towards XP in a "non-XP-
friendly"
> environment or simply a way to be Agile, if I not using XP
programming
> practices.
>
> If I am in an "XP-friendly" environment, I would not want to
complicate
> things by introducing Scrum terminology for project management,
which is
> largely redundant to the Planning Game.
>
>
>
> > -----Original Message-----
> > From: kschwaber [mailto:ken.schwaber@v...]
> > Sent: Monday, May 13, 2002 2:00 PM
> > To: extremeprogramming@y...
> > Subject: [XP] Scrum and XP
> >
> >
> > On May 12, Ron Jefferies wrote:
> >
> > >> What does Scrum seem to have that XP does not? It seems to me
that
> > >> Scrum is a subset of XP.
> >
> > I used to think that XP was a subset of Scrum until I understood
XP
> > better. Then I understood that Scrum is a set of business and
project
> > management practices, XP is a set of engineering practices. They
both
> > use iterations, increments, emergence, self-organization, and
> > collaboration, so I've been able to use each of them to make up
for
> > what the other doesn't address.
> >
> > Ken Schwaber
> >



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 Beedle [mailto:beedlem@...]
Sent: Wednesday, May 15, 2002 8:57 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Re: [XP] Scrum and XP

 

Andy:

 

Great response.  You make a couple of very good points about the separation of

concerns (management/engineering) and about the scope of each.

 

However, let me focus on your question:  "Is Scrum going to end up just being part of XP?"

 

Here is my take:  not a chance.  If anything, XP might eventually adopt a "full Scrum"

approach, and eventually get closer to a full gene mix of XP and Scrum.  But many of

us have already passed that level even 2 years ago.

 

However, XP@Scrum and XBreed have gone beyond that level by seeking very specific goals

that will contribute with more agile practices/patterns.

 

In the case of XP@Scrum the new extra practices will come from the emphasis on

"Business-Value Driven Development".  I am anxious to get a copy of Ken and Kane's

new book on  Business-Value Driven Development.  Ken, do you guys have concrete

date for when we might expect this book?  

 

In the case of XBreed, the new practices will come from the goal of creating a

layered framework of reusable components shared among many contributing teams.

 

- Mike 

 

-----Original Message-----
From: andycirillo [mailto:acirillo@...]
Sent: Wednesday, May 15, 2002 1:37 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Re: [XP] Scrum and XP

I won't attempt to answer your question because I'm kind of wondering
the same thing (except that my version is 'Isn't the XP planning game
just a scaled-down version of Scrum?')

I would like to make a few comments in support of Scrum however:

1.  Scrum is scalable.  There are precedents for having Scrums of
Scrums of Scrums, which is critical if you want to use agile methods
across an organization, or on very large teams.

2.  I think the Scrum concept of a backlog is more sophisticated than
anything on the XP side.  The flow from Product Backlog to Version
Backlog to Sprint Backlog gives you a nice clean way to manage a
product roadmap without sacrificing flexibility.

3.  Scrum is something that professional managers can relate to. 
These guys don't care about continuous integration or unit testing. 
XP is largely outside of their world, which means that they will have
a hard time relating to development.  Scrum is something they can
sink their teeth into, and it can act as a 'contract' between them
and development that both sides can understand.

4.  Like you said, Scrum can be an easier way to "go agile" than XP. 
If you're walking into an environment with no unit tests, no
continuous integration and developers that break out in hives at the
mention of pair programming, you can still implement Scrum fairly
easily.

My impression is that both XP and Scrum have crude 'stubs' of each
other built into them, which suggests that they were meant to be used
together - which begs the question, "Is Scrum going to end up just
being part of XP?"

--- In scrumdevelopment@y..., Lowell Lindstrom <lindstrom@o...> wrote:
> I can't seem to find a substantial difference between the XP
Planning Game
> and Scrum.  There are subtle differences, but if the team is
adapting their
> work as they proceed, I can't see why I starting with one versus
the other
> would have make any difference in the outcome of the project.
>
> I can see how Scrum would be a way to move towards XP in a "non-XP-
friendly"
> environment or simply a way to be Agile, if I not using XP
programming
> practices.
>
> If I am in an "XP-friendly" environment, I would not want to
complicate
> things by introducing Scrum terminology for project management,
which is
> largely redundant to the Planning Game.
>
>
>
> > -----Original Message-----
> > From: kschwaber [mailto:ken.schwaber@v...]
> > Sent: Monday, May 13, 2002 2:00 PM
> > To: extremeprogramming@y...
> > Subject: [XP] Scrum and XP
> >
> >
> > On May 12, Ron Jefferies wrote:
> >
> > >> What does Scrum seem to have that XP does not? It seems to me
that
> > >> Scrum is a subset of XP.
> >
> > I used to think that XP was a subset of Scrum until I understood
XP
> > better. Then I understood that Scrum is a set of business and
project
> > management practices, XP is a set of engineering practices. They
both
> > use iterations, increments, emergence, self-organization, and
> > collaboration, so I've been able to use each of them to make up
for
> > what the other doesn't address.
> >
> > Ken Schwaber
> >



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.

> -----Original Message-----
> From: Mike Beedle [mailto:beedlem@...]
> Lowell Lindstrom wrote:
> > I can't seem to find a substantial difference between
> > the XP Planning Game and Scrum.  There are subtle
> > differences, but if the team is adapting their
> > work as they proceed, I can't see why I starting
> > with one versus the other would have make any
> > difference in the outcome of the project.
>
> Lowell:
>
> Your assessment is correct.  However, there is a glitch:
> the planning game is like Scrum, but Scrum has a larger
> scope than the planning game.  Let me explain.
>
> [background clipped.....]

I appreciate the background.  I think it gives some explanation as to why we
have two sets of practices that are so similar, yet have different names.
For the practitioner, I don't believe that the historical relationship
between XP and Scrum are important.  My main point was that if you are
evolving your practices, XP Planning (or Scrum) will evolve to include the
parts of the Scrum (or XP) that it needs.  I don't need to confuse the
process by introducing Scrum terminology (XP Planning terminology).  From
the first XP Immersion course, when the questioned was raised about
documentation and other "stories" that don't end up as software tasks, the
answer has been "if you need them, you can make them stories and plan them
with the planning game."  Adapt as you need based on feedback from the
process.

They will evolve to the same result in practice without the shift in
terminology.  The XP@Scrum thing seems forced to me, unless I am in an
existing Scrum shop.  If I am with a team that is new to both, I am
introducing un-needed complexity with redundant practices.  XP Planning is
sufficient in this case.

I am not advocating XP over Scrum or vice versa.  It is the combination
that, to me, that has unneeded complexity for the new team.

>
> However, when all sort of things start to change, it is probably
> best to move to Scrum because Scrum provides and agile
> management framework to manage _all_ of the activities
> of many related projects at all levels of the organization.
>

I am unclear why I need to rename everything when the practices are
basically the same.  Why is it not sufficient to simply keep the XP Planning
terminology, in this case, and use the practices on non-functional stories?
This seems much more simple to me.  I just don't see much benefit to balance
against the cost of re-learning.  This becomes particularly important in
larger organizations.

>
> This difference is in fact the source of inspiration
> for what we practice at Hipaa Accelerator and e-Architects:
> XBreed, which is Scrum for management, XP for engineering,
> Alexanderian ideas, and a few new original ideas mixed
> throughout.
>

Did you consider expressing XBreed as simply additional practices to Scrum,
XP, and Patterns?   Having yet another agile method that primarily overlaps
with others seems like forced complexity.  If we were talking about code,
wouldn't we refactor these to avoid the duplication?  It feels like we are
going to brand a new methodolgy with every project rather than grow and
adapt the toolkit of agile practices as we learn more and apply these ideas
to new domains and technologies.

Lowell,
The reason why we go through the extra effort to rationalize the overlapping
names between Scrum and XP is that Scrum terminology is more understood,
more business natural. It fits with business project and product managers.
XP is more OO and engineering-centric and feels alien to this audience. It's
our way to get agile used with XP engineering practices. It eases the
implementation of XP and allows us to scale XP elsewhere in the
organization.
Ken

-----Original Message-----
From: Lowell Lindstrom [mailto:lindstrom@...]
Sent: Wednesday, May 15, 2002 10:53 AM
To: 'extremeprogramming@yahoogroups.com';
scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] RE: [XP] Scrum and XP


> -----Original Message-----
> From: Mike Beedle [mailto:beedlem@...]
> Lowell Lindstrom wrote:
> > I can't seem to find a substantial difference between
> > the XP Planning Game and Scrum.  There are subtle
> > differences, but if the team is adapting their
> > work as they proceed, I can't see why I starting
> > with one versus the other would have make any
> > difference in the outcome of the project.
>
> Lowell:
>
> Your assessment is correct.  However, there is a glitch:
> the planning game is like Scrum, but Scrum has a larger
> scope than the planning game.  Let me explain.
>
> [background clipped.....]

I appreciate the background.  I think it gives some explanation as to why we
have two sets of practices that are so similar, yet have different names.
For the practitioner, I don't believe that the historical relationship
between XP and Scrum are important.  My main point was that if you are
evolving your practices, XP Planning (or Scrum) will evolve to include the
parts of the Scrum (or XP) that it needs.  I don't need to confuse the
process by introducing Scrum terminology (XP Planning terminology).  From
the first XP Immersion course, when the questioned was raised about
documentation and other "stories" that don't end up as software tasks, the
answer has been "if you need them, you can make them stories and plan them
with the planning game."  Adapt as you need based on feedback from the
process.

They will evolve to the same result in practice without the shift in
terminology.  The XP@Scrum thing seems forced to me, unless I am in an
existing Scrum shop.  If I am with a team that is new to both, I am
introducing un-needed complexity with redundant practices.  XP Planning is
sufficient in this case.

I am not advocating XP over Scrum or vice versa.  It is the combination
that, to me, that has unneeded complexity for the new team.

>
> However, when all sort of things start to change, it is probably
> best to move to Scrum because Scrum provides and agile
> management framework to manage _all_ of the activities
> of many related projects at all levels of the organization.
>

I am unclear why I need to rename everything when the practices are
basically the same.  Why is it not sufficient to simply keep the XP Planning
terminology, in this case, and use the practices on non-functional stories?
This seems much more simple to me.  I just don't see much benefit to balance
against the cost of re-learning.  This becomes particularly important in
larger organizations.

>
> This difference is in fact the source of inspiration
> for what we practice at Hipaa Accelerator and e-Architects:
> XBreed, which is Scrum for management, XP for engineering,
> Alexanderian ideas, and a few new original ideas mixed
> throughout.
>

Did you consider expressing XBreed as simply additional practices to Scrum,
XP, and Patterns?   Having yet another agile method that primarily overlaps
with others seems like forced complexity.  If we were talking about code,
wouldn't we refactor these to avoid the duplication?  It feels like we are
going to brand a new methodolgy with every project rather than grow and
adapt the toolkit of agile practices as we learn more and apply these ideas
to new domains and technologies.



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/

Workshop on Empirical Evaluation of Agile Processes (EEAP 2002)
===============================================================

http://sern.ucalgary.ca/eeap/

Chicago, Illinois, USA, August 7, 2002, Marriott Lincolnshire
Held in conjunction with XP/Agile Universe 2002

Background
----------
Imagine the benefits of knowing that an XP project expends more effort understanding software requirements than does a team using a typical traditional, or waterfall approach. Imagine the benefits of being able to predict that for this particular combination of customer, product, and project team, agile modeling is going to benefit the team more than a strict XP implementation. The world we seek is one that demystifies the success of agile methods and supports everyday practitioners to apply the right method at the right time. We believe measurements are key to making these decisions and to making agile methods more accessible.

Goals
-----
The goals of this workshop are to attract those who believe that software development methods require measurement to establish a framework for 1) controlling an agile software process; 2) determining the situations when applying agile methods would be beneficial and 3) planning and budgeting for a software development effort that involve agile methods. The intent is to discuss the current state of ongoing empirical research efforts in agile methods and to work towards establishing an agile measurement framework.

Important Dates
---------------
Deadline for submission of position papers: June 15, 2002
Notification of acceptance: July 7, 2002
Workshop date: August 7, 2002

More Information
----------------

Visit the EEAP 2002 web site at http://sern.ucalgary.ca/eeap/ for all the details of the workshop, or contact one of the organizers directly:

Grigori Melnik (Primary Contact)
Southern Alberta Institute of Technology (SAIT)
Department of Information and Communications Technologies
1301 - 16th Ave. N.W.
Calgary, AB, T2M 0L4
403-284-8970
grigori.melnik@...

Adam Geras
University of Calgary
Department of Electrical and Computer Engineering
2400 University Dr. N.W.
Calgary, AB T2N 1N4
403-519-0061
ageras@...

Laurie Williams
North Carolina State University
Department of Computer Science
Campus Box 7534
1010 Main Campus Road, 407 EGRC
Raleigh, NC 27695
919-513-4151
williams@...

Scrum is for any development project (we even used it for marketing
programs), including software development. XP is for software engineering.
Scrum and XP work together great on software engineering projects, where
neither work that well by themselves. Scrum is going to reengineer IT in
organizations, from over the wall projects owned by IT, to projects owned by
users that are staffed by responsible XP trained IT teams. XP is a subset of
Scrum. XP@Scrum.
Ken

-----Original Message-----
From: andycirillo [mailto:acirillo@...]
Sent: Wednesday, May 15, 2002 2:37 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Re: [XP] Scrum and XP


I won't attempt to answer your question because I'm kind of wondering
the same thing (except that
my version is 'Isn't the XP planning game
just a scaled-down version of Scrum?')

I would like to make a few comments in support of Scrum however:

1. Scrum is scalable. There are precedents for having Scrums of
Scrums of Scrums, which is critical if you want to use agile methods
across an organization, or on very large teams.

2. I think the Scrum concept of a backlog is more sophisticated than
anything on the XP side. The flow from Product Backlog to Version
Backlog to Sprint Backlog gives you a nice clean way to manage a
product roadmap without sacrificing flexibility.

3. Scrum is something that professional managers can relate to.
These guys don't care about continuous integration or unit testing.
XP is largely outside of their world, which means that they will have
a hard time relating to development. Scrum is something they can
sink their teeth into, and it can act as a 'contract' between them
and developm
ent that both sides can understand.

4. Like you said, Scrum can be an easier way to "go agile" than XP.
If you're walking into an environment with no unit tests, no
continuous integration and developers that break out in hives at the
mention of pair programming, you can still implement Scrum fairly
easily.

My impression is that both XP and Scrum have crude 'stubs' of each
other built into them, which suggests that they were meant to be used
together - which begs the question, "Is Scrum going to end up just
being part of XP?"

--- In scrumdevelopment@y..., Lowell Lindstrom <lindstrom@o...> wrote:

I can't seem to find a substantial difference between the XP

Planning Game

and Scrum. There are subtle differences, but if the team is

adapting their

work as they proceed, I can't see why I starting with one versus

the other

would have make any difference in the outcome of the project.

I can see how Scrum would be a way to move towards XP in a "non-XP-

friendly"

environment or simply a way to be Agile, if I not using XP

programming

practices.

If I am in an "XP-friendly" environment, I would not want to

complicate

things by introducing Scrum terminology for project management,

which is

largely redundant to the Planning Game.

-----Original Message-----
From: kschwaber [mailto:ken.schwaber@v...]
Sent: Monday, May 13, 2002 2:00 PM
To: extremeprogramming@y...
Subject: [XP] Scrum and XP


On May 12, Ron Jefferies wrote:

What does Scrum seem to have that XP does not? It seems to me

that

Scrum is a subset of XP.

I used to think that XP was a subset of Scrum until I understood

XP

better. Then I understood that Scrum is a set of business and

project

management practices, XP is a set of engineering practices. They

both

use iterations, increments, emergence, self-organization, and
collaboration, so I've been able to use each of them to make up

for

what the other doesn't address.

Ken Schwaber

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/




------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Stock for $4
and no minimums.
FREE Money 2002.
http://us.click.yahoo.com/orkH0C/n97DAA/Ey.GAA/9EfwlB/TM
---------------------------------------------------------------------~->

To Post a message, s
end 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/ 

Lowell,
The reason why we go through the extra effort to rationalize the overlapping
names between Scrum and XP is that Scrum terminology is more understood,
more business natural. It fits with business project and product managers.
XP is more OO and engineering-centric and feels alien to this audience. It's
our way to get agile used with XP engineering practices. It eases the
implementation of XP and allows us to scale XP elsewhere in the
organization.
Ken

-----Original Message-----
From: Lowell Lindstrom [mailto:lindstrom@...]
Sent: Wednesday, May 15, 2002 10:53 AM
To: 'extremeprogramming@yahoogroups.com';
scrumdevelopment@yahoogroups.com
Subject: [sc
rumdevelopment] RE: [XP] Scrum and XP

-----Original Message-----
From: Mike Beedle [mailto:beedlem@...]
Lowell Lindstrom wrote:

I can't seem to find a substantial difference between
the XP Planning Game and Scrum. There are subtle
differences, but if the team is adapting their
work as they proceed, I can't see why I starting
with one versus the other would have make any
difference in the outcome of the project.

Lowell:

Your assessment is correct. However, there is a glitch:
the planning game is like Scrum, but Scrum has a larger
scope than the planning game. Let me explain.

[background clipped.....]

I appreciate the background. I think it gives some explanation as to why we
have two sets of practices that are so similar, yet have different names.
For the practitioner, I don't believe that the historical relationship
between XP and Scrum are important. My main point was that if you are
evolving your practices, XP Planning (or Scrum) will evolve to include the
parts of the Scrum (or XP) that it needs. I don't need to confuse the
process by introducing Scrum terminology (XP Planning terminology). From
the first XP Immersion course, when the questioned was raised about
documentation and other "stories" that don't end up as software tasks, the
answer has been "if you need them, you can make them stories and plan them
with the planning game." Adapt as you need based on feedback from the
process.

They will evolve to the same result in practice without the shift in
terminology. The XP@Scrum thing see
ms forced to me, unless I am in an
existing Scrum shop. If I am with a team that is new to both, I am
introducing un-needed complexity with redundant practices. XP Planning is
sufficient in this case.

I am not advocating XP over Scrum or vice versa. It is the combination
that, to me, that has unneeded complexity for the new team.

However, when all sort of things start to change, it is probably
best to move to Scrum because Scrum provides and agile
management framework to manage _all_ of the activities
of many related projects at all levels of the organization.

I am unclear why I need to rename everything when the practices are
basically the same. Why is it not sufficient to simply keep the XP Planning
terminology, in this case, and use the practices on non-functional stories?
This seems much more simple to me. I just don't see much benefit to balance
against the cost of re-learning. This becomes particularly important in
larger organizations.

This difference is in fact the source of inspiration
for what we practice at Hipaa Accelerator and e-Architects:
XBreed, which is Scrum for management, XP for engineering,
Alexanderian ideas, and a few new original ideas mixed
throughout.

Did you consider expressing XBreed as simply additional practices to Scrum,
XP, and Patterns? Having yet another agile method that primarily overlaps
with others seems like forced complexity. If we were talking about code,
wouldn't we refactor these to avoid the duplication? It feels like we are
going to brand a new methodolgy with every project rather than grow and
adapt the toolkit of agile practices as we learn more and apply these ideas
to new domains and technologies.



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/



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Stock for $4
and no minimums.
FREE Money 2002.
http://us.click.yahoo.com/orkH0C/n97DAA/Ey.GAA/9EfwlB/TM
---------------------------------------------------------------------~->

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/ 

Linda and Ken -

Can you provide some more detail here?  I have had no more trouble getting
business people engaged in XP than technical.  In fact, often the technical
folks are more difficult given the emotion around pairing.

Linda, was it the business people that were the obstacle until you switched
from XP to Scrum or the developers?  What did people like about Scrum?  Did
the rocket of Scrum adoption lead to greater acceptance of the XP practices?

Ken, I would guess that you always lead with Scrum?  Have you ever tried to
introduce XP only.  I wouldn't expect so and I don't mean that as a
challenge. I am just interested in what you have experienced.

As I stated before, my point here is not to advocate XP over Scrum or vice
versa.   I know one much better than the other, so that is my comfort zone,
that is where I can improvise with the greatest ease.  I am mainly trying to
learn more about Scrum.  I read the book to learn how Scrum could supplement
XP Planning for organizations that are scaling XP and dealing with multiple
team planning issues.  It is still not clear to me why I would bring in
Scrum rather than simply take the couple of different practices and evolve
XP in that direction.  I see teams doing this anyway who haven't even heard
of Scrum.

Thanks for the dialog!

Lowell

=============
Lowell Lindstrom
Object Mentor, Inc.
Agile Universe / XP Universe  August 4-7, 2002
http://www.agileuniverse.com
Beck, Boehm, Humphreys, Cockburn, Jeffries, Fowler talkin' Agile and XP!!!



>    From: Linda Rising <risingl@...>
>
> Maybe that explains why I was never able to sell XP to our company but
> Scrum took off like a rocket!
>
> Ken Schwaber wrote:
>
> >Lowell,
> >The reason why we go through the extra effort to rationalize
> the overlapping names between Scrum and XP is that Scrum terminology is
more
> understood, more business natural. It fits with business project and
> product managers.  XP is more OO and engineering-centric and feels alien
to
> this audience. It's our way to get agile used with XP engineering
practices. It eases the
> >implementation of XP and allows us to scale XP elsewhere in the
organization.
> >Ken
> >

Lowell Lindstrom wrote:
> I am unclear why I need to rename everything when
> the practices are basically the same.  Why is it
> not sufficient to simply keep the XP Planning
> terminology, in this case, and use the practices
> on non-functional stories?  This seems much more
> simple to me.  I just don't see much benefit
> to balance against the cost of re-learning.  This
> becomes particularly important in larger organizations.

Lowell:

As long as you know what things mean for you, go for it,
use the names that make sense to you and your project.

In different environments I use these equivalences:

	 Product Owner --> typically it is in the Customer's
				 organization (too many titles to list,
				 but an example is "Chief Privacy Officer")
	 Product Backlog Items --> Stories, Features or even UCs
	 Sprint Backlog Items --> Tasks
	 Scrum Master --> Team Leader (when you have a strong
	                  technical team)
	 Scrum Master --> Team Leader/Technical Leader
                        (when the team is technically weak)

In environments where the Scrum Master is not technical
and the team is not technically strong to distribute the
role, a new role is needed in addition:

	 Coach --> Technical Lead, Architect, (our
                 architects _always_ code at least
                 50% of the time, and mentor other in
                 design principles, patterns, and method)

Lowell Lindstrom wrote:
> Mike Beedle wrote:
> > This difference is in fact the source of inspiration
> > for what we practice at Hipaa Accelerator and e-Architects:
> > XBreed, which is Scrum for management, XP for engineering,
> > Alexanderian ideas, and a few new original ideas mixed
> > throughout.
>
> Did you consider expressing XBreed as simply additional
> practices to Scrum, XP, and Patterns?   Having yet
> another agile method that primarily overlaps with
> others seems like forced complexity.

We use a different names for 2 main reasons:

	 1) out of respect for what XP and Scrum are,
	 because we don't like to say that we do is
	 XP or Scrum and then have someone pointing out
	 that XP or Scrum don't do things like we do.

	 2) and because we like to remember,
	 "special combinations" that lead to a desired
	 specialized result.  In the case of XP@Scrum
	 is business value, and in the case of XBreed
	 is reusability.  So we abstract these special
	 combinations with a name rather than tell people:

	 * use XP
	 * use Scrum but
	 * have Scrum of Scrums that include multiple teams
	 and discuss Global Product Backlogs
	 * have Scum of Scrums among individual teams that
	 discuss Application Product Backlogs
	 * Released product in terms of code bases that
	 adhere to a layered architecture
	 * communicate releases using formatted templates
	 * Do layered testing for integration with the
	 code bases resulting from the layered architecture
	 etc., etc., etc.,

	 This description is already too long for anyone to
	 understand, so we simply say do XBreed == apply all the
	 patterns that were bagged in that collection.

Lowell Lindstrom wrote:
> If we were talking about code, wouldn't we refactor
> these to avoid the duplication?  It feels like we are going
> to brand a new methodolgy with every project rather
> than grow and adapt the toolkit of agile practices
> as we learn more and apply these ideas to new
> domains and technologies.

That is certainly the spirit of agility: use whatever makes
sense to you -- deep down, it is just one huge latent
Org Pattern Language anyhow.

(From 1996 to 1998 I spent some time in putting together
a Common Pattern Language for Organizations: it included
Scrum, Episodes (XP), Coplien's patterns, Patterns for
Customer relationships, System Test, etc.  This project
is still alive, I think, and is in the hands of Jim Coplien
and a few other people.  Our goal was to put together the
grand collection of org patterns and then offer people
the freedom to choose valid "sequences" to traverse
the pattern language.  Each sequence would yield basically
to a different way of doing things i.e. a customized
method.)

So in terms of code and patterns, what we have done with
xP@Scrum and XBreed is choose a special "sequence" of patterns
in the Alexanderian sense.

Having said that, I don't think there are any 2 projects that
are identical, so the instantiation process, by default,
always implies differences.  And these differences come
from either naming the practices differently, the roles
differently; or by simply choosing a different set of
practices.

In terms of names consider this: Monkeys and Humans have
a x > 99% overlap in their chromosome and gene sequences,
yet, this difference yields to very different animals.
However, as much as we are alike I don't think there
is any human that likes to be called a monkey
(and perhaps vice versa),

- Mike

http://www.hipaaccelerator.com
We are hiring Java Developers, architects and project managers.
http://www.e-architects.com

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

http://www.agilealliance.org

http://www.mikebeedle.com

>    From: "Mike Beedle" <beedlem@...>
> Subject: RE: Re: [XP] Scrum and XP
>
> However, let me focus on your question:  "Is Scrum going to
> end up just being part of XP?"
>
> Here is my take:  not a chance.

I agree with Mike.  I don't see this happening, nor do I think anyone needs
it to happen.

> If anything, XP might eventually adopt a "full Scrum" approach,
> and eventually get closer to a full gene mix of XP and Scrum.

Mike, here I do not understand.  Your response comes across to me as if you
feel threatened, as if XP and Scrum are in some kinda of competition with
each other.  Perhaps I am misreading.

You and Ken have had good experiences using practices from both XP and
Scrum.  I already see XP Teams naturally evolving to practices that greatly
resemble parts of Scrum (Scrum or scrums, more formal management of stories,
etc.).  They don't call it Scrum because they have never heard of Scrum.  I
don't see why we care whether XP becomes Scrum, Scrum becomes XP, or
everything is communicated under the umbrella of Agile Best Practices.  To
debate that seems to miss the point, which we all seem to agree is to find
better ways to deliver business value through software development.

Lowell

====================
Lowell Lindstrom
Object Mentor, Inc | www.objectmentor.com | 1-800-338-6716
lindstrom@...

> We use a different names for 2 main reasons:
>
>  1) out of respect for what XP and Scrum are,
>  because we don't like to say that we do is
>  XP or Scrum and then have someone pointing out
>  that XP or Scrum don't do things like we do.
>

I can definitely see wanting to avoid the "are you doing XP(Scrum)? debate."
But you are doing XP and Scrum, plus MORE.  What's interesting is the "more"
part, that variance, not the XP and Scrum.  That is where the attention
should be.  Naming the superset distracts from that.

>  2) and because we like to remember,
>  "special combinations" that lead to a desired
>  specialized result.  In the case of XP@Scrum
>  is business value, and in the case of XBreed
>  is reusability.  So we abstract these special
>  combinations with a name rather than tell people:
>

Thanks!   I understand a little better.  Somehow I missed that each had a
different emphasis.  I was under the impression that they were both simply
different combinations of XP and Scrum.

The name proliferation seems not agile to me.  It introduces unnecessary
complexity.  Surely XBreed projects want business value and XP@Scrum
projects want reuse.  A better approach is to emphasize only what is unique,
rather than the rename the whole set.  What are the set of practices that
when added to what we know as Scrum and XP lead to higher reuse?  That is a
set of practices that warrants a new label, not the superset.  Same with
XP@Scrum.  What are the practices that when added to what we know as Scrum
and XP deliver higher business value?  Call that XP@Scrum (or BVD).  If it
is just XP, with Scrum replacing the planning game, just call it "XP with
Scrum as the Planning Game" or "Scrum using XP Practices for the software
development."

> In terms of names consider this: Monkeys and Humans have
> a x > 99% overlap in their chromosome and gene sequences,
> yet, this difference yields to very different animals.
> However, as much as we are alike I don't think there
> is any human that likes to be called a monkey

Nicely phrased! Yes, I am aware that egos are involve here ;-).  I just hope
they can be kept in check enough not to kill the movement.  A proliferation
of differently names sets of methods that are basically identical has that
risk associated with it.

Lowell

====================
Lowell Lindstrom
Object Mentor, Inc | www.objectmentor.com | 1-800-338-6716
lindstrom@...

Linda and Ken -

Can you provide some more detail here? I have had no more trouble getting
business people engaged in XP than technical. In fact, often the technical
folks are more difficult given the emotion around pairing.

Linda, was it the business people that were the obstacle until you switched
from XP to Scrum or the developers? What did people like about Scrum? Did
the rocket of Scrum adoption lead to greater acceptance of the XP practices?

Ken, I would guess that you always lead with Scrum? Have you ever tried to
introduce XP only. I wouldn't expect so and I don't mean that as a
challenge. I am just interested in what you have experienced.

As I stated before, my point here is not to advocate XP over Scrum or vice
versa. I know one much better than the other, so that is my comfort zone,
that is where I can improvise with the greatest ease. I am mainly trying to
learn more about Scrum. I rea
d the book to learn how Scrum could supplement
XP Planning for organizations that are scaling XP and dealing with multiple
team planning issues. It is still not clear to me why I would bring in
Scrum rather than simply take the couple of different practices and evolve
XP in that direction. I see teams doing this anyway who haven't even heard
of Scrum.

Thanks for the dialog!

Lowell

=============
Lowell Lindstrom
Object Mentor, Inc.
Agile Universe / XP Universe August 4-7, 2002
http://www.agileuniverse.com
Beck, Boehm, Humphreys, Cockburn, Jeffries, Fowler talkin' Agile and XP!!!

 From: Linda Rising <risingl@...>

Maybe that explains why I was never able to sell XP to our company but 
Scrum took off like a rocket!

Ken Schwaber wrote:

Lowell,
The reason why we go through the extra effort to rationalize 

the overlapping names between Scrum and XP is that Scrum terminology is

more 

understood, more business natural. It fits with business project and 
product managers. XP is more OO and engineering-centric and feels alien

to 

this audience. It's our way to get agile used with XP engineering

practices. It eases the

implementation of XP and allows us to scale XP elsewhere in the

organization.

Ken

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Stock for $4
and no minimums.
FREE Money 2002.
http://us.click.yahoo.com/orkH0C/n97DAA/Ey.GAA/9EfwlB/TM
---------------------------------------------------------------------~->

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/ 

Hi Lowell,

I couldn't sell management on:

pair programming
code ownership

actually these were struggles for both management & developers.

You know, now that I think about what was going on at the time. I wasn't selling XP,
someone else was and maybe he was a bit too enthusiastic...memory fading here.
Gotta think about this some more...

I personally was selling Scrum and because of a set of lucky coincidences, I believe
I had learned how to sell new ideas. In fact, I'm writing a book of patterns about what
I did -- with my good friend, Mary Lynn Manns.

I gave a lot of talks locally about both XP and Scrum -- other companies and the
local ACM/IEEE/SPIN. Most seemed to be more interested in Scrum than XP
but, of course, I didn't work at all the places represented and usually never followed
up. The ones I did know about really never used either.

When I moved to Denmark for a year -- same thing -- gave a lot of talks -- most
people in Europe had heard of XP but no one knew anything about Scrum. Again,
they were interested but I'm not sure how many actually implemented either one.

I'm not feeling like I answered your question, Lowell!!!






Linda











Lowell Lindstrom wrote:

Linda and Ken -

Can you provide some more detail here? I have had no more trouble getting
business people engaged in XP than technical. In fact, often the technical
folks are more difficult given the emotion around pairing.

Linda, was it the business people that were the obstacle until you switched
from XP to Scrum or the developers? What did people like about Scrum? Did
the rocket of Scrum adoption lead to greater acceptance of the XP practices?

Ken, I would guess that you always lead with Scrum? Have you ever tried to
introduce XP only. I wouldn't expect so and I don't mean that as a
challenge. I am just interested in what you have experienced.

As I stated before, my point here is not to advocate XP over Scrum or vice
versa. I know one much better than the other, so that is my comfort zone,
that is where I can improvise with the greatest ease. I am mainly trying to
learn more about Scrum. I r
ea
d the book to learn how Scrum could supplement
XP Planning for organizations that are scaling XP and dealing with multiple
team planning issues. It is still not clear to me why I would bring in
Scrum rather than simply take the couple of different practices and evolve
XP in that direction. I see teams doing this anyway who haven't even heard
of Scrum.

Thanks for the dialog!

Lowell

=============
Lowell Lindstrom
Object Mentor, Inc.
Agile Universe / XP Universe August 4-7, 2002
http://www.agileuniverse.com
Beck, Boehm, Humphreys, Cockburn, Jeffries, Fowler talkin' Agile and XP!!!

 From: Linda Rising <risingl@...>

Maybe that explains why I was never able to sell XP to our company but 
Scrum took off like a rocket!

Ken Schwaber wrote:

Lowell,
The reason why we go through the extra effort to rationalize 

the overlapping names between Scrum and XP is that Scrum terminology is

more 

understood, more business natural. It fits with business project and 
product managers. XP is more OO and engineering-centric and feels alien

to 

this audience. It's our way to get agile used with XP engineering

practices. It eases the

implementation of XP and allows us to scale XP elsewhere in the

organization.

Ken

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Stock for $4
and no minimums.
FREE Money 2002.
http://us.click.yahoo.com/orkH0C/n97DAA/Ey.GAA/9EfwlB/TM
---------------------------------------------------------------------~->

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 .

Lowell,
I agree with all of your sentiments.

I lead with Scrum because I know it best since I'm more of a product manager
and project manager at this point than a developer. I probably couldn't lead
with XP because of the change management required for the engineering
practices. This doesn't mean that XP's engineering practices aren't needed!!
When the engineering practices are weak, as they are at almost IT shops
doing web development, I recommend XP and have recently been brining in
buildmasters or scrummasters from ThoughtWorks to implement them for the
customer while the project is underway.

I can bring Scrum in and within 1 day have the team developing software,
"the art of the possible." If their engineering practices are weak, the
productivity is lower and the bugs are many. As the engineering practices
improve, so do the increments of functionality. This way XP slips in bit by
bit rather than being a big "let's study it."

Ken

-----Original Message-----
From: Lowell Lindstrom [mailto:lindstrom@...]
Sent: Wednesday, May 15, 2002 4:56 PM
To: 'scrumdevelopment@yahoogroups.com'
Subject: [scrumdevelopment] RE: Re: [XP] Scrum and XP


>    From: "Mike Beedle" <beedlem@...>
> Subject: RE: Re: [XP] Scrum and XP
>
> However, let me focus on your question:  "Is Scrum going to
> end up just being part of XP?"
>
> Here is my take:  not a chance.

I agree with Mike.  I don't see this happening, nor do I think anyone needs
it to happen.

> If anything, XP might eventually adopt a "full Scrum" approach,
> and eventually get closer to a full gene mix of XP and Scrum.

Mike, here I do not understand.  Your response comes across to me as if you
feel threatened, as if XP and Scrum are in some kinda of competition with
each other.  Perhaps I am misreading.

You and Ken have had good experiences using practices from both XP and
Scrum.  I already see XP Teams naturally evolving to practices that greatly
resemble parts of Scrum (Scrum or scrums, more formal management of stories,
etc.).  They don't call it Scrum because they have never heard of Scrum.  I
don't see why we care whether XP becomes Scrum, Scrum becomes XP, or
everything is communicated under the umbrella of Agile Best Practices.  To
debate that seems to miss the point, which we all seem to agree is to find
better ways to deliver business value through software development.

Lowell

====================
Lowell Lindstrom
Object Mentor, Inc | www.objectmentor.com | 1-800-338-6716
lindstrom@...



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/

Lowell Lindstrom wrote:
> > We use a different names for 2 main reasons:
> >
> >  1) out of respect for what XP and Scrum are,
> >  because we don't like to say that we do is
> >  XP or Scrum and then have someone pointing out
> >  that XP or Scrum don't do things like we do.
> >
>
> I can definitely see wanting to avoid the "are you doing
> XP(Scrum)? debate." But you are doing XP and Scrum,
> plus MORE.  What's interesting is the "more"
> part, that variance, not the XP and Scrum.  That is
> where the attention should be.  Naming the superset
> distracts from that.

Lowell:

I disagree.  I feel it clarifies the purpose.

The problem also is that is not only +more as you point
out above, but in many cases is:

	  +more +modifying or specializing something in
	 Scrum or XP.  For example, there are highly specialized
	 Scrum of Scrums in an XBreed environment, we don't
	 only care about Product Backlog, but about many
	 Backlogs with dependencies.  So even when the
	 spirit of Scrum survives, the meeting is structured
	 around different buckets.

Lowell Lindstrom wrote:
> >  2) and because we like to remember,
> >  "special combinations" that lead to a desired
> >  specialized result.  In the case of XP@Scrum
> >  is business value, and in the case of XBreed
> >  is reusability.  So we abstract these special
> >  combinations with a name rather than tell people:
> >
>
> Thanks!   I understand a little better.  Somehow I missed
> that each had a different emphasis.  I was under the
> impression that they were both simply different
> combinations of XP and Scrum.

Unfortunately, Ken and I, and the people that we associate with
are typically on the trenches, so we have had little time
to explain things better.

Lowell Lindstrom wrote:
> The name proliferation seems not agile to me.  It introduces unnecessary
> complexity.  Surely XBreed projects want business value and XP@Scrum
> projects want reuse.  A better approach is to emphasize only what
> is unique, rather than the rename the whole set.  What are
> the set of practices that when added to what we know as
> Scrum and XP lead to higher reuse?  That is a set of practices that
> warrants a new label, not the superset.  Same with XP@Scrum.  What
> are the practices that when added to what we know as Scrum
> and XP deliver higher business value?  Call that XP@Scrum (or BVD).
> If it is just XP, with Scrum replacing the planning game, just
> call it "XP with Scrum as the Planning Game" or "Scrum using
> XP Practices for the software development."

Unfortunately, there are many modifications so it can't be
expressed by something as simple as:

	 "XP with Scrum as the Planning Game"

That is a starting point, and in fact, that's more or less
how XBreed started, but once the focus changed, the sentence
became a paragraph, the paragraph became a chapter, and
pretty soon you have something new.

I suspect the same thing is going on with xp@Scrum.

Lowell Lindstrom wrote:
> > In terms of names consider this: Monkeys and Humans have
> > a x > 99% overlap in their chromosome and gene sequences,
> > yet, this difference yields to very different animals.
> > However, as much as we are alike I don't think there
> > is any human that likes to be called a monkey
>
> Nicely phrased! Yes, I am aware that egos are involve here ;-).
> I just hope they can be kept in check enough not to
> kill the movement.  A proliferation of differently names
> sets of methods that are basically identical has that
> risk associated with it.

Well, I didn't mean to say anything related to egos.

My point was that simple changes in the meta-architecture of
a system (genotype) can yield to big changes in the overall
structure of the instances (phenotype), and that they
may deserve a different abstraction - a different word.

Actually, we did discuss "name proliferation" at our initial
meeting at Snowbird, and we encouraged each other to explore
and try new things without trying to "unify" things ;-)

Diversity makes us stronger,

- Mike


http://www.hipaaccelerator.com
We are hiring Java Developers, architects and project managers.
http://www.e-architects.com

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

http://www.agilealliance.org

http://www.mikebeedle.com

I wonder if some of this can be addressed using ideas similar to what Alistair
used in 'Agile Software Development" and his Crystal Methodologies...

It seems to me that Mike has perhaps found a new "niche" or "family" of
methodologies that mix XP and SCRUM together in project-specific ways based on
some project-specific parameters for certain tradeoff conditions (optimizing for
reuse versus for ???).

I wonder where on the spectrum of Crystal methods the particular set of
conditions are that lead to this 'family of methods' that has the intersection
of SCRUM+XP as its basis? I think it is probably not a problem to have a
separate name to identify this "space" rooted at the intersection, and having a
name for specific instantiation that is optimized for certain conditions seems
fine too so long as it isn't claiming to be a brand new methodology (rather, its
a  named variation or 'flavor' in this particular 'family' or 'subfamily' within
the agile methodology space).

We still need names for all these things, they just don't all have to be in the
same namespace at the same level of abstraction/granularity :)

On Wed, May 15, 2002 at 05:19:59PM -0500, Mike Beedle wrote:
>
> Lowell Lindstrom wrote:
> > > We use a different names for 2 main reasons:
> > >
> > >  1) out of respect for what XP and Scrum are,
> > >  because we don't like to say that we do is
> > >  XP or Scrum and then have someone pointing out
> > >  that XP or Scrum don't do things like we do.
> > >
> >
> > I can definitely see wanting to avoid the "are you doing
> > XP(Scrum)? debate." But you are doing XP and Scrum,
> > plus MORE.  What's interesting is the "more"
> > part, that variance, not the XP and Scrum.  That is
> > where the attention should be.  Naming the superset
> > distracts from that.
>
> Lowell:
>
> I disagree.  I feel it clarifies the purpose.
>
> The problem also is that is not only +more as you point
> out above, but in many cases is:
>
> 	 +more +modifying or specializing something in
>  Scrum or XP.  For example, there are highly specialized
>  Scrum of Scrums in an XBreed environment, we don't
>  only care about Product Backlog, but about many
>  Backlogs with dependencies.  So even when the
>  spirit of Scrum survives, the meeting is structured
>  around different buckets.
>
> Lowell Lindstrom wrote:
> > >  2) and because we like to remember,
> > >  "special combinations" that lead to a desired
> > >  specialized result.  In the case of XP@Scrum
> > >  is business value, and in the case of XBreed
> > >  is reusability.  So we abstract these special
> > >  combinations with a name rather than tell people:
> > >
> >
> > Thanks!   I understand a little better.  Somehow I missed
> > that each had a different emphasis.  I was under the
> > impression that they were both simply different
> > combinations of XP and Scrum.
>
> Unfortunately, Ken and I, and the people that we associate with
> are typically on the trenches, so we have had little time
> to explain things better.
>
> Lowell Lindstrom wrote:
> > The name proliferation seems not agile to me.  It introduces unnecessary
> > complexity.  Surely XBreed projects want business value and XP@Scrum
> > projects want reuse.  A better approach is to emphasize only what
> > is unique, rather than the rename the whole set.  What are
> > the set of practices that when added to what we know as
> > Scrum and XP lead to higher reuse?  That is a set of practices that
> > warrants a new label, not the superset.  Same with XP@Scrum.  What
> > are the practices that when added to what we know as Scrum
> > and XP deliver higher business value?  Call that XP@Scrum (or BVD).
> > If it is just XP, with Scrum replacing the planning game, just
> > call it "XP with Scrum as the Planning Game" or "Scrum using
> > XP Practices for the software development."
>
> Unfortunately, there are many modifications so it can't be
> expressed by something as simple as:
>
>  "XP with Scrum as the Planning Game"
>
> That is a starting point, and in fact, that's more or less
> how XBreed started, but once the focus changed, the sentence
> became a paragraph, the paragraph became a chapter, and
> pretty soon you have something new.
>
> I suspect the same thing is going on with xp@Scrum.
>
> Lowell Lindstrom wrote:
> > > In terms of names consider this: Monkeys and Humans have
> > > a x > 99% overlap in their chromosome and gene sequences,
> > > yet, this difference yields to very different animals.
> > > However, as much as we are alike I don't think there
> > > is any human that likes to be called a monkey
> >
> > Nicely phrased! Yes, I am aware that egos are involve here ;-).
> > I just hope they can be kept in check enough not to
> > kill the movement.  A proliferation of differently names
> > sets of methods that are basically identical has that
> > risk associated with it.
>
> Well, I didn't mean to say anything related to egos.
>
> My point was that simple changes in the meta-architecture of
> a system (genotype) can yield to big changes in the overall
> structure of the instances (phenotype), and that they
> may deserve a different abstraction - a different word.
>
> Actually, we did discuss "name proliferation" at our initial
> meeting at Snowbird, and we encouraged each other to explore
> and try new things without trying to "unify" things ;-)
>
> Diversity makes us stronger,
>
> - Mike
>
>
> http://www.hipaaccelerator.com
> We are hiring Java Developers, architects and project managers.
> http://www.e-architects.com
>
> http://www.xbreed.net
> http://www.agilescrum.com
> http://www.livingmetaphor.org
>
> http://www.agilealliance.org
>
> http://www.mikebeedle.com
>
>
> To unsubscribe from this group, send an email to:
> chicago-agile-dev-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>

--
Brad Appleton <brad@...>  http://www.bradapp.net/
  "Education is the ability to listen to almost anything
   without losing your temper or your self-confidence."
    -- Robert Frost

Brad Appleton wrote:
> I wonder if some of this can be addressed using
> ideas similar to what Alistair used in
> 'Agile Software Development" and his Crystal
> Methodologies...
>
> It seems to me that Mike has perhaps found a new
> "niche" or "family" of methodologies that mix
> XP and SCRUM together in project-specific ways
> based on some project-specific parameters
> for certain tradeoff conditions (optimizing for
> reuse versus for ???).
> I wonder where on the spectrum of Crystal methods
> the particular set of conditions are that lead to
> this 'family of methods' that has the intersection
> of SCRUM+XP as its basis? I think it is probably not
> a problem to have a separate name to identify this
> "space" rooted at the intersection, and having
> a name for specific instantiation that is optimized
> for certain conditions seems fine too so long as
> it isn't claiming to be a brand new methodology
> (rather, its a  named variation or 'flavor' in
> this particular 'family' or 'subfamily' within
> the agile methodology space).
>
> We still need names for all these things, they
> just don't all have to be in the same namespace
> at the same level of abstraction/granularity :)

Brad:

These are interesting thoughts indeed.

Much to be worked by present and future agileers,

- Mike

Last year I was managing a project before the Scrum book was
published.  I understood from the web sites the concept of a sprint
and Scrum meetings, but not the idea of backlog.  We went live on
our project with about half of the work unfinished, and provided
weekly production updates to complete the project.

As soon as the project went live, I developed a `punch list'.
  This
was learned in my days of installing process control systems.  As
soon as you bring up a process, you create a punch list of areas
that need to be finished.  Happens in construction too.  The punch
list was prioritized by the customer every week; items were added
and subtracted, fleshed out and changed.  It drove everything we did
for the duration of the project, and each week the development team
choose the items off the top of the list they felt they could
complete in the next week.

I was not using the correct word – backlog – but the idea of
a
backlog (or punch list) is universal.  In the Scrum book, the point
is made that in the end, almost all projects are run using a method
like Scrum.  I agree.  I particularly like the concept and use of
backlog, and especially the velocity charts that result from
estimating the remaining work to be done from the backlog every
sprint.  This is a well-understood and quite universal way to run
all kinds of projects, *especially after an initial phase has been
completed*.  I suspect this is a key reason Scrum is easy to sell to
senior managers.

One concept that has gotten me thinking is – if the backlog is so
powerful as well as universal, and if it is usually used (as a punch
list) to manage projects after some initial implementation – then
perhaps this tells us something about the fundamentally iterative
nature of software development.

Another concept, sort of a corollary, is:  In lean manufacturing,
the fastest way to help a manufacturing organization `get it'
is to
implement a pull system based on just-in-time inventory flow.  In
agile development, the fastest way to help an organization `get
it'
is to start implementing in real, tested, workable, useful
iterations.  So it makes sense to focus on, as Ken says, `the art
of
the possible.'  What real thing can we *complete* in one month?
Getting a team (and organization) to start delivering real, workable
iterations is the fastest way to help the organization `get
it'.

Hi all,
I've just read Jim Highsmith's article in the Software Development magazine.
It is really great and talks quite much about Scrum (a case study from IDX
among others).

Does Agility Work?
by Jim Highsmith
http://www.sdmagazine.com/documents/s=7147/sdm0206a/sdm0206a.htm


Jonas

Papers accepted at XP2002 Conference are now online at:

www.xp2002.org

There is still room to register to the conference!

See you in Alghero next week

Michele Marchesi
XP2002 Program Chair

-----Original Message-----
From: Jonas Bengtsson [mailto:jonas.b@...]
Sent: Thursday, May 16, 2002 8:34 AM
To: Scrum
Subject: [scrumdevelopment] Article: Does Agility Work?

Hi all,
I've just read Jim Highsmith's article in the Software Development magazine.
It is really great and talks quite much about Scrum (a case study from IDX
among others).

Does Agility Work?
by Jim Highsmith
http://www.sdmagazine.com/documents/s=7147/sdm0206a/sdm0206a.htm


Jonas



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.

Good ideas tend to evolve simultaneously in multiple places.  It
makes me think of the evolution of the eyball.  The eyeball of the
Octopus is nearly identical in function and structure to the
mammalian eyeball, yet biologists can prove that they evolved from
completely distinct sources.

-arc

--- In scrumdevelopment@y..., "mpoppendieck" <mary@p...> wrote:
> Last year I was managing a project before the Scrum book was
> published.  I understood from the web sites the concept of a sprint
> and Scrum meetings, but not the idea of backlog.  We went live on
> our project with about half of the work unfinished, and provided
> weekly production updates to complete the project.
>
> As soon as the project went live, I developed a `punch list'.
>  This
> was learned in my days of installing process control systems.  As
> soon as you bring up a process, you create a punch list of areas
> that need to be finished.  Happens in construction too.  The punch
> list was prioritized by the customer every week; items were added
> and subtracted, fleshed out and changed.  It drove everything we
did
> for the duration of the project, and each week the development team
> choose the items off the top of the list they felt they could
> complete in the next week.
>
> I was not using the correct word – backlog – but the idea of
> a
> backlog (or punch list) is universal.  In the Scrum book, the point
> is made that in the end, almost all projects are run using a method
> like Scrum.  I agree.  I particularly like the concept and use of
> backlog, and especially the velocity charts that result from
> estimating the remaining work to be done from the backlog every
> sprint.  This is a well-understood and quite universal way to run
> all kinds of projects, *especially after an initial phase has been
> completed*.  I suspect this is a key reason Scrum is easy to sell
to
> senior managers.
>
> One concept that has gotten me thinking is – if the backlog is
so
> powerful as well as universal, and if it is usually used (as a
punch
> list) to manage projects after some initial implementation –
then
> perhaps this tells us something about the fundamentally iterative
> nature of software development.
>
> Another concept, sort of a corollary, is:  In lean manufacturing,
> the fastest way to help a manufacturing organization `get it'
> is to
> implement a pull system based on just-in-time inventory flow.  In
> agile development, the fastest way to help an organization `get
> it'
> is to start implementing in real, tested, workable, useful
> iterations.  So it makes sense to focus on, as Ken says, `the art
> of
> the possible.'  What real thing can we *complete* in one month?
> Getting a team (and organization) to start delivering real,
workable
> iterations is the fastest way to help the organization `get
> it'.

Mary wrote:
[snip]
> In the Scrum book, the point is made that in the end,
> almost all projects are run using a method like Scrum.
> I agree.
[snip]
> This is a well-understood and quite universal way to run
> all kinds of projects, *especially after an initial phase has been
> completed*.  I suspect this is a key reason Scrum is easy to sell to
> senior managers.

Andy wrote:
> Good ideas tend to evolve simultaneously in multiple places.  It
> makes me think of the evolution of the eyball.  The eyeball of the
> Octopus is nearly identical in function and structure to the
> mammalian eyeball, yet biologists can prove that they evolved from
> completely distinct sources.
>
>-arc

Mary, Andy:

Just like the design of the eyeball that Andy cites above
the Scrum-like practices abound and emerge independently
in different fields and are indeed universal patterns -- the
winning specimen in each field that results after many iterations
of competing alternatives that resemble a genetic algorithm.

And these Scrum-like patterns pop up in all sort of places --
even at very high levels of the organization.  If you look at
what has happened to Strategic Planning and Management in
the last 30 years is relevant to Scrum because the rise and
fall of long-term strategic management and planning techniques
resembles the rise and fall of the waterfall methods and the
fallacy of having a "phasist defined and repeatable step-wise
processes" in software development.

In contrast, like modern-day manufacturing, Strategic Management
and Planning, more and more relies on adaptive time-boxed-oriented
techniques that curiously resemble Scrum-like techniques.

I think this similarity will be a critical factor to sell
Scrum to organizations at the highest level of the organization.

Scrum also ties very well with the concept of "strategic scenarios"
because it proposes and evaluates alternate implementation of
the Backlog.

And Scrum also ties very well with Lifestreams, a concept that
David Gelertner has been pushing for the last few years because
Scrum is essentially the management of the Lifestream.

In the end, Scrum-like techniques are always the generators of
the organization of work i.e. of self-organization.  Interestingly,
Stuart Kauffman argues that this is the central and key element
for what is now known as "artificial life".  So one could argue --
strongly, that Scrum-like organizations, in any form, are more "alive".
(It feels that way too :-)

But this is only the beginning.  Once you have the basic elements
of organizing work, many other goals are achievable:

	 - introspection and retrospection of actions by
	 analyzing old backlog
	 - discovery of patterns from experience (past backlog)
	 and therefore the creation and storage of knowledge
	 - evaluation of alternative plans and strategies by
	 evaluating alternate sequences of future backlog
	 (which is the key realize an organizational "game theory")
	 - tracking, evaluation and generation of intentions
	 - sensing and effecting of events that get analyzed to
	 generate:

		 intentions, plans, strategies, actions/work and
		 external communications

	 - homeostatic behavior, determination of equilibrium conditions
	 and rules that work with negative feedback to
	 restore equilibrium
	 - protometabolic behavior, in the processing of requirements,
	 knowledge and interactions with other groups
	 etc.

Goals like the above will be the origin of the future organizational
patterns, yet undiscovered and unapplied, that will make organizations
more closely resemble living organisms, or perhaps intelligent
distributed agent architectures,

- Mike
http://www.livingmetaphor.org

andycirillo wrote:

> Good ideas tend to evolve simultaneously in multiple places.  It
> makes me think of the evolution of the eyball.  The eyeball of the
> Octopus is nearly identical in function and structure to the
> mammalian eyeball, yet biologists can prove that they evolved from
> completely distinct sources.

Interesting note: This week's Science (p1010) notes work reported at a recent
Cold Spring Harbor meeting that suggests eyes had a common origin and that the
ancestor could have been a microbe that later became the chloroplast.  Evidence
comes from the pax-6 developmental gene present in 20 species.

--
Ward Cunningham
v 503-245-5633   mailto:ward@...
f 503-246-5587   http://c2.com/

Ward wrote:
>andycirillo wrote:
> > Good ideas tend to evolve simultaneously in multiple places.
> > It makes me think of the evolution of the eyball.  The eyeball
> > of the Octopus is nearly identical in function and structure to the
> > mammalian eyeball, yet biologists can prove that they evolved from
> > completely distinct sources.
>
> Interesting note: This week's Science (p1010) notes
> work reported at a recent Cold Spring Harbor meeting
> that suggests eyes had a common origin and that the
> ancestor could have been a microbe that later
> became the chloroplast.  Evidence comes from the
> pax-6 developmental gene present in 20 species.

Ward:

It is also interesting that parallel research in biology is
showing that high concentrations of _new_ types of
bacteria and chemicals are the origin of cancer in
most living organisms.

The same research argues that a living organism, like a mammal,
is a giant hotel for bacteria, but that as long as the
bacteria present are in a stable coevolutionary path,
they represent no harm to the "individual".  In fact, some
bacteria have been "living with us and our ancestors"
for millions of years.  And the immune system even ignores
many kind of bacteria because it somehow knows that they
are, so to speak, part of the working system.

So in the case of the origin of the eye above, a nice
coevolutionary path existed, probably for a long time,
that eventually led to the encoding of a gene in the
host organisms,

- Mike
http://www.livingmetaphor.org

Hi all,

I just felt that I had to share this amazing article with you:
http://www.fastcompany.com/online/28/ge.html

It is about General Electric plant in Durham that builds jet engines.

Jonas

Jonas:

Thanks for the reference.

There are so many things to comment on but these things
really got my attention:

1) Time-boxed goals
The jet engines are produced by nine teams of people -- teams that are given
just one basic directive: the day that their next engine must be loaded onto
a truck. All other decisions -- who does what work; how to balance training,
vacations, overtime against work flow; how to make the manufacturing process
more efficient; how to handle teammates who slack off -- all of that stays
within the team.


2) Culture and Values
"Teams," "teamwork," "teaming" -- these are such overused words, such
overworked concepts, that they have been all but drained of meaning.
GE/Durham isn't so much a team environment as it is a tribal community.
There are rules, rituals, and folklore; there is tribal loyalty and tribal
accountability. There is a connection to a wider world, beyond the tribe.

What happens if someone is not performing? If you've got an issue -- a
problem with someone's work ethic, for instance -- you've got to bring it
up.

The plant has not missed a delivery date on the CF6 engine in 38 straight
months. Or, to put it another way, GE/Durham has consecutively delivered
more than 500 CF6 engines on schedule.


3) Daily Meetings to Discuss Progress and Issues
Some of these routines are big things. Everyone at the plant belongs to a
team, and every team meets every day at 2:30 pm. The team meeting is the
pivot of GE/Durham. There are two shifts, and they overlap to allow everyone
either to start or to end the day at the team meeting. More than a simple
update of the day's progress and problems, this meeting is a place to
hip-check morale, conflict, overtime, hiring, technical snags, and planning
for the future.


4) High skills for all workers
You have to be above the bar in all 11 of the areas: helping skills, team
skills, communication skills, diversity, flexibility, coaching ability, work
ethic, and so forth. Even if just one thing out of the 11 knocks you down,
you don't come to work here.


5) Flat Organizations
GE/Durham has more than 170 employees but just one boss: the plant manager.
Everyone in the place reports to her. Which means that on a day-to-day
basis, the people who work here have no boss. They essentially run
themselves


6) Self-organization through Rapid Feedback
GE/Durham's continuous-feedback culture -- "We call this the feedback
capital of the world," says Paula Sims -- means that while in one sense it's
true that no one here has a boss, the opposite is also true: "I have 15
bosses," says Keith McKee. "All of my teammates are my bosses." No one is
exempt.

The jet engines are produced by nine teams of people -- teams that are given
just one basic directive: the day that their next engine must be loaded onto
a truck. All other decisions -- who does what work; how to balance training,
vacations, overtime against work flow; how to make the manufacturing process
more efficient; how to handle teammates who slack off -- all of that stays
within the team.

(There are too many good quotes I could put in here.)


7) Knowledge transfer
Multiskilling is how the place is kept together," says Derrick McCoy, 32, a
tech-3 and a buddy of Duane Williams's on Team Raven. "You don't hoard your
skills. That way, when I'm on vacation, the low-pressure turbine can still
be built without me.


8) Knowledge creation
The most interesting measure may be one that the people at GE/Durham talk
about themselves. They don't really think that their main job is to make jet
engines. They think that their main job is to make jet engines better.

Now, for instance, when the GE90 is in final assembly, the huge engine sits
in a scaffold that consists of two-story-high yellow metal platforms. The
platforms form a kind of pier, giving easy access to the flanks and top of
an engine that is as big around as a passenger liner. "They used to go up on
ladders to work on those engines," says Sims. "The GE90 teams said, 'Could
we build some platforms?' I said, 'That's a great idea.' Once we decided on
a design, it took a month to build the first one, and now we have two. Not
having to climb up and down the ladder, or to move it each time you need to
reach something new, has reduced the assembly time of the engine by eight
hours."


9) Team Shared Ownership, Responsibilities
One team "owns" an engine from beginning to end -- from the point when parts
are uncrated and staged to the moment a team member climbs on a forklift to
place the finished engine on a truck for shipment.


10) Value of the individual
"I think what they've discovered in Durham is the value of the human being,"
says McEwan. He points to the ceiling.


Hmm, where did I hear this before :-) ?

Each and every points reminds me of Scrum -- specially in the
form described that Nonaka and Takeuchi described it in the
"New New Product Development Game".

Thanks again for the reference,

- Mike



-----Original Message-----
From: Jonas Bengtsson [mailto:jonas.b@...]
Sent: Wednesday, May 22, 2002 4:35 AM
To: Scrum
Subject: [scrumdevelopment] Engines of democracy


Hi all,

I just felt that I had to share this amazing article with you:
http://www.fastcompany.com/online/28/ge.html

It is about General Electric plant in Durham that builds jet engines.

Jonas