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

Re: Technology Decisions, The Team and the PO

Expand Messages
  • Paul Oldfield
    (responding to Aldo) ... It is always wise to ask oneself, when making any technology decision, Is the choice totally invisible to the Customer? . The degree
    Message 1 of 9 , Aug 1, 2007
    • 0 Attachment
      (responding to Aldo)

      > ... the team decided to switch technology versions
      > without letting the product owner know. The reason they
      > took this decision to switch is because i had told them that
      > technology decisions are in the hands of the team, and ...

      It is always wise to ask oneself, when making any
      technology decision, "Is the choice totally invisible to
      the Customer?". The degree of impact on the Customer
      tells you whether the Customer should be informed or
      consulted when the decision needs to be made.

      It is true that the team are best placed to make design
      and technology decisions, and should continue to do so.
      However, they are best placed because they are in touch
      with all the stakeholders in those decisions. By leaving
      the Customer out of the process you are in effect cutting
      out one of the potential stakeholders.

      Paul Oldfield
      Capgemini
    • 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 2 of 9 , Aug 1, 2007
      • 0 Attachment
        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 3 of 9 , Aug 1, 2007
        • 0 Attachment
          > 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 4 of 9 , Aug 1, 2007
          • 0 Attachment
            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 5 of 9 , Aug 1, 2007
            • 0 Attachment
              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 6 of 9 , Aug 1, 2007
              • 0 Attachment
                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 7 of 9 , Aug 2, 2007
                • 0 Attachment
                  >> 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 8 of 9 , Aug 2, 2007
                  • 0 Attachment
                    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.