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

Re: AW: [scrumdevelopment] Who has the last say?

Expand Messages
  • Bas Vodde
    Hi, Totally agree. It s the profession of software developers to develop good quality software. Bas
    Message 1 of 12 , Aug 1, 2007
      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
      >
      >
    • 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 2 of 12 , Aug 1, 2007
        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 3 of 12 , Aug 1, 2007
          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 4 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.