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

Agile for Run-of-the-Mill Software Upgrade

Expand Messages
  • Gannon, Terry
    We have an accounting software upgrade coming up. We re having considerable success with Agile/Scrum managing both development and implementation project, and
    Message 1 of 3 , May 3, 2005
    • 0 Attachment
      Message
      We have an accounting software upgrade coming up.  We're having considerable success with Agile/Scrum managing both development and implementation project, and we're considering the extension of it's use to cover this upgrade.
       
      I was curious to know if anybody has any experience in this area, particularly when it comes to expressing the business value of said upgrade.  It looks like purely non-functional requirement type stuff, which theoretically means you need to marry to a functional requirement in order to justify the value of the ugrade to the business.  Any thoughts you have in this regard would be much appreciated.
       
      Thanx!
       
      Terence Gannon
      Manager, Software Development
      Trican Well Service Ltd.
      Calgary, Alberta
    • William Wake
      ... Terry - While it might be easier to explain a new feature to a typical end-user, the business can certainly value non-functional benefits. I wouldn t feel
      Message 2 of 3 , May 3, 2005
      • 0 Attachment
        On 5/3/05, Gannon, Terry <tcgannon@...> wrote:
        > I was curious to know if anybody has any experience in this area,
        > particularly when it comes to expressing the business value of said upgrade.
        > It looks like purely non-functional requirement type stuff, which
        > theoretically means you need to marry to a functional requirement in order
        > to justify the value of the ugrade to the business.

        Terry -

        While it might be easier to explain a new feature to a typical
        end-user, the business can certainly value non-functional benefits. I
        wouldn't feel I had to "marry" them if the business as a whole is
        comfortable otherwise.

        For example:
        - performance improvements - (ok, users like these too:)
        - stability improvements -> less down-time
        - staying near current release -> better vendor support (you don't get
        told to first upgrade every time you hit a bug)
        - architectural improvements e.g., redundancy may lower risk of down-time
        - re-structuring -> may make future requirements cheaper to implement
        - security improvements -> less risk to business

        I wish I didn't need to spend a chunk of my money on car upkeep or
        insurance. But I accept them as they lower my overall cost of
        transportation. Businesses face the same thing with software.

        (This is all to say I want the product owner to understand their real
        costs and benefits. When all is said and done, they may decide they'd
        like to mix functional & non-functional things to make an attractive
        package for purchasers and/or users, and that's ok.)

        Regards,
        --
        Bill Wake William.Wake@... www.xp123.com
      • Mike Dwyer
        Terry the management of released software is an ideal area for Scrum/Agile techniques. The business value of an upgrade comes from the business reason(s) that
        Message 3 of 3 , May 3, 2005
        • 0 Attachment
          Message

          Terry the management of released software is an ideal area for Scrum/Agile techniques.

           

          The business value of an upgrade comes from the business reason(s) that justified it approval.  The Product Owner (Accounting Manager) plays the same role as a decision  maker that prioritizes the changes (it is not a bad idea to have user stories or their equivalent associated with the changes), accepts the work and is there to respond to developer questions.   Now when you say the changes are ‘non functional’ am I to assume the upgrade changes nothing in the external interface with either the users or system/application/data interfaces. 

           

          Let us know.

           

          Michael F. Dwyer

           

          Mike.Dwyer1@...

           

           

          -----Original Message-----
          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Gannon, Terry
          Sent: Tuesday, May 03, 2005 1:45 PM
          To: scrumdevelopment@yahoogroups.com
          Cc: Salek, Chris
          Subject: [scrumdevelopment] Agile for Run-of-the-Mill Software Upgrade

           

          We have an accounting software upgrade coming up.  We're having considerable success with Agile/Scrum managing both development and implementation project, and we're considering the extension of it's use to cover this upgrade.

           

          I was curious to know if anybody has any experience in this area, particularly when it comes to expressing the business value of said upgrade.  It looks like purely non-functional requirement type stuff, which theoretically means you need to marry to a functional requirement in order to justify the value of the ugrade to the business.  Any thoughts you have in this regard would be much appreciated.

           

          Thanx!

           

          Terence Gannon

          Manager, Software Development

          Trican Well Service Ltd.

          Calgary, Alberta



          To Post a message, send it to:   scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



        Your message has been successfully submitted and would be delivered to recipients shortly.