-----Original Message-----
From: peter@... [mailto:peter@...]
Sent: Monday, September 30, 2002 5:04 PM
To: scrum@...
Subject: RE: [scrumdevelopment] Alternative to EGroups

* Scrum Mailing List - Header *

scrum@... is active (scrumdevelopment@yahoogroups.com is a member).

 

Send a message to it with “subscribe” in the header and you’re done.  Same goes for unsubscribe.

 

 

-----Original Message-----
From: Mike Cohn [mailto:mike@...]
Sent: Friday, September 27, 2002 3:27 PM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

 

Oops—I’d assumed that on the new system we would still get emails.

 

I’d be opposed to anything where I have to go to a website as I know I won’t go there very frequently. The “push” approach of email works much better, IMO.

 

-----Original Message-----
From: Jonas Bengtsson [mailto:jonas.b@...]
Sent: Friday, September 27, 2002 11:18 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

 

I am using e-mail to read and post messages to this group (I guess that's
the case for most members). Using a web based approach would be quite a
change.

Have you considered starting a new mailing list? (This might be something
for AgileAlliance to host?)

But change might be good. Perhaps moving this group to a web based system
would give it an energy boost.

/Jonas

> -----Original Message-----
> From: Ken Schwaber [mailto:kschwaber@...]
> Sent: Friday, September 27, 2002 6:33 PM
> To: scrumdevelopment@yahoogroups.com
> Subject: [scrumdevelopment] Alternative to EGroups
>
>
> I met Francois Beauregard from Pyxis Technologies at the initial
> meeting of the Montreal Agile User Group. He offerred to host our
> egroup on his company's server. Since I'm getting a little tired on
> Yahoo's commercialization of egroups, I thought that I would put it
> up to a vote. Does anyone mind if I shift us over to this egroup
> host?
>
>
> http://www.pyxis-tech.com/agilemontreal/yabb/YaBB.cgi
>
> Ken Schwaber
> 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.

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: Peter McGowan [mailto:pmcgowan@...]
Sent: Tuesday, October 01, 2002 12:13 PM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

Hi Ken,

 

The Mailing List software on controlchaos.com only supports subscribe/unsubscribe.  It doesn’t have a Web Interface or Digest functionality like you would get with Yahoo!Groups.

 

Peter

 

 

-----Original Message-----
From: Ken Schwaber [mailto:ken.schwaber@...]
Sent: Tuesday, October 01, 2002 11:46 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

 

Peter,

How do I get on and review old message, membership ... the type of browsing and administrative stuff that egroups has? Is that available at scrum@...? How do new people sign up?

Ken

-----Original Message-----
From: peter@... [mailto:peter@...]
Sent: Monday, September 30, 2002 5:04 PM
To: scrum@...
Subject: RE: [scrumdevelopment] Alternative to EGroups

* Scrum Mailing List - Header *

scrum@... is active (scrumdevelopment@yahoogroups.com is a member).

 

Send a message to it with “subscribe” in the header and you’re done.  Same goes for unsubscribe.

 

 

-----Original Message-----
From: Mike Cohn [mailto:mike@...]
Sent: Friday, September 27, 2002 3:27 PM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

 

Oops—I’d assumed that on the new system we would still get emails.

 

I’d be opposed to anything where I have to go to a website as I know I won’t go there very frequently. The “push” approach of email works much better, IMO.

 

-----Original Message-----
From: Jonas Bengtsson [mailto:jonas.b@...]
Sent: Friday, September 27, 2002 11:18 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

 

I am using e-mail to read and post messages to this group (I guess that's
the case for most members). Using a web based approach would be quite a
change.

Have you considered starting a new mailing list? (This might be something
for AgileAlliance to host?)

But change might be good. Perhaps moving this group to a web based system
would give it an energy boost.

/Jonas

> -----Original Message-----
> From: Ken Schwaber [mailto:kschwaber@...]
> Sent: Friday, September 27, 2002 6:33 PM
> To: scrumdevelopment@yahoogroups.com
> Subject: [scrumdevelopment] Alternative to EGroups
>
>
> I met Francois Beauregard from Pyxis Technologies at the initial
> meeting of the Montreal Agile User Group. He offerred to host our
> egroup on his company's server. Since I'm getting a little tired on
> Yahoo's commercialization of egroups, I thought that I would put it
> up to a vote. Does anyone mind if I shift us over to this egroup
> host?
>
>
> http://www.pyxis-tech.com/agilemontreal/yabb/YaBB.cgi
>
> Ken Schwaber
> 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.

 

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.

http://bejerae.s5.com/index.html

-----Original Message-----
From: Ken Schwaber [mailto:ken.schwaber@...]
Sent: Tuesday, October 01, 2002 7:05 PM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

Is ther anything for free that has equivalent functionality?

-----Original Message-----
From: Peter McGowan [mailto:pmcgowan@...]
Sent: Tuesday, October 01, 2002 12:13 PM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

Hi Ken,

 

The Mailing List software on controlchaos.com only supports subscribe/unsubscribe.  It doesn’t have a Web Interface or Digest functionality like you would get with Yahoo!Groups.

 

Peter

 

 

-----Original Message-----
From: Ken Schwaber [mailto:ken.schwaber@...]
Sent: Tuesday, October 01, 2002 11:46 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

 

Peter,

How do I get on and review old message, membership ... the type of browsing and administrative stuff that egroups has? Is that available at scrum@...? How do new people sign up?

Ken

-----Original Message-----
From: peter@... [mailto:peter@...]
Sent: Monday, September 30, 2002 5:04 PM
To: scrum@...
Subject: RE: [scrumdevelopment] Alternative to EGroups

* Scrum Mailing List - Header *

scrum@... is active (scrumdevelopment@yahoogroups.com is a member).

 

Send a message to it with “subscribe” in the header and you’re done.  Same goes for unsubscribe.

 

 

-----Original Message-----
From: Mike Cohn [mailto:mike@...]
Sent: Friday, September 27, 2002 3:27 PM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

 

Oops—I’d assumed that on the new system we would still get emails.

 

I’d be opposed to anything where I have to go to a website as I know I won’t go there very frequently. The “push” approach of email works much better, IMO.

 

-----Original Message-----
From: Jonas Bengtsson [mailto:jonas.b@...]
Sent: Friday, September 27, 2002 11:18 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

 

