Re: The Essence of Agile and Scrum

Linda:
It is "all connected."  However, I believe Craig's observation is 
still correct -- as is yours.  In fact, together, they give the 
insight that we use to institute agile in a company that is not 
currently doing agile.  We say: let's get short, time-boxed cycles 
in.  OK, now that we know we have to do this, what things must we do 
to facilitate this (this is usually a scope problem).  What things 
can we do to facilitate this (there is always low-hanging fruit).  
If we can't do monthly cycles (our preference) can we at least break 
the project up somewhat?

This enables us to unfold the problem, so to speak.  Do a little, 
see how it works and do some more.

Alan Shalloway
Net Objectives


--- In scrumdevelopment@xxxxxxxxxxxxxxx, Linda Rising <risingl@xxxx> 
wrote:
> John Muir, the founder of the Sierra Club said something like -- 
when 
> you try to pick up any
> one thing, you find it's connected to everything else in the 
universe :-)!
> 
> I've seen projects that were struggling unsuccessfully with short 
> timeboxed iterations -- what
> saved them was Scrum meetings. I'm a real fan of those meetings. 
You 
> gotta have good
> communication or those short timeboxed iterations deliver too many 
> surprises :-)!
> 
> It's all connected, guys :-)!
> 
> 
> 
> 
> Craig Larman wrote:
> 
> >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@xxxx]
> >>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@xxxx
> >To Unsubscribe, send a blank message to: scrumdevelopment-
unsubscribe@xxxx 
> >
> >Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 
> >
> >
> >


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/