Re: [scrumdevelopment] Re: Burn Up Charts
- On Wednesday, April 2, 2003, at 3:34:35 PM, Phil Goodwin wrote:
> It seems to me that time is also negotiable. It makes sense to limit theIn my experience, the date is almost always the most important thing, in
> amount of work scheduled for an iteration to the the amount indicated by
> the current velocity times the duration of the iteration. But, I don't
> think that it makes sense to limit the number of iterations in the
> project by assigning a fixed ship date.
spite of the fact that I have only worked on one project in my entire life
where the date chosen had any basis in reality. I believe that the wise
thing to do for most teams is to plan for a fixed delivery date and to use
scope control to hit that date exactly, with the best possible running
software (which has been shipped every two weeks all along, but this is the
one everyone will care about).
> On a pure XP project I don't think that the developers ever have to careIf you do it perfectly, yes, this should be true. Perfection has been
> about the ship date because their behavior won't change because of it.
granted only to a lucky few of us, so I would expect that most projects
would in fact be doing things a bit differently in final iterations.
Only the hand that erases can write the true thing. -- Meister Eckhart
> I think it is fine to assume that it is "independentAgreed!
> thinking". This is a good thing because it confirms
> that at least 2 people can reach the same conclusions
> and can validate their experiences and explain
> the world the same way.
> (You could alwaysI think we struggle with researching "previous art" because most of the
> ask the question the other way: Is the stuff
> from "Growing Software" coming from somewhere else
> since our stuff was published 5-7 years ago
> i.e. PLOP3 proceedings, PLOPD4 book, etc. I think
> it is safe to assume "independent thinking" because
> our industry is famous for not researching
> "previous art". In hard Science this would actually
> be an embarrassment.)
leading agile thinkers are in the trenches, not in academia. This is why I was
excited when I saw the overlap between the Scrum book and "Growing
Software". I figured that both the Scrum folks and Roy had probably not had
the opportunity to find each other.
I look forward to the outcome of future collaborations between agile thinkers
who find complexity science applicable to software development.