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

Re: [scrumdevelopment] Who has the last say?

Expand Messages
  • 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 1 of 12 , Aug 1, 2007
    • 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 2 of 12 , Aug 2, 2007
      • 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.