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

RE: [scrumdevelopment] Who has the last say?

Expand Messages
  • Chris S. Sterling
    Good day, Not too long ago I had written a blog entry on debt in software in terms of design, platform experience, configuration management, quality, and
    Message 1 of 12 , Aug 2, 2007
      Good day,
       
      Not too long ago I had written a blog entry on debt in software in terms of design, platform experience, configuration management, quality, and technical.
       
       
      Chris Sterling
      Agile Coach / Certified Scrum Trainer
       
      Experience is easy to provide and quickly put to good use by people with all the other qualities." - Dee Hock
       


      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ilja Preuss
      Sent: Wednesday, August 01, 2007 10:22 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Who has the last say?

      Yes, I like the concept.

      Another great explanation of what happens when you compromise quality
      for the sake of speed can be found in Ken's google talk. To find it, go
      to google video, search vor "Ken Schwaber" and start with minute 40.
      (The rest of the video is quite good, too, of course.)

      Cheers, Ilja

      Kurt Smith wrote:

      > Hi,
      >
      > I agree as well. I've been in several discussion concerning quality
      > and unrealistic expectations to deliver ahead of the "ideal"
      >
      velocity. When presented with such cases I always refer back
      > to "Code
      Debt". If you are unaware please reference the following
      > URL:
      >
      >
      href="http://www.scrumalliance.org/articles/14-technical-debt-and-design-">http://www.scrumall iance.org/ articles/ 14-technical- debt-and- design-
      >
      death
      >
      > I would like to know what you all feel about this
      concept. It's
      > truly opened a new perpective for me and a new way to
      communicate to
      > business users the results of their decisions. In the
      end the
      > business typically wants a "quality" product and when explained
      in
      > terms they understand such as "debt" it becomes to hit home.
      >
      > --- In
      href="mailto:scrumdevelopment%40yahoogroups.com">scrumdevelopment@ yahoogroups. com, Bas Vodde <basv@...> wrote:
      >>
      >>
      Hi,
      >>
      >> Totally agree. It's the profession of software
      developers to
      > develop
      >> good quality
      software.
      >>
      >> Bas
      >>
      >> Heber Ferraz-Leite
      wrote:
      >>>
      >>> This has been a while ago, as I'm cathing
      up on 700+ emails ...
      > But I'd
      >>> still like to
      comment.
      >>>
      >>> <<< Who's jurisdiction is the
      final say as to what is developed?
      > Surely
      >>> the team
      cannot decline Option A for the perceived quality that
      >>> Option B
      will provide as it will lose the company business.
      >>>
      >>>
      >>> Everybody seems to have named the
      PO ... But I think it is
      > dangerous to put
      >>> it that way,
      as it may bring the thinking of "cut quality to meet
      >
      the
      >>> deadline" into scrum. The PO is responsible for the stories
      > implemented,
      >>> but not for the way they are implemented.
      How things are
      > technically
      >>> implemented is a decision of
      the team.
      >>>
      >>> The PO should say what exact
      functionality is expected, define
      > priorities,
      >>> etc. ...
      And then it's the team's job to commit to something that
      > can
      be
      >>> delivered with good quality. It's the scrummasters role to
      make
      > sure that
      >>> these rules are adhered
      to.
      >>>
      >>> I don't think that the PO should have the
      option to say "I want
      > it delivered
      >>> with poorer
      quality", because the customer that the PO is
      > delivering to
      will
      >>> certainly not expect poorer quality. Reducing quality may
      help
      > you make a
      >>> short term presentation, but in the
      long term it will create more
      > costs
      >>> because of
      bugfixing, poorer code maintenance, and loss of
      > reputation
      for
      >>> your company.
      >>>
      >>> If the POs
      requirements cannot be commited to within a certain
      >
      timeframe,
      >>> it's the PO's job to reduce the requirements (or
      simplify them)
      > so that they
      >>> can be met, and outline a
      roadmap for the rest.
      >>>
      >>> So ... It's the PO's call
      what will be implemented ... But it's
      > not anyone's
      >>> call
      to reduce quality. The call the PO needs to make is to reduce
      >>>
      complexity, or choose not to reduce complexity and show less
      >
      functionality
      >>> at his demo ... With a roadmap for the
      implementation of the rest.
      >>>
      >>>
      Regards,
      >>>
      >>>
      Heber
      >>>
      >>>
      >
      >
      >
      >
      > To Post a message, send it to:
      href="mailto:scrumdevelopment%40eGroups.com">scrumdevelopment@ eGroups.com
      >
      To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.com
      > Yahoo! Groups Links
      >
      >
      >
      >

    Your message has been successfully submitted and would be delivered to recipients shortly.