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

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

Expand Messages
  • Kurt Smith
    Aug 1, 2007
    • 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
      > >
      > >
      >
    • Show all 12 messages in this topic