Re: [scrumdevelopment] Re: Burn Up Charts
> Veering off topic a bit...sorry but I'm really in hurry today so I looked for a doc and I find this:
> Does Scrum really let you futz with quality? In XP quality is one of the
> knobs that gets turned up to "11" I believe. On the projects I work on
> we keep our list of known defects very low. The few bugs that we choose
> to tolerate are low impact and don't affect continuing development. How
> does a Scrum project tolerate less than pristine quality without getting
> bogged down?
my perspective fits that description.
I hope to have some spare time to answer you more extensively (and to Russ too).
Marco Abis - CEO & Chairman
Agility SPI: Software Process Improvement
abis@... - abis@...
> 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.