RE: [scrumdevelopment] Re: Impediment Reporting
MessageIt seems that this is saying that the only acceptable reason for not meeting the work in a sprint is because of an impediment, and it also seems an indirect message here that says that given no impediments, the team should be able to get everything done they said they would (team has to get approval from product owner to remove something) - but...what they said they would is purely an estimate. Agile is grounded on one of the principles that estimates are estimates and cannot truly be predicted right? So the description below, to me, does not sound agile at all. However, I think there is another underlying message here and that is how to keep a sense of urgency and commitment up.-----Original Message-----
From: woynam [mailto:woyna@...]
Sent: Friday, October 01, 2004 1:19 PM
Subject: [scrumdevelopment] Re: Impediment Reporting
The team has committed to delivering the features, provided that there
are no major impediments that aren't cleared in a reasonable amount of
time. If the impediments are identified, and they are not removed, the
team should not be held to the original feature set.
From another angle, features can be removed from a sprint with the
approval of the product owner provided that the team made a good faith
effort in upholding their end of the "contract". They should not be
forced to work extended hours through no fault of their own.
However, if the team violates one of the basic principles of Scrum,
openness and honesty, by withholding knowledge of major impediments,
then I see can see where they could be "penalized" by having to work
overtime to meet the sprint's goals.
Of course, in the perfect world this shouldn't happen. Unfortunately,
as some groups and individuals are exposed to Scrum, they may have a
hard time embracing the amount of openness necessary for Scrum to
work, or may be actively attempting to derail the process. :-(
--- In email@example.com, Ron Jeffries <jeffries@d...>
> On Friday, October 1, 2004, at 7:47:06 AM, Pete Bevin wrote:
> > The speech I give these days is "If you as a team sign up to these
> > backlog items, it means that come hell or high water, you have to
> > deliver them by the end of the sprint. So if there is anything
> > stopping you from doing that, you have to let people know sooner
> > rather than later, otherwise there are going to be some very late
> > nights four weeks from now."
> The above does not feel to me to be in the spirit of Scrum and Agile
> methods. Am I missing something?
> Ron Jeffries
> Scientists discover the world that exists;
> engineers create the world that never was.
> -- Theodore von Karman
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
- Ken's CSM course does cover Scrum pre-project steps - at different
levels of detail for different situations: New Unfunded Projects, New
Funded Projects, Ongoing Projects, Fixed Price/Fixed Date Projects. In
my copy of the methodology book, these are grouped under the title
"planning" which occurs before the first Sprint Planning meeting.
> On Thu, 07 Oct 2004 12:22:32 -0700, todd <todd@p...> wrote:lack
> > The lack of a pre-project phase in all the methodologies is major
> > in my mind.
> I would not say this is true of Jim Highsmith's APM. Do others agree
> or have a different view?
> This could be an interesting discussion thread in its own right. What
> do you do wtih the work before a project starts or is funded?
> Alistair Cockburn
> President, Humans and Technology
> Phone: 801.582-3162
> 1814 E. Fort Douglas Circle, Salt Lake City, UT 84103
> _mailto_ (http://mailto/) : acockburn@a...
> _http://alistair.cockburn.us/_ (http://alistair.cockburn.us/)
> Author of
> "Surviving Object-Oriented Projects" (1998)
> "Writing Effective Use Cases" (Jolt Productivity Award 2001)
> "Agile Software Development" (Jolt Productivity Award 2002)
> "La perfection est atteinte non quand il ne reste rien a ajouter,
> mais quand il ne reste rien a enlever." (Saint-Exupery)