I am using e-mail to read and post messages to this group (I guess that's
the case for most members). Using a web based approach would be quite a
change.

Have you considered starting a new mailing list? (This might be something
for AgileAlliance to host?)

But change might be good. Perhaps moving this group to a web based system
would give it an energy boost.

/Jonas

> -----Original Message-----
> From: Ken Schwaber [mailto:kschwaber@...]
> Sent: Friday, September 27, 2002 6:33 PM
> To: scrumdevelopment@yahoogroups.com
> Subject: [scrumdevelopment] Alternative to EGroups
>
>
> I met Francois Beauregard from Pyxis Technologies at the initial
> meeting of the Montreal Agile User Group. He offerred to host our
> egroup on his company's server. Since I'm getting a little tired on
> Yahoo's commercialization of egroups, I thought that I would put it
> up to a vote. Does anyone mind if I shift us over to this egroup
> host?
>
>
> http://www.pyxis-tech.com/agilemontreal/yabb/YaBB.cgi
>
> Ken Schwaber
> 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.

 

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.

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: Tuesday, October 01, 2002 9:27 PM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

The one Mary sent out looked awfully close but it did still seem to have ads—so probably not worth a change.

 

-----Original Message-----
From: Ken Schwaber [mailto:ken.schwaber@...]
Sent: Tuesday, October 01, 2002 6:05 PM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

 

Is ther anything for free that has equivalent functionality?

-----Original Message-----
From: Peter McGowan [mailto:pmcgowan@...]
Sent: Tuesday, October 01, 2002 12:13 PM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

Hi Ken,

 

The Mailing List software on controlchaos.com only supports subscribe/unsubscribe.  It doesn’t have a Web Interface or Digest functionality like you would get with Yahoo!Groups.

 

Peter

 

 

-----Original Message-----
From: Ken Schwaber [mailto:ken.schwaber@...]
Sent: Tuesday, October 01, 2002 11:46 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

 

Peter,

How do I get on and review old message, membership ... the type of browsing and administrative stuff that egroups has? Is that available at scrum@...? How do new people sign up?

Ken

-----Original Message-----
From: peter@... [mailto:peter@...]
Sent: Monday, September 30, 2002 5:04 PM
To: scrum@...
Subject: RE: [scrumdevelopment] Alternative to EGroups

* Scrum Mailing List - Header *

scrum@... is active (scrumdevelopment@yahoogroups.com is a member).

 

Send a message to it with “subscribe” in the header and you’re done.  Same goes for unsubscribe.

 

 

-----Original Message-----
From: Mike Cohn [mailto:mike@...]
Sent: Friday, September 27, 2002 3:27 PM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

 

Oops—I’d assumed that on the new system we would still get emails.

 

I’d be opposed to anything where I have to go to a website as I know I won’t go there very frequently. The “push” approach of email works much better, IMO.

 

-----Original Message-----
From: Jonas Bengtsson [mailto:jonas.b@...]
Sent: Friday, September 27, 2002 11:18 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

 

I am using e-mail to read and post messages to this group (I guess that's
the case for most members). Using a web based approach would be quite a
change.

Have you considered starting a new mailing list? (This might be something
for AgileAlliance to host?)

But change might be good. Perhaps moving this group to a web based system
would give it an energy boost.

/Jonas

> -----Original Message-----
> From: Ken Schwaber [mailto:kschwaber@...]
> Sent: Friday, September 27, 2002 6:33 PM
> To: scrumdevelopment@yahoogroups.com
> Subject: [scrumdevelopment] Alternative to EGroups
>
>
> I met Francois Beauregard from Pyxis Technologies at the initial
> meeting of the Montreal Agile User Group. He offerred to host our
> egroup on his company's server. Since I'm getting a little tired on
> Yahoo's commercialization of egroups, I thought that I would put it
> up to a vote. Does anyone mind if I shift us over to this egroup
> host?
>
>
> http://www.pyxis-tech.com/agilemontreal/yabb/YaBB.cgi
>
> Ken Schwaber
> 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.

 

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.

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.

The one Mary sent out looked awfully close but it did still seem to have ads—so probably not worth a change.

 

-----Original Message-----
From: Ken Schwaber [mailto:ken.schwaber@...]
Sent: Tuesday, October 01, 2002 6:05 PM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

 

Is ther anything for free that has equivalent functionality?

-----Original Message-----
From: Peter McGowan [mailto:pmcgowan@...]
Sent: Tuesday, October 01, 2002 12:13 PM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

Hi Ken,

 

The Mailing List software on controlchaos.com only supports subscribe/unsubscribe.  It doesn’t have a Web Interface or Digest functionality like you would get with Yahoo!Groups.

 

Peter

 

 

-----Original Message-----
From: Ken Schwaber [mailto:ken.schwaber@...]
Sent: Tuesday, October 01, 2002 11:46 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

 

Peter,

How do I get on and review old message, membership ... the type of browsing and administrative stuff that egroups has? Is that available at scrum@...? How do new people sign up?

Ken

-----Original Message-----
From: peter@... [mailto:peter@...]
Sent: Monday, September 30, 2002 5:04 PM
To: scrum@...
Subject: RE: [scrumdevelopment] Alternative to EGroups

* Scrum Mailing List - Header *

scrum@... is active (scrumdevelopment@yahoogroups.com is a member).

 

Send a message to it with “subscribe” in the header and you’re done.  Same goes for unsubscribe.

 

 

-----Original Message-----
From: Mike Cohn [mailto:mike@...]
Sent: Friday, September 27, 2002 3:27 PM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

 

Oops—I’d assumed that on the new system we would still get emails.

 

I’d be opposed to anything where I have to go to a website as I know I won’t go there very frequently. The “push” approach of email works much better, IMO.

 

-----Original Message-----
From: Jonas Bengtsson [mailto:jonas.b@...]
Sent: Friday, September 27, 2002 11:18 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Alternative to EGroups

 

I am using e-mail to read and post messages to this group (I guess that's
the case for most members). Using a web based approach would be quite a
change.

Have you considered starting a new mailing list? (This might be something
for AgileAlliance to host?)

But change might be good. Perhaps moving this group to a web based system
would give it an energy boost.

/Jonas

