Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!news.kei.com!newsfeed.internetmci.com!howland.reston.ans.net!ix.netcom.com!netcom.com!rfenney.slip.netcom.com!user
From: rfenney@directnet.com (Robert J. Fenney)
Subject: Re: SCRUM and Why the Waterfall Methodology is a Fool's Errand ...
Message-ID: <rfenney-281195180817@rfenney.slip.netcom.com>
Followup-To: comp.lang.smalltalk,comp.lang.c++,comp.object
Sender: netnews@mork.netcom.com
Nntp-Posting-Host: rfenney.slip.netcom.com
Organization: FenTek
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>
Date: Wed, 29 Nov 1995 02:14:32 GMT
Lines: 53

In article <49fk7a$jc@brtph500.bnr.ca>, mancus@bnr.ca (Cathy Mancus) wrote:

> 
> In article <49ffbj$oon@dns1.mci.com>, tuttor@velveeta.enet.dec.com () writes:
> > It seems to me that there are times when different methods are appropriate.
> > When requirements are very well known (as above), or if the level of
> > complexity of the problem is not very large (as in a college homework
> > assignment), the waterfall method may be more appropriate.
> 
>   I think you have put your finger on a very important, oft-overlooked
> (at least by management) point, and it goes beyond the waterfall/iterative
> battle.  Specifically, the success of most projects depends on how
> well the requirements are understood early in the design phase.
> 
>   The biggest headaches on projects I've seen up close are almost never
> due to "bad" design; they are due to design that didn't take into account
> requirements that were "discovered" late in the design phase or even
> the implementation phase.  The same thing can happen in an interative
> model, because it is not time- or resource-efficient to scrap half the
> design in a late iteration and recode it all.
> 
>   I believe the biggest weakness in the software business today is
> the lack of sufficient process, and understanding of process, to figure out
> what you want to build *before* you call in the programmers to design and
> implement it.  Even the best designers will often lack background in the
> domain in which they are working, due to high turnover and large amounts
> of contract work.
> 
> [The above opinions are my own; no corporate entity is responsible.]
> 
> /-------------------------------------------------------------------\
> |  Catherine Mancus               <cathy@zorac.cary.nc.us>          |
> |  PP-SEL, N5WVR                  "God is a sponge."                |
> \-------------------------------------------------------------------/

How about TTM (Time TO Market)? 20 years ago a project could run over a
number of years and it did not matter. Now we measure market opertunities
in months, weeks, and days (usually under 6 months). These time frames do
not leave room for anything close to a waterfall time requirement. The
advantage that Objects bring to the table is the abillity to capture
knowledge about a market/oppertunity and to leverage it accross a number of
addition market/oppetunities while refining and building a better
understanding of how to respond in a real-time environment.

I generally listen to the staff at my client talk aabout how management
wont give them the time to do it right when they have not shown management
that they can deliver in the first place. Management is looking for
partners from IT professionals. They want experts how can learn a problem
domain and help them to servive in a very competitive market!



Robert
