Forums

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Technical Upgrades
Last Post 24 Aug 2013 11:40 PM by Ian Mitchell. 6 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Randy Ho
New Member
New Member
Posts:47
Randy Ho

--
18 Jul 2013 06:21 AM
    Our product depends on a third party piece of software and want to periodically update the software to the latest version so that performance enhancements and bug fixes are addressed.

    We know we need to set aside some time for someone to upgrade the software and run regressions and track any integration issues.

    How would you guys scrum this? Do we need to dig into the changelist of the dependency and pinpoint reasons for the upgrade? Can we simply do it as a constraint? DoD?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1535
    Ian Mitchell

    --
    18 Jul 2013 11:10 PM
    The third party software is not developed by your team. It's a dependency that your team has. This puts it at a higher level than your team's Scrum process. Things like this are generally best handled by larger scale frameworks such as SAFe or DAD.

    To be more specific, it's the sort of thing you need to integrate within an agile Release Train. The features and enhancements provided by each upgrade need to be understood, along with the risks, and included in your Product Roadmap. The upgrade dates then feed into the Release Train, which is your plan for incremental delivery.
    Fredrik Vestin
    New Member
    New Member
    Posts:72
    Fredrik Vestin

    --
    19 Jul 2013 02:06 AM
    Dependencies like this has the potential of breaking many things. We usually do a spike in a sprint where one or more team members update the 3rd party software, run regression tests and verify that everything is working as expected. For the next sprint we know enough to decide whether to proceed or to roll back to the old version. this applies to the IDE and 3rd party components. Test automation is key to avoid a lot of manual testing and to make sure that you can ship after each sprint. Also, since this is high risk we do this as early as possible for a new release.
    Randy Ho
    New Member
    New Member
    Posts:47
    Randy Ho

    --
    19 Jul 2013 07:39 AM
    Fredrik, that's exactly what we were thinking of doing. The thing that makes me unsure about it is how we should represent it in our product backlog. We use user stories and sometimes it's not apparent if an update will provide direct value to the customer.

    Is this more of the technical wishlist item sort of work or can we somehow write this as a story?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1535
    Ian Mitchell

    --
    20 Jul 2013 12:50 AM
    It doesn't really belong on the Product Backlog unless it provides new features that the PO values. It's a technical dependency in your release train, one which the Development Team are in charge of, and it brings with it the need to assess the upgrade risks.

    Fredrik has described a way of managing those risks by a Development Team within a Sprint. Since the team wholly own their Sprint Backlog, they can include whatever requirements they want within it, including technically focused ones for spiking in the way Fredrik suggests.
    Charles Bradley
    Basic Member
    Basic Member
    Posts:409
    Charles Bradley

    --
    20 Jul 2013 04:55 AM
    > Things like this are generally best handled by larger scale frameworks such as SAFe or DAD.
    I completely disagree with this statement. IMO, SAFe and DAD are not really Agile at all, but that's not really on topic with the poster's question. I will add that I'm much more in favor of the scaling ideas from Cohn, Schwaber, and Larman/Vodde.

    One way to think about 3rd party component(or service) upgrades is that they *are* requirements in the sense that they are outside your system. A requirement on a system usually occurs at the boundary of a system. Most people understand front end requirements, but back end requirements(when connecting to 3rd party systems) are also requirements, especially when the thing your interfacing with is outside the control of your company.

    With 3rd party components, I think you have to ask yourself... Where's the business value in upgrading to the new version? Business value in these situations usually comes down to either a) taking advantage of new features and bug fixes that *your system will **actually** take advantage of/use* or b) there is business value in making sure you are working with a fully supported version of the 3rd party component (but that doesn't mean you have to do every upgrade that comes out -- only ones that are required to get you off of an unsupported version and onto a supported one)

    So, Randy, I ask you -- does a) or b) even apply in your situation? If not, what would happen if you did NOT do the upgrade?

    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1535
    Ian Mitchell

    --
    24 Aug 2013 11:40 PM
    > IMO, SAFe and DAD are not really Agile at all...

    SAFe and DAD are like the UK rail network. They are utterly broken and pretend to be something they are not, but thousands may use the creaking infrastructure for part of their journey.
    You are not authorized to post a reply.


    Feedback