> -----Original Message-----
> From: Ken Schwaber [mailto:kschwaber@...]
> Sent: Friday, September 27, 2002 6:33 PM
> To: scrumdevelopment@yahoogroups.com
> Subject: [scrumdevelopment] Alternative to EGroups
>
>
> I met Francois Beauregard from Pyxis Technologies at the initial
> meeting of the Montreal Agile User Group. He offerred to host our
> egroup on his company's server. Since I'm getting a little tired on
> Yahoo's commercialization of egroups, I thought that I would put it
> up to a vote. Does anyone mind if I shift us over to this egroup
> host?
>
>
> http://www.pyxis-tech.com/agilemontreal/yabb/YaBB.cgi
>
> Ken Schwaber
> 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.

 

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.

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.

I've found a couple of good sites on project management.  One is a
site by Hal Macomber at http://weblog.halmacomber.com/ .  Hal is
active in the Lean Construction Institute, and by the way,
references this group on his site.

The second site is the NASA magazine for on project leadership -
really!  See http://www.appl.nasa.gov/knowledge/ask_home.htm .  This
magazine has a lot of gems from very senior project managers on what
makes or breaks a project - and guess what - it turns out it is
always the people working with each other....

Mary Poppendieck
www.leanprogramming.com

I am a member of a dozen or so Yahoo discussion groups, and I always
choose to get a digest instead of e-mails, and then I use the web
interface if the digest is interesting. One thing Yahoo can do that
Topica can't is allow file posting.  I don't like the Yahoo web
interface, but I'm used to it. I prefer Topica, but can live with
Yahoo.

What is our problem – the web interface or the junk e-mail?  I
administer a Yahoo group for our bike club and I have complete
control over who can join and post messages.  There are varying
levels of control, all easy to set up and administer.

Mary Poppendieck
www.leanprogramming.com

I've been questioned recently about the xP plugin for the Rational
Unified Process (RUP) that ObjectMentor recently created for
Rational. It is only available currently for RUP customers with
license ID's, but I got a pretty good feel for what and how this was
done at a Rational demo site:
http://www.rational.com/demos/viewlets/rup/xp_plugin/XP_PlugIn_Preview
_viewlet.html

We've been struggling for some time with the difference between
traditional methodologies and agile methodologies. In my mind, this
difference is primarily based in the process control theory division
of defined vs empirical, that is: command and control vs emergent and
adaptive. I've always viewed RUP as a traditional methodology, but
one implemented in a hypertext tool rather than the traditional
database. However, I've been pleased that the underlying principles
that Grady Booch and others adhere to are very close to agile and
that they are making efforts to "lighten" RUP.

With this background, I was quite interested to look at the xP plugin
for RUP. I came away with mixed feelings. On the positive side, I
think that this plugin makes xP more understandable to people coming
at it from a traditional command-and-control background, and that are
trying to use xP within the RUP mindset. This will help
institutionalize and cause acceptance of many of the excellent xP
engineering practices.

On the negative side, I think the xP plugin cuts the heart of agility
right out of xP. Roles are identified and people asked to fulfill
them. Workproducts (artifacts) are defined and are shown to be
created sequentially - such as a user story is an output from a
release plan. The inspect/adapt cycle is lost, and the still unknown
mechanisms of emergence on which we all rely are turned into mini-
machines that can be repeated over and over. That is, the xP plugin
makes the systems development process look repeatable, CMM
certifiable, and like something that anyone can plugin and run like a
good command-and-control manager.

The heart of xP that you read in the xP series of books and sense in
conversations with Kent, Ron and Ward is lost in this translation. My
biggest concern with the plugin is that xP will be co-opted by this
commercialization of it. People will buy the plugin, implement it,
improve their engineering practices with it, but in no way realize
the spirit of it. The plugin is great for RUP, bad for xP. It reminds
me of the commercialization of love on TV.

I've never been shy in saying what I think. Take a look and let me
know what you think.
Ken Schwaber

Ken:

> It reminds me of the commercialization of love on TV.

No reason why there couldn't be a RUP plugin for that ! I can easily
see it - Inception, Elaboration, Conception, Alimony...

Cheers,

-[Morendil]-
- This tagline omitted for technical reasons -

Thanks for the feedback Ken and Tom.  We'll certainly use it to improve it.

Lowell

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

