Newsgroups: comp.lang.smalltalk,comp.lang.c++,comp.object
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!gatech2!swrinde!newsfeed.internetmci.com!EU.net!sun4nl!ktibv!gnome
From: rdb@ktibv.nl (The Graphical Gnome)
Subject: Re: SCRUM and Why the Waterfall Methodology is a Fool's Errand ...
Message-ID: <DIusH9.Dp3@ktibv.nl>
Sender: usenet@ktibv.nl (News System Administrator)
Organization: Kinetics Technology International b.v.
X-Newsreader: News Xpress Version 1.0 Beta #4
References: <30AF370B.1AE@vmark.com> <jzqcvc@bmtech.demon.co.uk>
	<48spd4$s30@ixnews4.ix.netcom.com> <30B34179.66AF@oma.com>
	<49ffbj$oon@dns1.mci.com> <49fk7a$jc@brtph500.bnr.ca>
	<49fplo$nlq@ixnews5.ix.netcom.com> <RMARTIN.95Nov29025047@rcm.oma.com>
Date: Thu, 30 Nov 1995 11:12:46 GMT
Lines: 38
Xref: glinda.oz.cs.cmu.edu comp.lang.smalltalk:31298 comp.lang.c++:162624 comp.object:41670

In article <RMARTIN.95Nov29025047@rcm.oma.com>,
   rmartin@oma.com (Robert C. Martin) wrote:
>In article <49fplo$nlq@ixnews5.ix.netcom.com> kentb@ix.netcom.com (Kent Beck 
) writes:
>
>   Fairy-land is the only place you know what you're supposed to do before
>   you start. I've seen three reactions to this- force the client to
>   commit to something early and deliver a system they don't want, accept
>   changes throughout the project and end up with a late, low quality
>   system, or deliver the system in pieces, imagining the long term result
>   but being prepared to change. This last is what works best for me, and
>   (giving a brief nod to the title of this thread) what is suggested by
>   SCRUM.
>
>   Manage change.
>
>Well said.

Very well said. But not always practical.

I'm working on a automation department and all our projects are inhouse 
projects. In this way it is impossible to manage changes. We somtimes have to 
undo weeks of work, just because some manager B desides to have it the other 
way around than desided by manager A. And if you manager is afraid of B and 
not of A, your in a hell of trouble.

This does not happen once in a project, but about once every week.

My last project ran for 4 years (planned 3.5, so not to bad).

Working in a admosphere like this means, trying to convince managers that the 
people I'm making the program for like it the way it was before. Somtime you 
succes, most of the time not.

Working in very small parts and adding those parts to the working version is 
the only way these projects are manageble.

R.E. den Braasem (ka The Graphical Gnome (rdb@ktibv.nl))
