Technical Upgrades

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.

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.

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?

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.

> 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?

> 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.

only ones that are required to get you off of an unsupported version and onto a supported one

@ Charles Bradley : 

I think the original question was more or less dedicated to exactly these kinds of cases (not to interpret the posters intention for him, but at least that was how I stumbled upon this discussion after some googling.. 😬).

If we consider only these cases—passing from an unsupported version onto a supported one—how do you integrate this into your agile flow, if there's no sufficient business value to attach to it? Does "moving to the supported version" automatically have to imply business value?

@Johannes Neukamm:

again multiple months later... :-)

According to me, it's up to the business to decide.

I'm a product owner myself, and in cases like that, I would like the dev team to explain to me the risks, costs, benefits etc... of upgrading to a new version or staying at the old.

It's then up to me to decide whether I want to take the risk of staying with an unsupported version (for example) because maybe there are more important things to do at that point in time.

Or the risks are becoming that high, that the value of upgrading is important enough.