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

Re:Technology Decisions, The Team and the PO

Expand Messages
  • David A Barrett
    If a technology decision is not going to affect the schedule, limit what can be done in the future, change the cost of the project or have some other negative
    Message 1 of 9 , Aug 1, 2007
      If a technology decision is not going to affect the schedule, limit what
      can be done in the future, change the cost of the project or have some
      other negative impact , then it falls to the developers to decide.

      In reality, though, the majority of non-trivial technical decisions aren't
      transparent to everyone who isn't a developer. For those decisions, a
      business case usually has to be made and the Product Owner has to be
      convinced that it is the right decision. If the technical issue is going
      to take a significant amount of time to build and implement, then it needs
      to go into the Product Backlog, just like any other feature or task.

      It really becomes a matter of the developers losing the feeling that they
      "own" the software because they built it. If they feel really strongly
      about an issue, then they need to convince the PO that they're right. If
      they can't do so, then they have to drop it. Even really technical things
      need to have a real business reason to do them.


      Dave Barrett,
      Lawyers' Professional Indemnity Company
    • David H.
      ... Just out of curiosity, why? How did you come to that conclusion? If you spend my money to build a car and there is a choice between a rotary engine and
      Message 2 of 9 , Aug 1, 2007
        > If a technology decision is not going to affect the schedule, limit what
        > can be done in the future, change the cost of the project or have some
        > other negative impact , then it falls to the developers to decide.
        >
        Just out of curiosity, why? How did you come to that conclusion? If
        you spend my money to build a car and there is a choice between a
        rotary engine and piston type engine, both the same cost, same power
        etc... I as business, still need to understand what that means to me
        as a business and _why_ you made that choice. For marketing reasons
        alone, since software is a technology and often technology is driving
        acceptance in the market.

        For example, in a large scale organisation the word JAVA gets you nods
        and murmur while RUBY will get you shuddering head shaking.

        So while I agree with your approach I cannot agree to the overal
        sentiment. Those decisions, in my opinion, always need the input of
        the product owner, if not their decision. It is the duty of the team
        or scrum master to make sure the Product Owner can understand why he
        needs to make that decision.

        -d

        --
        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
      • Roy Morien
        Wouldn t this come down to the impact or affect that the development technology will have? Perhaps the client is totally disinterested in the technology of
        Message 3 of 9 , Aug 1, 2007
          Wouldn't this come down to the impact or affect that the development technology will have? Perhaps the client is totally disinterested in the technology of development, therefore the developers can choose whatever development technology they want ...Java, RUBY ... doesn't matter ... BUT only once they have discussed it with the client and ascertained how indifferent the client is to the underlying development technology.
           
          Perhaps this is a new system that must fit in with the existing architecture of the client's current systems. In this case, it is certainly not the decision of the developers to adopt whatever pleases them. But of course it is the responsibility of the Project leader, being the chief technical consultant, to find out about these things before the project gets underway. It is his responsibility to choose the appropriate development technology, taking into account all the necessary facts of the matter, which will include the impact on productivity that the dev.tech has (if perhaps it is a new environment to the team), the training needs of the team members, the level of competence and experience that the team has with this particular environment etc etc etc.
           
          Either way, it is surely just a politically wise thing ... at the very least ... to ensure that the client is aware of these issues, and has the opportunity to express his indifference or interest. After all, he is surely part of the 'team', and collaboration is a keystone of agile development activities. "No Surprises" is a quick and useful motto.
           
          Roy Morien





          To: scrumdevelopment@yahoogroups.com
          From: dmalloc@...
          Date: Wed, 1 Aug 2007 15:33:35 +0100
          Subject: Re: [scrumdevelopment] Re:Technology Decisions, The Team and the PO

          > If a technology decision is not going to affect the schedule, limit what
          > can be done in the future, change the cost of the project or have some
          > other negative impact , then it falls to the developers to decide.
          >
          Just out of curiosity, why? How did you come to that conclusion? If
          you spend my money to build a car and there is a choice between a
          rotary engine and piston type engine, both the same cost, same power
          etc... I as business, still need to understand what that means to me
          as a business and _why_ you made that choice. For marketing reasons
          alone, since software is a technology and often technology is driving
          acceptance in the market.

          For example, in a large scale organisation the word JAVA gets you nods
          and murmur while RUBY will get you shuddering head shaking.

          So while I agree with your approach I cannot agree to the overal
          sentiment. Those decisions, in my opinion, always need the input of
          the product owner, if not their decision. It is the duty of the team
          or scrum master to make sure the Product Owner can understand why he
          needs to make that decision.

          -d

          --
          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



          Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it!
        • aldoc_uniblue
          thanks all for your replies. it seems that the general idea is that the PO needs to be in the loop when a decision is made. What about how and when a decision
          Message 4 of 9 , Aug 1, 2007
            thanks all for your replies. it seems that the general idea is that
            the PO needs to be in the loop when a decision is made.

            What about how and when a decision is made? Do your teams usually have
            set times when they can investigate new technologies, you have a
            senior member with time allocated to research new tech or you place an
            allowance within every sprint for the team to 'catch up' on new tech.
            and investigate new technologies?

            cheers
            aldo
          • Roy Morien
            My view would be that checking out new technology, selecting it, training people in its use etc. is not part of any specific project, so where it fits in
            Message 5 of 9 , Aug 1, 2007
              My view would be that checking out new technology, selecting it, training people in its use etc. is not part of any specific project, so where it fits in sprints is just not a question that needs to be debated. A project team should have its portfolio of tools, languages, object libraries, data dictionary, document standards, code standards etc etc ... ie: all of the infrastructure necessary to undertake development activities competently and efficiently ... all ready, willing and able to go before any project starts.
               
              Alternatively, if it is an essential and inherent part of a new project to decide on new technologies and tools specifically for that project, then the overhead of selecting, training and implementing the new technology (as well as an 'inefficiency allowance' necessitated by the fact that the team members just are not up to speed on this new technology) must be allocated to sprints as appropriate ... first and early sprints may be mostly learning and familiarisation activities, and the clear expectation that 'learning on the job' plus other training is necessary, will be built into the sprints. This overhead will diminish as time goes on and team members become more competent and efficient in the use of the tools. I think the idea that Scrum has a built-in concept of the project 'velocity' actually encompasses this ... the velocity will increase over sprints as a result of the education, learning and experience gained by the team members.





              To: scrumdevelopment@yahoogroups.com
              From: aldoc@...
              Date: Wed, 1 Aug 2007 15:15:37 +0000
              Subject: [scrumdevelopment] Re:Technology Decisions, The Team and the PO

              thanks all for your replies. it seems that the general idea is that
              the PO needs to be in the loop when a decision is made.

              What about how and when a decision is made? Do your teams usually have
              set times when they can investigate new technologies, you have a
              senior member with time allocated to research new tech or you place an
              allowance within every sprint for the team to 'catch up' on new tech.
              and investigate new technologies?

              cheers
              aldo




              Connect to the next generation of MSN Messenger  Get it now!
            • David A Barrett
              ... Well, there is a certain point at which the PO simply won t care what the decision is. Nested IF s or a CASE statement? , maybe even Ruby or Java? .
              Message 6 of 9 , Aug 2, 2007
                >> If a technology decision is not going to affect the schedule, limit what
                >> can be done in the future, change the cost of the project or have some
                >> other negative impact , then it falls to the developers to decide.
                >>
                >Just out of curiosity, why? How did you come to that conclusion?

                Well, there is a certain point at which the PO simply won't care what the
                decision is. "Nested IF's or a CASE statement?", maybe even "Ruby or
                Java?".

                What IS going to cause a problem is having to tell the the PO sometime down
                the road that you can't do something in a reasonable amount of time because
                you chose to use Ruby instead of Java back at the beginning of the project.

                There's probably a fairly large number of issues where there are company
                (or IT department) policies which dictate the choices, or where the PO is
                willing to simply trust that the developers will make the best choice.
                These are probably cases where the PO's main contribution to the decision
                making process would be to clarify outside criteria so that the developers
                have all of the information that the need to make an informed decision.

                Dave Barrett,
                Lawyers' Professional Indemnity Company
              • Roy Morien
                A project that is about to be commenced with a new development technology that the team members are unfamiliar with, do not have competence in and good
                Message 7 of 9 , Aug 2, 2007
                  A project that is about to be commenced with a new development technology that the team members are unfamiliar with, do not have competence in and good knowledge of, has a substantially increased risk inherent in this situation. If that high risk is known and understood, by all, including the PO, and cost and time estimates are struck to acknowledge that higher risk, and the potential for lower productivity by the team, then there should be no problem about using that technology. The 'experimental' and 'exploratory' nature of the project, imposed by the use of new development technology must be acknowledged, BY ALL STAKEHOLDERS.
                   
                  However, in my view, that risk is too high. A development team should have in place already, prior to commencing a project, their portfolio of development tools, standards, code libraries, testing regime, backup and archiving practices etc etc etc.
                   
                  So the possibility of hitting a wall somewhere downstream in the project, as David has rightly pointed out, should either not be a possibility, or has been accepted as a known risk beforehand.
                   
                  But at all times, in any or either situation, ALL STAKEHOLDERS should be fully informed ... that is the fundamental nature of the 'collaborative' environment implied in all agile methods.
                   
                  Regards,
                  Roy Morien  





                  To: scrumdevelopment@yahoogroups.com
                  From: dave.barrett@...
                  Date: Thu, 2 Aug 2007 10:16:00 -0400
                  Subject: [scrumdevelopment] Re: Technology Decisions, The Team and the PO


                  >> If a technology decision is not going to affect the schedule, limit what
                  >> can be done in the future, change the cost of the project or have some
                  >> other negative impact , then it falls to the developers to decide.
                  >>
                  >Just out of curiosity, why? How did you come to that conclusion?

                  Well, there is a certain point at which the PO simply won't care what the
                  decision is. "Nested IF's or a CASE statement?", maybe even "Ruby or
                  Java?".

                  What IS going to cause a problem is having to tell the the PO sometime down
                  the road that you can't do something in a reasonable amount of time because
                  you chose to use Ruby instead of Java back at the beginning of the project.

                  There's probably a fairly large number of issues where there are company
                  (or IT department) policies which dictate the choices, or where the PO is
                  willing to simply trust that the developers will make the best choice.
                  These are probably cases where the PO's main contribution to the decision
                  making process would be to clarify outside criteria so that the developers
                  have all of the information that the need to make an informed decision.

                  Dave Barrett,
                  Lawyers' Professional Indemnity Company




                  Connect to the next generation of MSN Messenger  Get it now!
                Your message has been successfully submitted and would be delivered to recipients shortly.