RUP is a very fascinating subject. It is almost always implemented as a
waterfall (on the dozen or so RUP projects I've seen and from I gather
from talking to others) yet when I read the RUP book ("The Unified
Software Development Process") I see ways I could manage a RUP project
in what I'd consider a very agile manner.

I don't really think the XP plugin "cuts the heart of agility" right out
of XP. DSDM defines work products and roles and it is still generally
thought of as an agile process. Even without defined roles most
developers will gravitate toward one or more of the traditional software
development roles. I'm working with a Scrum team right now and everyone
on the team has an official HR title of "Software Engineer" (hmm, that's
probably a bad title for any agile developer). There are no titles
beyond that but the five developers on this team have migrated into very
natural roles--one is clearly the architect of the system, one is
responsible for the database, one has taken on primarily testing, one
programmer has taken up the client side, and the last does the server.
Yes, they self-organized into these roles per the normal Scrum roles. If
I had made a bunch of HTML pages and said to the team "read these, they
tell you what each 'role' on the project does, then sign up for various
roles" I don't think it would have affected the team's organization.
They'd still be free to pick and choose and change those roles per the
needs of their project.

On the other hand, if a project manager mandates who fills which roles
and what deliverables come out and what those deliverables look like
then the process has lost its agility. I don't see the XP Plugin as
going anywhere near that far.

Similar arguments can be made about the definition of work products. If
they are given as examples and good ideas then I think they're great. In
implementing Scrum with teams the team will frequently decide that a few
design documents will be handy and they produce them. With some teams I
will encourage them to describe their expectations in the form of a
table of contents or list of issues to be addressed before they start
the document. In some ways this is similar to test-driven
development--how will I know this document is done unless I write its
"tests" first? If the team agrees on a template for what they want in a
design document before it's written it is much easier on the person
writing the design. Of course he is free to add or remove and to still
do whatever he wants but he knows the expectations of his
reviewers/users. (So maybe the right way to think of the expectations of
the design document is as "user stories.")

I think there are two types of agility: macro-agility and micro-agility.
Macro-agility is the agility of the project as a whole--how well it can
avoid backing itself into a design corner, how well it can cope with
sudden orthogonal requirements, etc. Micro-agility is the amount of
flexibility in the day to day work. XP, for examples, makes significant
tradeoffs from micro-agility for macro-agility. In XP I can't just
decide to code at whim--I have to write tests first and find someone to
pair with. That can be a serious crimp on how one likes to work.
However, a great amount of macro-agility is gained via that tradeoff. I
think it is perfectly reasonable to assume that other tradeoffs may
exist--for example, maybe I can great macro-agility if I define a "Chief
Architect" role as does FDD. It's when I push that definition too far
and have Chief Architects who refuse to code and eventually get too far
away from the code that I lose agility.

Here's a question for you, Ken: My favorite sections in your book were
the ones differentiating defined and empirical processes. That really
helped me see why Scrum works (and I'd been using it before you're book
so I knew it worked but I didn't really know why). In your book you tell
a story about chemists at DuPont and why they need to use an empirical
process in some cases (it's a simplification but generally when there's
too much uncertainty). Is it fair to say, though, that those chemists
would have preferred to use a defined process if they could gain enough
knowledge about the chemical reactions?

If that's true for the chemists it seems very true for Project Managers
who will use RUP or the XP Plugin for RUP. They want a defined process,
not an empirical one, and the real danger is that they take the XP
Plugin and apply it as though it's a defined process. They forgot the
uncertainty and vagueness around the process. It seems like this is
what's happened with RUP in general. Grady's "Object Solutions" book
(which I view as the main predecessor to RUP) is very agile, RUP can be
agile but rarely is implemented that way. It's just easier for someone
who is accustomed to defined process to implement RUP in a very
waterfall manner.

Bringing all this back to your conclusion: The Plugin is great for RUP,
bad for XP. I totally agree with you on this. XP will be tried by some
organizations who wouldn't have tried it otherwise. It will help
somewhat but not all the way (XP will be viewed as a failure by them)
but their engineering practices will be improved by some of the XP
practices.

--Mike


-----Original Message-----
From: Ken Schwaber [mailto:kschwaber@...]
Sent: Friday, October 04, 2002 7:46 AM
To: agilealliance@yahoogroups.com
Subject: [agilealliance] XP Plugin for RUP

I've been questioned recently about the xP plugin for the Rational
Unified Process (RUP) that ObjectMentor recently created for
Rational. It is only available currently for RUP customers with
license ID's, but I got a pretty good feel for what and how this was
done at a Rational demo site:
http://www.rational.com/demos/viewlets/rup/xp_plugin/XP_PlugIn_Preview
_viewlet.html

We've been struggling for some time with the difference between
traditional methodologies and agile methodologies. In my mind, this
difference is primarily based in the process control theory division
of defined vs empirical, that is: command and control vs emergent and
adaptive. I've always viewed RUP as a traditional methodology, but
one implemented in a hypertext tool rather than the traditional
database. However, I've been pleased that the underlying principles
that Grady Booch and others adhere to are very close to agile and
that they are making efforts to "lighten" RUP.

With this background, I was quite interested to look at the xP plugin
for RUP. I came away with mixed feelings. On the positive side, I
think that this plugin makes xP more understandable to people coming
at it from a traditional command-and-control background, and that are
trying to use xP within the RUP mindset. This will help
institutionalize and cause acceptance of many of the excellent xP
engineering practices.

On the negative side, I think the xP plugin cuts the heart of agility
right out of xP. Roles are identified and people asked to fulfill
them. Workproducts (artifacts) are defined and are shown to be
created sequentially - such as a user story is an output from a
release plan. The inspect/adapt cycle is lost, and the still unknown
mechanisms of emergence on which we all rely are turned into mini-
machines that can be repeated over and over. That is, the xP plugin
makes the systems development process look repeatable, CMM
certifiable, and like something that anyone can plugin and run like a
good command-and-control manager.

The heart of xP that you read in the xP series of books and sense in
conversations with Kent, Ron and Ward is lost in this translation. My
biggest concern with the plugin is that xP will be co-opted by this
commercialization of it. People will buy the plugin, implement it,
improve their engineering practices with it, but in no way realize
the spirit of it. The plugin is great for RUP, bad for xP. It reminds
me of the commercialization of love on TV.

I've never been shy in saying what I think. Take a look and let me
know what you think.
Ken Schwaber



To unsubscribe from this group, send an email to:
agilealliance-unsubscribe@yahoogroups.com



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

The reason that I used the strong phrase, "cuts the heart out" is exactly as
you described. Project managers and people new to XP will follow the defined
structure and think that xP is another defined process. They will not have
picked up on the distinction that only relatively simple projects, with very
little people,technology and requirements complexity and change can use
defined approaches. They will think that, since ObjectMentor and Rational
says that xP works in this manner, that it must work in this manner. They
will not use the constant inspection and adaptation required for complex
processes. The next step, of course, is for the plug-in to go to the
company's process group, where they will really nail it down as a defined
process. This is a constant trend and evolution of things, from a general
set of guidelines that require intelligence and collaboration to something
that is considered "rent an intelligence", where you applied the defined
process that someone else wrote and figure that - since they said it's ok -
that you can just measure hours and report changes.

The goal of all process engineering is to turn something into a defined
process. Empirical processes take a lot more effort, thought, intelligence,
and work. A defined process can be set up once and run over and over.
However, the defined process has to produce a product of quality adequate to
the customer. Therein lies the problem for DuPont's chemical engineers - the
precision of the specifications for the polymers exceeds the specificity of
the raw materials and their ability at this time to control the chemical
processes, so they have to use an empirical approach. Whereever possible
they use defined, because of the reduced costs. But, of course, once it's
defined and can be done without intelligence, it is a commodity and DuPont
can't charge for their chemical capability and skills. So, with the
empirical process, you are saying that this is such a complex thing that
intelligence, inspection, adaptation is required, so you get to charge more.

I'm going to give a talk at XPDay in England in November that will address
this topic. How the premature rush to "define" CMM and RUP as commodities
that can be generally applied without thinking led to their turning into a
pile of dust. And how exactly the same thing can happen to agile.

Ken



-----Original Message-----
From: Mike Cohn [mailto:mike@...]
Sent: Sunday, October 06, 2002 12:08 PM
To: agilealliance@yahoogroups.com; scrumdevelopment@yahoogroups.com
Subject: RE: [agilealliance] XP Plugin for RUP


RUP is a very fascinating subject. It is almost always implemented as a
waterfall (on the dozen or so RUP projects I've seen and from I gather
from talking to others) yet when I read the RUP book ("The Unified
Software Development Process") I see ways I could manage a RUP project
in what I'd consider a very agile manner.

I don't really think the XP plugin "cuts the heart of agility" right out
of XP. DSDM defines work products and roles and it is still generally
thought of as an agile process. Even without defined roles most
developers will gravitate toward one or more of the traditional software
development roles. I'm working with a Scrum team right now and everyone
on the team has an official HR title of "Software Engineer" (hmm, that's
probably a bad title for any agile developer). There are no titles
beyond that but the five developers on this team have migrated into very
natural roles--one is clearly the architect of the system, one is
responsible for the database, one has taken on primarily testing, one
programmer has taken up the client side, and the last does the server.
Yes, they self-organized into these roles per the normal Scrum roles. If
I had made a bunch of HTML pages and said to the team "read these, they
tell you what each 'role' on the project does, then sign up for various
roles" I don't think it would have affected the team's organization.
They'd still be free to pick and choose and change those roles per the
needs of their project.

On the other hand, if a project manager mandates who fills which roles
and what deliverables come out and what those deliverables look like
then the process has lost its agility. I don't see the XP Plugin as
going anywhere near that far.

Similar arguments can be made about the definition of work products. If
they are given as examples and good ideas then I think they're great. In
implementing Scrum with teams the team will frequently decide that a few
design documents will be handy and they produce them. With some teams I
will encourage them to describe their expectations in the form of a
table of contents or list of issues to be addressed before they start
the document. In some ways this is similar to test-driven
development--how will I know this document is done unless I write its
"tests" first? If the team agrees on a template for what they want in a
design document before it's written it is much easier on the person
writing the design. Of course he is free to add or remove and to still
do whatever he wants but he knows the expectations of his
reviewers/users. (So maybe the right way to think of the expectations of
the design document is as "user stories.")

I think there are two types of agility: macro-agility and micro-agility.
Macro-agility is the agility of the project as a whole--how well it can
avoid backing itself into a design corner, how well it can cope with
sudden orthogonal requirements, etc. Micro-agility is the amount of
flexibility in the day to day work. XP, for examples, makes significant
tradeoffs from micro-agility for macro-agility. In XP I can't just
decide to code at whim--I have to write tests first and find someone to
pair with. That can be a serious crimp on how one likes to work.
However, a great amount of macro-agility is gained via that tradeoff. I
think it is perfectly reasonable to assume that other tradeoffs may
exist--for example, maybe I can great macro-agility if I define a "Chief
Architect" role as does FDD. It's when I push that definition too far
and have Chief Architects who refuse to code and eventually get too far
away from the code that I lose agility.

Here's a question for you, Ken: My favorite sections in your book were
the ones differentiating defined and empirical processes. That really
helped me see why Scrum works (and I'd been using it before you're book
so I knew it worked but I didn't really know why). In your book you tell
a story about chemists at DuPont and why they need to use an empirical
process in some cases (it's a simplification but generally when there's
too much uncertainty). Is it fair to say, though, that those chemists
would have preferred to use a defined process if they could gain enough
knowledge about the chemical reactions?

If that's true for the chemists it seems very true for Project Managers
who will use RUP or the XP Plugin for RUP. They want a defined process,
not an empirical one, and the real danger is that they take the XP
Plugin and apply it as though it's a defined process. They forgot the
uncertainty and vagueness around the process. It seems like this is
what's happened with RUP in general. Grady's "Object Solutions" book
(which I view as the main predecessor to RUP) is very agile, RUP can be
agile but rarely is implemented that way. It's just easier for someone
who is accustomed to defined process to implement RUP in a very
waterfall manner.

Bringing all this back to your conclusion: The Plugin is great for RUP,
bad for XP. I totally agree with you on this. XP will be tried by some
organizations who wouldn't have tried it otherwise. It will help
somewhat but not all the way (XP will be viewed as a failure by them)
but their engineering practices will be improved by some of the XP
practices.

--Mike


-----Original Message-----
From: Ken Schwaber [mailto:kschwaber@...]
Sent: Friday, October 04, 2002 7:46 AM
To: agilealliance@yahoogroups.com
Subject: [agilealliance] XP Plugin for RUP

I've been questioned recently about the xP plugin for the Rational
Unified Process (RUP) that ObjectMentor recently created for
Rational. It is only available currently for RUP customers with
license ID's, but I got a pretty good feel for what and how this was
done at a Rational demo site:
http://www.rational.com/demos/viewlets/rup/xp_plugin/XP_PlugIn_Preview
_viewlet.html

We've been struggling for some time with the difference between
traditional methodologies and agile methodologies. In my mind, this
difference is primarily based in the process control theory division
of defined vs empirical, that is: command and control vs emergent and
adaptive. I've always viewed RUP as a traditional methodology, but
one implemented in a hypertext tool rather than the traditional
database. However, I've been pleased that the underlying principles
that Grady Booch and others adhere to are very close to agile and
that they are making efforts to "lighten" RUP.

With this background, I was quite interested to look at the xP plugin
for RUP. I came away with mixed feelings. On the positive side, I
think that this plugin makes xP more understandable to people coming
at it from a traditional command-and-control background, and that are
trying to use xP within the RUP mindset. This will help
institutionalize and cause acceptance of many of the excellent xP
engineering practices.

On the negative side, I think the xP plugin cuts the heart of agility
right out of xP. Roles are identified and people asked to fulfill
them. Workproducts (artifacts) are defined and are shown to be
created sequentially - such as a user story is an output from a
release plan. The inspect/adapt cycle is lost, and the still unknown
mechanisms of emergence on which we all rely are turned into mini-
machines that can be repeated over and over. That is, the xP plugin
makes the systems development process look repeatable, CMM
certifiable, and like something that anyone can plugin and run like a
good command-and-control manager.

The heart of xP that you read in the xP series of books and sense in
conversations with Kent, Ron and Ward is lost in this translation. My
biggest concern with the plugin is that xP will be co-opted by this
commercialization of it. People will buy the plugin, implement it,
improve their engineering practices with it, but in no way realize
the spirit of it. The plugin is great for RUP, bad for xP. It reminds
me of the commercialization of love on TV.

I've never been shy in saying what I think. Take a look and let me
know what you think.
Ken Schwaber



To unsubscribe from this group, send an email to:
agilealliance-unsubscribe@yahoogroups.com



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






To unsubscribe from this group, send an email to:
agilealliance-unsubscribe@yahoogroups.com



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

--- In scrumdevelopment@y..., "Ken Schwaber" <ken.schwaber@v...>
wrote:
>  The next step, of course, is for the plug-in to go to the
> company's process group, where they will really nail it down as a
defined
> process. This is a constant trend and evolution of things, from a
general
> set of guidelines that require intelligence and collaboration to
something
> that is considered "rent an intelligence", where you applied the
defined
> process that someone else wrote and figure that - since they said
it's ok -
> that you can just measure hours and report changes.

You're a bitter, bitter man, Ken. ;->

It is true that many people think as you describe. It is also true
that many do not. The current very small software process group at
Ford, for example, chartered to help the company do RUP, is staffed
entirely by XP people. With XP identified as a valid form of RUP,
they are in a position to install the practices there.

My opinion is that we only learn that the "empirical" processes work
through experience. No amount of reasoning can convince us that
our "defined" process view is wrong.

So my thrust, wherever I go, is to get teams to try the agile
practices. Trying them, some of them, at least, will get it. I know
no better way, though I'd be happy to learn one.

We at OM had great concerns about doing the XP plug-in, for just the
reasons you mention. (And because we feared that none of you would
ever talk to us again.) My own view was simple: Rational clearly
would put XP under RUP. If that was to be the case, I felt that we
owed it to the universe to see that it was as good as possible.

We've done the first cut, and we're hoping that the agile community
will help us make it better.

Regards,

Ron

I assume everyone in the list followed this comment, but it is worth
repeating.  Yahoo Groups has a nice digest feature; no advertisements
(except for the people who SP~M the group), and the one daily e-mail
makes for a quick read to scan for what is interesting.

As the saying goes, "and now for something completely different."

I would love to get feedback from those with some experience in a
management-centric environment on how to get some traction with
Agile.  Here's the current situation:  I've introduced a slight
variation of scrum that is only within our development group (we are
basically handed a product backlog that does not change at the
beginning of development).  While scrum is not quite ubiquitous on
teams, it is fairly well received within development, but there are a
couple challenges to becoming truly agile.

First, as I mentioned, we tend to be a management-centric group, so
it's been a challenge for the leadership to let go of the reigns a
bit and also for a lot of the development team to grab on and drive.
Second, we deliver to external customers, so our marketing team, I
think, would be our closest proxy for "the customer" but I haven't
yet successfully engaged them in the process.  Finally, if we can
successfully engage the rest of the business, I need a better
understanding of how we expand the scope from software deliveries at
the end of each sprint, to a complete product delivery that is ready
for manufacture, sale, and service when we launch to external
customers.

Thanks so much in advance for any advice anyone can pass my way.

Dan


--- In scrumdevelopment@y..., "Mike Cohn" <mike@m...> wrote:
> It looks good to me but the Yahoo ads don't bother me very much
because
> I use email rather than the web for this group.
>

Dan--
One of the nice things with Scrum is that it is very applicable at
organizational levels above where the software happens. When I've sold
Scrum to directors, VPs, CEOs, etc., the approach I take is

1)describe the problem(s) they are currently facing and get their
agreement that I really know the problems. You can probably do this with
some variation of "Our products are generally well received and have
acceptable defect levels but customers are constantly pushing for faster
deliveries" or "We meet our dates but we always end up cutting some
(many?) of the features we've previously told people we'll have in the
product.

2) I don't really go into Scrum and what it's all about. I use the name
"Scrum" but I don't say, "we're going to make this group agile etc...".
Rather, I just describe an approach--stress that you're doing the
project in one month increments and that during that one month the
developers commit to completing everything they sign up for and that you
want the business to commit to not changing things (that doesn't sound
like a problem in your case). Describe how you'll meet at the start of
the month to create the "sprint backlog" and how the marketing person (a
"product manager" or in Scrum terms the "Product Owner") completely owns
the prioritization but that the team will draw a line under the tasks
they can commit to. Tell the person you're selling about the "daily
scrum" meetings and tell him how he can attend any of these he wants but
that he's a chicken and will be there just to observe.

3) Explain how the Product Owner can call "Release!" whenever he or she
wants following a sprint. Tell him how any estimates you give decrease
in accuracy quickly beyond one or two sprints into the future. Negotiate
that estimates from you will be in the number of sprints (months) it
will take to do the project. I'll typically say something like, "Based
on my understanding of the features needed before we can sell the new
version, I estimate this project will take 3-5 sprints (months) before
it will releasable. We'll be at the 3 end if we opt to release near the
low end of what the Product Owner says is needed and if things go well;
we'll be at the 5 if we're at the high end of that or if we have some
problems or turnover, etc. Most importantly, we'll be able to make that
decision on a month-to-month basis."

4) Go over some of the economics (not really the dollars, though) of
what you're proposing. For example, a point that Ken taught me is how
really low the opportunity cost for Scrum is. What is the absolute worst
case of trying Scrum for 30 days? Scrum can be implemented in a day and
without any tool costs or dramatic changes in engineering practices
(some changes are usually appropriate, especially incorporating some of
the good ideas from XP but they aren't necessary right off). In an
absolutely disastrous situation the team would have gone off and coded
for 30 days and produced something that the organization doesn't want.
Even if you find Scrum doesn't work for some reason then you switch back
after 30 days.

5) Scrum really takes off when you get the whole company thinking Scrum.
I'm working with an organization right now and we're moving Scrum up
from the engineers to a process we use for allocating resources across
the company. This is a really small company (20 people) but they have
dozens of commercial products and so we're starting to introduce a
higher level set of Scrum activities to decide where programmers should
spend their time. I haven't tried this yet (but I will within two weeks)
but I am really intrigued with using Real Option Valuation (an
alternative to simple ROI calculations) in these management Scrums.

