RE: The Essence of Agile and Scrum

I think I said something like "an iterative lifecycle of short timeboxed
iterations is the most important ingredient in successful process." 


Consider an alternative: a 3 year waterfall project in which year 1 is
requirements analysis, year 2 is design, and year 3 is implementation. 


I claim that on such a project, you could throw all the pair
programming, self-directed creative team, scrum meetings, test first
development, etc at it you want, and it would still be very risky, and
perhaps fail due to the myriad problems that arise from a sequential
lifecycle of very long req -> des -> impl. 


I've seen lots of techniques and values in the 25 years I've been in the
business, and nothing has more influence and implications than moving
from "year 1 req, year 2 des, year 3 impl" to "from the start, when only
partial reqs are known, incrementally build software in 4 week (or
whatever) iterations." from that lifecycle practice arises explicitly or
implicitly so much else in terms of PM, req analysis, adaptation, risk
mgmt, prioritization, build tools and test practices,
architecture/design, ...


I think that in the modern promotion of "agile" methods, the old,
venerable and key critical practice of short iterations rather than the
waterfall, which dates back to the 70s in some enlightened camps, is the
real magic sauce without which the other practices and values lose much
power. 


As an aside, Dr. Vic Basili and I are writing "the history of iterative
development" article for IEEE Computer. It is a fascinating history
imho.

Do any of you have contributions to the chronology and references? Input
much appreciated at: http://c2.com/cgi/wiki?HistoryOfIterative 

regards, craig


> -----Original Message-----
> From: Ken Schwaber [mailto:ken.schwaber@xxxxxxxxxxx]
> Sent: Thursday, December 05, 2002 11:28 PM
> To: scrumdevelopment@xxxxxxxxxxxxxxx
> Cc: Craig Larman
> Subject: The Essence of Agile and Scrum
> 
> I was at a BOF at SD East and Craig brought up that he thought that
> time-boxing, as in the Sprint, was the essence of agility. I demurred
a
> reply at the time, but I've decided in retrospect that time-boxing is
> critical. However, the following aspects are equally critical, and all
of
> them play with each other to create the beauty of agility:
> 1. That the work being done in the time-box is of the greatest urgency
and
> importance to the user, the customer, otherwise why is the time-box
> relevant?
> 2. That the people in the time-box are able to be as creative as
possible
> to
> reach the best solution they can come up with. That is, that the
> principles
> of self-organization and then emergence will be given full play within
the
> time-box. If someone external is directing the team, then it's not
agile.
> 3. That the team has good engineering practices so that what they
create
> is
> the real thing, not just some pale shadow of the real thing ... such
as a
> buggy, poorly designed set of functionality that really never has a
chance
> of being "an increment of potentially shippable code."
> 
> My thoughts,
> Ken



To Post a message, send it to:   scrumdevelopment@xxxxxxxxxxx
To Unsubscribe, send a blank message to: 
scrumdevelopment-unsubscribe@xxxxxxxxxxx 

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