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

Technology Decisions, The Team and the PO

Expand Messages
  • aldoc_uniblue
    Hi, A small issue arose in the past retrospective when the team decided to switch technology versions without letting the product owner know. The reason they
    Message 1 of 9 , Jul 31 11:51 PM
    • 0 Attachment
      Hi,

      A small issue arose in the past retrospective when 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 they felt
      that if they did not switch now, before the product was released, the
      server administrators would not allow them to switch in the future.

      This has cause delays in the release of the product as the site now
      has to be re-tested with the new technology, and there are some small
      issues with the IDE.

      My reaction was that while the decision to move to the new technology
      should be in the hands of the team, if that decision affects the
      release plan, it should be passed by the product owner. Also, the work
      within the sprint should be focused on accomplishing the sprint goals
      or generating as much business value as possible and so, the time to
      perform the necessary changes or to research the technology should
      have either been in a story or in a 'research' sprint at the end of a
      release.

      The Product Owner was happy with this suggestion, but the team was not
      and so my question is, was my initial reaction correct? And what would
      you recommend as an alternative way to tackle this issue?

      thanks
      Aldo
    • 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 2 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 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.

          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 4 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 5 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 6 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 7 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 8 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 9 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.