In terms of expanding Scrum beyond development so that it includes all
of the other product deliverables: There's really no secret there--just
put those items on the product backlog and then move them into
appropriate sprint backlogs. On most products this feels a bit weird but
it's still worth doing. What I mean by that is you put tasks on the
backlog of "write user's guide" and like Scrum says you don't really
assign that to a particular person. Well, if you've only got one tech
writer it's pretty obvious who will do the work. It's the same case with
"design packaging" and "write marketing collateral" and "place ads" etc.
All those activities are not ones a programmer is likely to pull off a
sprint backlog list. Anyway, I do track them on the sprint backlog
because it helps me get a good overall view of the project AND many of
these activities do spinoff engineering tasks--e.g., proofreading
sections of the manual, etc. Those tasks can be handled just like coding
tasks so they should be tracked that way. Also, this helps make sure
that these tasks aren't forgotten when the programmers plan how much
they can get done. One thing I do when I'm tracking these types of
activities--I'll typically leave them out of my sprint burndown charts
(so the burndown chart is just the "true" engineering tasks (including
test)), or I may show the burndown with and without them, depending on
the project. The burndown charts are most useful when there's a lot of
uncertainty in tasks. For example, most tech writers end up having their
work very timeboxed such that they know they have 3 days on chapter 1
and 5 on chapter 2. Those types of tasks burn down at predictable rates
so they mask real trends in the burndown chart.

