746Re: The Essence of Agile and Scrum
- Dec 10, 2002Linda:
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.
--- In firstname.lastname@example.org, Linda Rising <risingl@a...>
> John Muir, the founder of the Sierra Club said something like --when
> you try to pick up anyuniverse :-)!
> one thing, you find it's connected to everything else in the
> 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.
> gotta have goodtimeboxed
> 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
> >iterations is the most important ingredient in successfulprocess."
> >1 is
> >Consider an alternative: a 3 year waterfall project in which year
> >requirements analysis, year 2 is design, and year 3 isimplementation.
> >I claim that on such a project, you could throw all the pair
> >programming, self-directed creative team, scrum meetings, test
> >development, etc at it you want, and it would still be veryrisky, and
> >perhaps fail due to the myriad problems that arise from asequential
> >lifecycle of very long req -> des -> impl.in the
> >I've seen lots of techniques and values in the 25 years I've been
> >business, and nothing has more influence and implications thanmoving
> >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 (orexplicitly or
> >whatever) iterations." from that lifecycle practice arises
> >implicitly so much else in terms of PM, req analysis, adaptation,risk
> >mgmt, prioritization, build tools and test practices,than the
> >architecture/design, ...
> >I think that in the modern promotion of "agile" methods, the old,
> >venerable and key critical practice of short iterations rather
> >waterfall, which dates back to the 70s in some enlightened camps,is the
> >real magic sauce without which the other practices and valueslose much
> >As an aside, Dr. Vic Basili and I are writing "the history of
> >development" article for IEEE Computer. It is a fascinatinghistory
> >imho.references? Input
> >Do any of you have contributions to the chronology and
> >much appreciated at: http://c2.com/cgi/wiki?HistoryOfIterativethat
> >regards, craig
> >>-----Original Message-----
> >>From: Ken Schwaber [mailto:ken.schwaber@v...]
> >>Sent: Thursday, December 05, 2002 11:28 PM
> >>To: email@example.com
> >>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
> >>time-boxing, as in the Sprint, was the essence of agility. Idemurred
> >>boxing is
> >>reply at the time, but I've decided in retrospect that time-
> >>critical. However, the following aspects are equally critical,and all
> >>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
> >>importance to the user, the customer, otherwise why is the time-
> >>2. That the people in the time-box are able to be as creative as
> >>reach the best solution they can come up with. That is, that the
> >>of self-organization and then emergence will be given full play
> >>time-box. If someone external is directing the team, then it's
> >>3. That the team has good engineering practices so that what they
> >>the real thing, not just some pale shadow of the real thing ...
> >>has a
> >as a
> >>buggy, poorly designed set of functionality that really never
> >>of being "an increment of potentially shippable code."
> >>My thoughts,
> >To Post a message, send it to: scrumdevelopment@e...
> >To Unsubscribe, send a blank message to: scrumdevelopment-
> >Your use of Yahoo! Groups is subject to
- << Previous post in topic Next post in topic >>