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

22777RE: [scrumdevelopment] Re:Technology Decisions, The Team and the PO

Expand Messages
  • Roy Morien
    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!
    • Show all 9 messages in this topic