Yes, use your marketing team or ideally a single "Product Manager" in
that group as your customer. I've done plenty of commercial software
w/Scrum and always use that type of person. I've had people suggest I
use a "customer advisory team" but I've always been in too big of a
hurry for that and trust the Product Manager to invoke such a team on
the occasional item where it's necessary.

Good luck and post some progress reports to this group. I'm sure I'm not
the only one who would like to hear how it goes.

--Mike


-----Original Message-----
From: Dan Brown [mailto:kid_danomite@...]
Sent: Sunday, October 06, 2002 7:42 PM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Re: Alternative to EGroups + scrum in a
"management" org

I assume everyone in the list followed this comment, but it is worth
repeating.  Yahoo Groups has a nice digest feature; no advertisements
(except for the people who SP~M the group), and the one daily e-mail
makes for a quick read to scan for what is interesting.

As the saying goes, "and now for something completely different."

I would love to get feedback from those with some experience in a
management-centric environment on how to get some traction with
Agile.  Here's the current situation:  I've introduced a slight
variation of scrum that is only within our development group (we are
basically handed a product backlog that does not change at the
beginning of development).  While scrum is not quite ubiquitous on
teams, it is fairly well received within development, but there are a
couple challenges to becoming truly agile.

First, as I mentioned, we tend to be a management-centric group, so
it's been a challenge for the leadership to let go of the reigns a
bit and also for a lot of the development team to grab on and drive.
Second, we deliver to external customers, so our marketing team, I
think, would be our closest proxy for "the customer" but I haven't
yet successfully engaged them in the process.  Finally, if we can
successfully engage the rest of the business, I need a better
understanding of how we expand the scope from software deliveries at
the end of each sprint, to a complete product delivery that is ready
for manufacture, sale, and service when we launch to external
customers.

