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

Re: [scrumdevelopment] Who has the last say?

Expand Messages
  • Kurt Smith
    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
    Message 1 of 12 , Aug 1, 2007
    View Source
    • 0 Attachment
      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:

      http://www.scrumalliance.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 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
      > >
      > >
      >
    • Ilja Preuss
      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
      Message 2 of 12 , Aug 1, 2007
      View Source
      • 0 Attachment
        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:
        >
        > http://www.scrumalliance.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 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: scrumdevelopment@...
        > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
        > Yahoo! Groups Links
        >
        >
        >
        >
      • 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 3 of 12 , Aug 2, 2007
        View Source
        • 0 Attachment
          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.