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

Who has the last say?

Expand Messages
  • bennyou.cpt1
    Hi all, I would like to gather some thoughts on the following scenario. Mr. Product Owner has a specific need that he wants the team to fulfill, given a very
    Message 1 of 12 , Jun 14, 2007
    • 0 Attachment
      Hi all,

      I would like to gather some thoughts on the following scenario.

      Mr. Product Owner has a specific need that he wants the team to
      fulfill, given a very strict time frame in order to service business
      strategies and goals. For example one of our existing systems may be
      able to solve a customers needs given one or two tweaks to the said
      system (the solution needed uses common functionality of the existing
      system), however the customer has given a specific deadline for a
      demonstartion, should this deadline not be met another company will
      demo and win the tender, which is not favourable to our business as
      this is loss of revenue.

      Mr Architect then kicks up a big fuss saying that the tweaks will
      compromise the integrity and principal of which the original system
      was designed, and says that the system needs to be relooked at and
      reworked to fit the new business need. However such a change will
      take more time than is allowed by the customers deadline.

      Given this particular situation the team presents two solutions:
      Option A: The tweaks to the system, which can be developed with
      potential shippable code, which is predicted to be done within the
      restricted timeframe

      Option B: A rearchitected system fulfilling technical needs, however
      given the current velocity of the team, there is a large degree of
      certainity that the dealine will be missed.

      Mr Product Owner has been presented with the two caseses and is aware
      that system integrity may be compromised, however believes that
      Option A will bring more value to the business than Option B, however
      Mr Architect is persistant that we tackle Option B. The team is
      indifferent as to which solution is developed.

      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.

      IMHO it seems that the Product Owner's should have discretion to take
      on the solution as it best suits the current business needs.

      What are the communities thoughts on this particular scenario?
    • David H.
      ... The Product Owner - Full Stop. ... -- Sent from gmail so do not trust this communication. Do not send me sensitive information here, ask for my none-gmail
      Message 2 of 12 , Jun 14, 2007
      • 0 Attachment
        >
        > What are the communities thoughts on this particular scenario?

        The Product Owner - Full Stop.


        :)

        --
        Sent from gmail so do not trust this communication.
        Do not send me sensitive information here, ask for my none-gmail accounts.

        "Therefore the considerations of the intelligent always include both
        benefit and harm." - Sun Tzu
      • Michael Vizdos
        Hi, The clean answer is: Product Owner. That being said, reality sets in and you have to make sure that the architect and Mr. Product Owner are talking about
        Message 3 of 12 , Jun 14, 2007
        • 0 Attachment
          Hi,

          The "clean" answer is: Product Owner.

          That being said, reality sets in and you have to make sure that the architect and Mr. Product Owner are talking about this (sounds like they are).

          I have seen many systems with incredible architects that did not sell.

          Keep things in perspective so you have jobs and systems to continue working on and selling (smile).

          - mike vizdos
            www.implementingscrum.com
            www.michaelvizdos.com



          On 6/14/07, bennyou.cpt1 <bennyou.cpt@...> wrote:

          Hi all,

          I would like to gather some thoughts on the following scenario.

          Mr. Product Owner has a specific need that he wants the team to
          fulfill, given a very strict time frame in order to service business
          strategies and goals. For example one of our existing systems may be
          able to solve a customers needs given one or two tweaks to the said
          system (the solution needed uses common functionality of the existing
          system), however the customer has given a specific deadline for a
          demonstartion, should this deadline not be met another company will
          demo and win the tender, which is not favourable to our business as
          this is loss of revenue.

          Mr Architect then kicks up a big fuss saying that the tweaks will
          compromise the integrity and principal of which the original system
          was designed, and says that the system needs to be relooked at and
          reworked to fit the new business need. However such a change will
          take more time than is allowed by the customers deadline.

          Given this particular situation the team presents two solutions:
          Option A: The tweaks to the system, which can be developed with
          potential shippable code, which is predicted to be done within the
          restricted timeframe

          Option B: A rearchitected system fulfilling technical needs, however
          given the current velocity of the team, there is a large degree of
          certainity that the dealine will be missed.

          Mr Product Owner has been presented with the two caseses and is aware
          that system integrity may be compromised, however believes that
          Option A will bring more value to the business than Option B, however
          Mr Architect is persistant that we tackle Option B. The team is
          indifferent as to which solution is developed.

          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.

          IMHO it seems that the Product Owner's should have discretion to take
          on the solution as it best suits the current business needs.

          What are the communities thoughts on this particular scenario?


        • Robert Hanson
          Deliver what the Product Owner wants. Add in the features, even if it compromises the architecture. This will produce a code base that has some technical
          Message 4 of 12 , Jun 14, 2007
          • 0 Attachment

            Deliver what the Product Owner wants.  Add in the features, even if it compromises the architecture.  This will produce a code base that has some technical debt.  If the customer does not buy, then revert back to the original codebase.  If the customer does buy, add a story to the product backlog to rearchitect to remove the technical debt. 

             

            Having money in the bank will make it easier to convince the PO that removing the technical debt incurred by the addition of the new features is worthwhile.

          • Brent Barton
            In a disagreement, the Product Owner wins. I believe the architect has the responsibility to help ensure this does not start turning the system into a Big
            Message 5 of 12 , Jun 14, 2007
            • 0 Attachment
              In a disagreement, the Product Owner wins. 
               
              I believe the architect has the responsibility to help ensure this does not start turning the system into a "Big Ball of Mud," though.  Make it work, refactor mercilessly after the deadline and prove that the architecture is updatable and maintainable.  The Product Owner can probably be persuaded to do this after the business "win" has resulted in additional revenue. 
               
              I hope you have a full suite of tests and continuous integration.  If not, add that to the backlog too. :-)
               
              Good luck!
               
              Brent


              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of bennyou.cpt1
              Sent: Thursday, June 14, 2007 6:01 AM
              To: scrumdevelopment@yahoogroups.com
              Subject: [scrumdevelopment] Who has the last say?

              Hi all,

              I would like to gather some thoughts on the following scenario.

              Mr. Product Owner has a specific need that he wants the team to
              fulfill, given a very strict time frame in order to service business
              strategies and goals. For example one of our existing systems may be
              able to solve a customers needs given one or two tweaks to the said
              system (the solution needed uses common functionality of the existing
              system), however the customer has given a specific deadline for a
              demonstartion, should this deadline not be met another company will
              demo and win the tender, which is not favourable to our business as
              this is loss of revenue.

              Mr Architect then kicks up a big fuss saying that the tweaks will
              compromise the integrity and principal of which the original system
              was designed, and says that the system needs to be relooked at and
              reworked to fit the new business need. However such a change will
              take more time than is allowed by the customers deadline.

              Given this particular situation the team presents two solutions:
              Option A: The tweaks to the system, which can be developed with
              potential shippable code, which is predicted to be done within the
              restricted timeframe

              Option B: A rearchitected system fulfilling technical needs, however
              given the current velocity of the team, there is a large degree of
              certainity that the dealine will be missed.

              Mr Product Owner has been presented with the two caseses and is aware
              that system integrity may be compromised, however believes that
              Option A will bring more value to the business than Option B, however
              Mr Architect is persistant that we tackle Option B. The team is
              indifferent as to which solution is developed.

              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.

              IMHO it seems that the Product Owner's should have discretion to take
              on the solution as it best suits the current business needs.

              What are the communities thoughts on this particular scenario?

            • Ilja Preuss
              Work on finding Option C, the integrated solution. For example, do a quick and dirty implementation on a branch for the demo. Then throw it away and
              Message 6 of 12 , Jun 16, 2007
              • 0 Attachment
                Work on finding Option C, the integrated solution.

                For example, do a quick and dirty implementation on a branch for the
                demo. Then throw it away and reimplement it more cleanly, if you get the
                deal.

                That's just an example, which might not fit your needs. The point is
                that its better to collaborate on finding a creative solution, than to
                fight over which suboptimal obvious solution to use.

                This reminds me of something that happened in our team this week: we
                have to develop a complex converter for XML files.

                We saw the options of using XSL-T or using Java on a DOM tree. It wasn't
                clear which would be better, so (after some heated discussions) the pair
                started to implement both in parallel, following the lean principle of
                set based decision making. After some time they found out that they
                didn't even have to decide - the architecture that emerged allowed both
                approaches to be used in concert. We were all quite delighted.

                Hope this helps,

                Ilja

                bennyou.cpt1 wrote:
                > Hi all,
                >
                > I would like to gather some thoughts on the following scenario.
                >
                > Mr. Product Owner has a specific need that he wants the team to
                > fulfill, given a very strict time frame in order to service business
                > strategies and goals. For example one of our existing systems may be
                > able to solve a customers needs given one or two tweaks to the said
                > system (the solution needed uses common functionality of the existing
                > system), however the customer has given a specific deadline for a
                > demonstartion, should this deadline not be met another company will
                > demo and win the tender, which is not favourable to our business as
                > this is loss of revenue.
                >
                > Mr Architect then kicks up a big fuss saying that the tweaks will
                > compromise the integrity and principal of which the original system
                > was designed, and says that the system needs to be relooked at and
                > reworked to fit the new business need. However such a change will
                > take more time than is allowed by the customers deadline.
                >
                > Given this particular situation the team presents two solutions:
                > Option A: The tweaks to the system, which can be developed with
                > potential shippable code, which is predicted to be done within the
                > restricted timeframe
                >
                > Option B: A rearchitected system fulfilling technical needs, however
                > given the current velocity of the team, there is a large degree of
                > certainity that the dealine will be missed.
                >
                > Mr Product Owner has been presented with the two caseses and is aware
                > that system integrity may be compromised, however believes that
                > Option A will bring more value to the business than Option B, however
                > Mr Architect is persistant that we tackle Option B. The team is
                > indifferent as to which solution is developed.
                >
                > 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.
                >
                > IMHO it seems that the Product Owner's should have discretion to take
                > on the solution as it best suits the current business needs.
                >
                > What are the communities thoughts on this particular scenario?
                >
                >
                >
                >
                > To Post a message, send it to: scrumdevelopment@...
                > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                > Yahoo! Groups Links
                >
                >
                >
                >
              • bennyou.cpt1
                Thanks for the reply. In the end we actually worked out Option C and agreed that we would probably write the better solutution. But there was some difficulty
                Message 7 of 12 , Jun 18, 2007
                • 0 Attachment
                  Thanks for the reply.

                  In the end we actually worked out Option C and agreed that we would
                  probably write the better solutution. But there was some difficulty
                  getting to that point becuase the Architect was afraid that we would
                  keep postponing the technical debt, and fall into the vicous cycle of
                  attending more "urgent" stories.

                  But in the end there has been some consensus that rework will have to
                  be done once we have more revenue.



                  --- In scrumdevelopment@yahoogroups.com, Ilja Preuss <it@...> wrote:
                  >
                  > Work on finding Option C, the integrated solution.
                  >
                  > For example, do a quick and dirty implementation on a branch for
                  the
                  > demo. Then throw it away and reimplement it more cleanly, if you
                  get the
                  > deal.
                  >
                  > That's just an example, which might not fit your needs. The point
                  is
                  > that its better to collaborate on finding a creative solution, than
                  to
                  > fight over which suboptimal obvious solution to use.
                  >
                  > This reminds me of something that happened in our team this week:
                  we
                  > have to develop a complex converter for XML files.
                  >
                  > We saw the options of using XSL-T or using Java on a DOM tree. It
                  wasn't
                  > clear which would be better, so (after some heated discussions) the
                  pair
                  > started to implement both in parallel, following the lean principle
                  of
                  > set based decision making. After some time they found out that they
                  > didn't even have to decide - the architecture that emerged allowed
                  both
                  > approaches to be used in concert. We were all quite delighted.
                  >
                  > Hope this helps,
                  >
                  > Ilja
                  >
                  > bennyou.cpt1 wrote:
                  > > Hi all,
                  > >
                  > > I would like to gather some thoughts on the following scenario.
                  > >
                  > > Mr. Product Owner has a specific need that he wants the team to
                  > > fulfill, given a very strict time frame in order to service
                  business
                  > > strategies and goals. For example one of our existing systems may
                  be
                  > > able to solve a customers needs given one or two tweaks to the
                  said
                  > > system (the solution needed uses common functionality of the
                  existing
                  > > system), however the customer has given a specific deadline for a
                  > > demonstartion, should this deadline not be met another company
                  will
                  > > demo and win the tender, which is not favourable to our business
                  as
                  > > this is loss of revenue.
                  > >
                  > > Mr Architect then kicks up a big fuss saying that the tweaks will
                  > > compromise the integrity and principal of which the original
                  system
                  > > was designed, and says that the system needs to be relooked at
                  and
                  > > reworked to fit the new business need. However such a change will
                  > > take more time than is allowed by the customers deadline.
                  > >
                  > > Given this particular situation the team presents two solutions:
                  > > Option A: The tweaks to the system, which can be developed with
                  > > potential shippable code, which is predicted to be done within
                  the
                  > > restricted timeframe
                  > >
                  > > Option B: A rearchitected system fulfilling technical needs,
                  however
                  > > given the current velocity of the team, there is a large degree
                  of
                  > > certainity that the dealine will be missed.
                  > >
                  > > Mr Product Owner has been presented with the two caseses and is
                  aware
                  > > that system integrity may be compromised, however believes that
                  > > Option A will bring more value to the business than Option B,
                  however
                  > > Mr Architect is persistant that we tackle Option B. The team is
                  > > indifferent as to which solution is developed.
                  > >
                  > > 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.
                  > >
                  > > IMHO it seems that the Product Owner's should have discretion to
                  take
                  > > on the solution as it best suits the current business needs.
                  > >
                  > > What are the communities thoughts on this particular scenario?
                  > >
                  > >
                  > >
                  > >
                  > > To Post a message, send it to: scrumdevelopment@...
                  > > To Unsubscribe, send a blank message to: scrumdevelopment-
                  unsubscribe@...
                  > > Yahoo! Groups Links
                  > >
                  > >
                  > >
                  > >
                  >
                • Heber Ferraz-Leite
                  This has been a while ago, as I m cathing up on 700+ emails ... But I d still like to comment.
                  Message 8 of 12 , Aug 1, 2007
                  • 0 Attachment
                    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
                  • Bas Vodde
                    Hi, Totally agree. It s the profession of software developers to develop good quality software. Bas
                    Message 9 of 12 , Aug 1, 2007
                    • 0 Attachment
                      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 10 of 12 , 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
                        > >
                        > >
                        >
                      • 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 11 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 12 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.