Thanks so much in advance for any advice anyone can pass my way.

Dan


--- In scrumdevelopment@y..., "Mike Cohn" <mike@m...> wrote:
> It looks good to me but the Yahoo ads don't bother me very much
because
> I use email rather than the web for this group.
>




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/

On Sunday, October 6, 2002, at 10:17:29 PM, Mike Cohn wrote:

> 2) I don't really go into Scrum and what it's all about. I use the name
> "Scrum" but I don't say, "we're going to make this group agile etc...".
> Rather, I just describe an approach--stress that you're doing the
> project in one month increments and that during that one month the
> developers commit to completing everything they sign up for and that you
> want the business to commit to not changing things (that doesn't sound
> like a problem in your case).

I thought that in Scrum the developers commit to completing as much as
they can, not as much as is provided? What am I missing?

Thanks,

Ron Jeffries
www.XProgramming.com
Speculation or experimentation - which is more likely to give the correct
answer?

Ron's right, the developers (team) commits to completing as much as they can
of the product backlog, aiming as the sprint goal to which they committed.
The goal is the overall purpose of the sprint, the backlog is what they have
to turn into product functionality to meet the goal. They are free to add
and subtract (with the customers colaboration) from the backlog as long as
they meet the goal. If the requirements become irrelevant or the technology
untractable during the sprint so that they can't meet the goal, the sprint
can be abnormally terminated either by the customer or the team.
Ken

-----Original Message-----
From: Ron Jeffries [mailto:ronjeffries@...]
Sent: Monday, October 07, 2002 1:40 AM
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] Re: Alternative to EGroups + scrum in a
"management" org


On Sunday, October 6, 2002, at 10:17:29 PM, Mike Cohn wrote:

> 2) I don't really go into Scrum and what it's all about. I use the name
> "Scrum" but I don't say, "we're going to make this group agile etc...".
> Rather, I just describe an approach--stress that you're doing the
> project in one month increments and that during that one month the
> developers commit to completing everything they sign up for and that you
> want the business to commit to not changing things (that doesn't sound
> like a problem in your case).

I thought that in Scrum the developers commit to completing as much as
they can, not as much as is provided? What am I missing?

Thanks,

Ron Jeffries
www.XProgramming.com
Speculation or experimentation - which is more likely to give the correct
answer?



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/

On Monday, October 7, 2002, at 9:46:28 AM, Ken Schwaber wrote:

> Ron's right, the developers (team) commits to completing as much as they can
> of the product backlog, aiming as the sprint goal to which they committed.
> The goal is the overall purpose of the sprint, the backlog is what they have
> to turn into product functionality to meet the goal. They are free to add
> and subtract (with the customers colaboration) from the backlog as long as
> they meet the goal. If the requirements become irrelevant or the technology
> untractable during the sprint so that they can't meet the goal, the sprint
> can be abnormally terminated either by the customer or the team.

