Re: [scrumdevelopment] Impediment Reporting
>That's not my problem.I guess that goes to show that there are lots of different problems in the
It reminds me of Tolstoy's line about all happy families being happy in the
same way (because the same things have to go right), but unhappy families
each having a unique unhappiness (because there are so many different
things that can go wrong).
>I was not aware that Sprint Goals were absolute commitments. I'm still not.I suppose it all depends what you mean by absolute. The team must take
ultimate responsibility for the success of the sprint. However, it is
perfectly reasonable for the team to negotiate down from their estimates if
they prove to be unrealistic. I think that is built in to any agile
process, and is explicit in the Sprint Burndown.
But one of the prices for that flexibility is that you have to be straight
with your team and your product owner when things are in trouble. The
natural human instinct (at least in my neck of the woods) to sweep problems
under the rug is an enemy to the kind of trust and mutual respect we are
trying to build between the people with the money and the people with the
So if you find that happening, I don't think it is unreasonable to let the
team suffer with unacceptable overtime, keeping the hope that they will
self-organize into sustainability in reaction to this by developing the
courage to speak up when changing conditions make the original promises
impossible to sensibly deliver.
The price of the freedom and joy that Agilists seek in their work is
responsibility and discipline. And sometimes those values are painful
before we master them. Letting the team both suffer and enjoy the natural
consequences of their choices is part of the inherent power of Scrum (and
like approaches), and I think it is almost the duty of the Scrum Master to
let that happen, and point it out when it does.
- 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)