22773Re: [scrumdevelopment] Who has the last say?
- Aug 1, 2007Hi,
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
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 email@example.com, Bas Vodde <basv@...> wrote:
> Totally agree. It's the profession of software developers to
> good quality software.
> Heber Ferraz-Leite wrote:
> > This has been a while ago, as I'm cathing up on 700+ emails ...
> > still like to comment.
> > <<< Who's jurisdiction is the final say as to what is developed?
> > 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
> > deadline" into scrum. The PO is responsible for the stories
> > but not for the way they are implemented. How things are
> > implemented is a decision of the team.
> > The PO should say what exact functionality is expected, define
> > etc. ... And then it's the team's job to commit to something that
> > delivered with good quality. It's the scrummasters role to make
> > these rules are adhered to.
> > I don't think that the PO should have the option to say "I want
> > 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
> > because of bugfixing, poorer code maintenance, and loss of
> > your company.
> > If the POs requirements cannot be commited to within a certain
> > 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
> > call to reduce quality. The call the PO needs to make is to reduce
> > complexity, or choose not to reduce complexity and show less
> > at his demo ... With a roadmap for the implementation of the rest.
> > Regards,
> > Heber
- << Previous post in topic Next post in topic >>