Loading ...
Sorry, an error occurred while loading the content.

RE: [scrumdevelopment] Impediment Reporting

Expand Messages
  • Mike Cohn
    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
    Message 1 of 66 , Oct 2, 2004
    View Source
    • 0 Attachment
      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?

      --Mike Cohn
      Author of User Stories Applied for Agile Software Development
      www.mountaingoatsoftware.com
      www.userstories.com

      -----Original Message-----
      From: Ron Jeffries [mailto:jeffries@...]
      Sent: Saturday, October 02, 2004 5:31 AM
      To: scrumdevelopment@yahoogroups.com
      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
      most cases.

      Ron Jeffries
      www.XProgramming.com
      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:
      scrumdevelopment-unsubscribe@...
      Yahoo! Groups Links
    • Deb
      Ken s CSM course does cover Scrum pre-project steps - at different levels of detail for different situations: New Unfunded Projects, New Funded Projects,
      Message 66 of 66 , Oct 9, 2004
      View Source
      • 0 Attachment
        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:
        >
        > > The lack of a pre-project phase in all the methodologies is major
        lack
        > > 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)
        > ==============================================
      Your message has been successfully submitted and would be delivered to recipients shortly.