Now, this may be exactly what Mike meant by "committing to what they
sign up for". Let me try out some differences between Scrum and XP to
see if I understand. These are in the form of statements, but they are
really questions:

   In Scrum, the developers pick from an ordered list of backlog, that
   is the Backlog Owner says what the priorities are and the team does
   the top N that they feel they can commit to, based on their
   assessment of their velocity.

   In XP, based on existing estimates for stories and on the team's
   measured velocity, the customer picks stories that s/he next wants
   to see done. The team signs up for those.

   Comparing, in Scrum the team commits to the high level goals but not
   to the details, nor to the how. In XP, the team undertakes to meet
   the Customer's detailed acceptance tests, but still not to the how,
   and renegotiates when it appears that they will fall short. XP
   involves the Customer in the tradeoff decision, while by definition,
   pardon the term, Scrum does not. (I'll bet that in practice, Scrum
   teams do commonly go to the owner and offer alternatives when
   there's tradeoff to be done.)

So there's an equivalent amount of real "commitment", I'd say. Now
Mike said:

> Rather, I just describe an approach--stress that you're doing the
> project in one month increments and that during that one month the
> developers commit to completing everything they sign up for and that you
> want the business to commit to not changing things (that doesn't sound
> like a problem in your case). Describe how you'll meet at the start of
> the month to create the "sprint backlog" and how the marketing person (a
> "product manager" or in Scrum terms the "Product Owner") completely owns
> the prioritization but that the team will draw a line under the tasks
> they can commit to.

In a recent conversation on the xp group, Bill Walton who bravely came
and talked with us after writing an op/ed piece that many XPers
roundly trounced, made the point that in his experience, managers want
hard answers as to how much some project will cost. He feels that they
will not sit still for approaches like the above, because they don't
let them decide go / nogo on a project and its budget.

Do you feel the same pressure to come up with a complete answer? How
do you deal with it?

Ron Jeffries
www.XProgramming.com
To be on the wire is life. The rest is waiting.  --Karl Wallenda

>
> Bringing all this back to your conclusion: The Plugin is
> great for RUP, bad for XP. I totally agree with you on this. XP will be
tried by some
> organizations who wouldn't have tried it otherwise. It will help somewhat
but not all
> the way (XP will be viewed as a failure by them) but their engineering
practices
> will be improved by some of the XP practices.
>

I have always believed that doing the practices, but not "getting it," is
better than not doing the practices.  If someone is not going to "get it"
through the literature and does not have an audience with someone who can
explain it, then the best shot is to try it and see it work.

What you are describing as bad for XP is the status quo for XP (and any
other method). The Plug-In won't have much of an effect on that, no matter
how well or poorly written.

Many teams do XP "not all way."  My understanding is that SCRUM is often
used in cases where a team won't do XP all the way.   Many have used parts
of XP to improve their engineering practices.  How is this bad for XP?   I
think its great!  Not everyone is going to have this instant revelation on
how wonderful emergence and self-organization are.  Some will need to see
the practices work before they are open to such a revelation.  I've observed
some cases, where the revelation is much stronger having come from a real
experience versus an intellectual activity.

My belief is that anything that gets people exposed to the values and
principles and gets them trying the practices is good for XP and Agile.

All that said, how to express the values in a non-interactive media is very
difficult and something we'll continue to work hard on.

Thanks again for the feedback!

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

Lowell:

> My belief is that anything that gets people exposed to the values and
> principles and gets them trying the practices is good for XP and Agile.

When you say "anything", do you really mean *anything* ?

Cheers,

-[Morendil]-
[ This tagline has been left blank intentionally. ]

Hmm, I must not have been clear. Here's how a typical Scrum project goes
for me:

First we work with a "Product Owner" to jumpstart the Product Backlog
with all the "obvious" items on the list. (For the last year I've been
capturing most of these as XP stories.) This takes a few hours and
results in what will usually be 2-6 months of work for the team. I don't
estimate it at that point but by the time most organizations get around
to deciding to actually develop a product they have lots of ideas about
what goes in it--some good, some bad.

Based on what the Product Owner says the priorities are the team pulls
off the top N tasks and says "This is what we can commit to finishing
(tested, etc.) in a month." In reality it's never the exact top N tasks
but rather it is the top M tasks plus "a few" more that are near the top
but not the "next" items. I've never met a Product Owner who had a
problem with this because their prioritization are approximate anyway,
especially early on.

The team codes. The Product Owner comes up with new items on the
Backlog.

So--yes, the team commits to completing as much as they can but they
make that commitment at the start of the sprint (iteration) by pulling
off a bundle of work. As Ken noted the real measure of their success is
against a "sprint goal," which is a summary of what they're doing in the
sprint, not against the exact list of tasks. I'm not sure I've had more
than a couple of sprints deliver everything exactly in the sprint and no
more/no less. Usually the team will pull a couple of things in and/or
ask for permission to defer an item or two.

Most of the Scrum teams I've worked with tend to pull in too much
(especially at first) so I've encouraged them to pull in what they "know
they can do". That way we know we'll finish the most important tasks and
we can pull more in from there. I don't like situations where we pull in
the 10 most important and then decide we're not going to finish so we
drop the second-most important item. That's wrong for delivering value
to our customer so I encourage it to go the other way. XP's idea of
velocity here has been very useful in helping me assist Scrum teams by
knowing how much they need to over or underestimate their capacity.

--Mike



-----Original Message-----
From: Ron Jeffries [mailto:ronjeffries@...]
Sent: Sunday, October 06, 2002 11:40 PM
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] Re: Alternative to EGroups + scrum in a
"management" org

On Sunday, October 6, 2002, at 10:17:29 PM, Mike Cohn wrote:

> 2) I don't really go into Scrum and what it's all about. I use the
name
> "Scrum" but I don't say, "we're going to make this group agile
etc...".
> Rather, I just describe an approach--stress that you're doing the
> project in one month increments and that during that one month the
> developers commit to completing everything they sign up for and that
you
> want the business to commit to not changing things (that doesn't sound
> like a problem in your case).

I thought that in Scrum the developers commit to completing as much as
they can, not as much as is provided? What am I missing?

Thanks,

Ron Jeffries
www.XProgramming.com
Speculation or experimentation - which is more likely to give the
correct answer?



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/

On Monday, October 7, 2002, at 10:21:25 AM, Laurent Bossavit wrote:

> Lowell:

>> My belief is that anything that gets people exposed to the values and
>> principles and gets them trying the practices is good for XP and Agile.

> When you say "anything", do you really mean *anything* ?

Can you think of something that gets people exposed to the values and
principles, and gets them trying the practices, but that is not good
for XP and agile?

For extra credit, can you think of anything a reasonable person would
actually do that meets those criteria?

Ron Jeffries
www.XProgramming.com
Wisdom begins when we discover the difference between
"That makes no sense" and "I don't understand". --Mary Doria Russell