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

RE: [scrumdevelopment] Re: Impediment Reporting

Expand Messages
  • Jeff Oberlander
    It 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 1 of 66 , Oct 1 1:50 PM
      Message
      It 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
      To: scrumdevelopment@yahoogroups.com
      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. :-(

      Mark


      --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <jeffries@d...>
      wrote:
      > 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
      > www.XProgramming.com
      > 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@...



    • 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 5:55 AM
        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.