RE: [scrumdevelopment] Impediment Reporting
- I doubt that forcing anything is ever good. (Including when my mom forced me
to eat vegetables.)
Making and meeting commitments is valuable and--within reason--it is good
for a team to meet a commitment they make. A simple example:
Team A--finishes a two-week sprint and delivers all planned work but
collectively decided to hang out late two nights and work through lunch once
(the company bought pizzas for all). They worked 40 hours the first week
then 43 the next.
Team B--Does the same two-week sprint but misses the committed work (whether
you define this by sprint goal or sprint priority). They could have finished
with the same 3 hours of extra effort of Team A but valued their
"sustainable pace" too much to do it.
I will take Team A over Team B every time. I will make sure that Team A
"gets back" that 3 hours in some way in some manner. Team A will feel a
greater pride because they met a goal *that they set*. Team B can be a great
team; Team A will be better. In their great book, Teamwork, Larson and
Lafasto identify 8 things common among truly great teams. One is a "unified
commitment." They talk about the extra energy (mental & physical) exhibited
by teams with a unified commitment. I won't bother saying more; I suspect we
all know this is true.
Yes, I want teams to work at a sustainable pace. But consider this analogy.
Suppose I want to run a 10k at a 8:00/mile pace. My training will consist of
training faster than and slower than that pace. I may run 15k at 9:00/mile
and 8k at 7:30. The faster tempo running will make the 8:00 pace feel easy.
In my opinion a big part of "sustainable pace" means NOT working 40 hours a
week. Sometimes it means 35, sometimes it means 45. Variety is important.
When we do a 45 hour week, the 40 next week is easy and we do more in that
40 hours than we used to--just like the 7:30 pace run made the 8:00 pace
easier. There's no specific pattern but IMO sustainable pace includes
variety both above and below 40/week. The best judge of what's too much is
the team. By the way, I spend far more time telling developers "go home"
than ever dropping hints that they need to work more. (I never say "stay
longer" unless it's an isolated employee who is taking advantage and is
probably about to be booted).
What do others think about sustainable pace implying variety?
Author of User Stories Applied for Agile Software Development
From: Ron Jeffries [mailto:jeffries@...]
Sent: Saturday, October 02, 2004 5:31 AM
Subject: Re: [scrumdevelopment] Impediment Reporting
On Saturday, October 2, 2004, at 12:21:55 AM, Dion Stewart wrote:
> Forcing people to work overtime doesn't change their behavior.
Nor does it get more work done, or better work done. Quite the contrary in
Keep away from people who try to belittle your ambitions. Small people
always do that, but the really great make you feel that you, too, can
become great." -- Mark Twain.
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
Yahoo! Groups Links
- 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)