How do you handle big CMS upgrades?

Last post 01:11 pm November 7, 2019
by Bob Korte
11 replies
Author
Messages
04:22 pm November 5, 2019

Hello all,

I have been looking for an answer on the internet, but could not really find one. Hopefully someone here can help me.

Problem:
We have a website that is running on a 3rd party CMS. We need to upgrade this CMS from version x to version y. The CMS upgrade itself is rather simple, but almost all the custom build software is not working on the new version. The dev-team thinks it is taking at at least 6 sprints before their own build software is working with the new version of the CMS. We have discussed how we can deliver increments (value) after every sprint that can be deployed. The only solution we came up with is that we need 2 production environments that somehow interact and switch depending on which content the visitor is looking for. The dev-team tells that an unknown number of sprints is needed to get that up and running.
All in all, we got the feeling that for the next upcoming sprints we will not deliver a working increment.

Question:
I am curious how do you handle a software upgrade in a Scrum way, where the base of the system is 3rd party CMS and the website itself is build upon this software?

Aftermath :)
Just to be complete. We are talking about doing this as a project, because we know what we want to build. There is no uncertainty. So why should we use Scrum?

Looking forward to read your opinion and solutions.
 

06:30 pm November 5, 2019

The only solution we came up with is that we need 2 production environments that somehow interact and switch depending on which content the visitor is looking for. The dev-team tells that an unknown number of sprints is needed to get that up and running.

Would this solution still be required if you took a project based approach instead of Scrum?

I think you're asking the right questions and based on your explanation I'm not convinced Scrum would be the best framework for this problem especially if it's introducing uncertainty by trying to force the work into deliverable increments. 

 

 

 

11:01 pm November 5, 2019

almost all the custom build software is not working on the new version

Why not? Shouldn’t it  be designed in such a way that it is decoupled from the CMS version? Shouldn’t the Definition of Done assure this kind of robustness?

It sounds as though technical debt may have been incurred through tight coupling, and repayment of that debt ought to occur before the next version upgrade. Repayment might be done incrementally.

08:04 am November 6, 2019

I can't tell whether the team in question already "doing Scrum"? This might not be the ideal operation to try it out on.

But it sounds like it is. If so, then why do you view it as a separate "project" in the first place? If this CMS and the software you build for it are part of the product that your team is responsible for, then this situation seems like a great incentive to come up with better solutions to improve your project's quality by reducing technical dependencies.

08:13 am November 6, 2019

Ian, we also feel, we have a technical debt. We have build and extended upon the CMS system. And one of the challenges we face is making the next CMS upgrade more easy to execute. Not failing really fast, but eventually we learned ;-)

The main question is, how? We are really leaning toward a project, but I was just wondering if it is possible to use Scrum. And how this should be done. For example one of the questions we have is: "What are we doing during the review?". But also: "How Scrum are we when we do not deliver a working increment".

What I get from your response is that we might need to pay the tecnical debt on the current platform and then upgrade. I will talk this over with the team.

08:16 am November 6, 2019

Tony, if we are going to make it a project. We are really going to make it a real project and waterfall it. But, somehow it just does not feel right. Perhaps it is something we as a team should accept.

08:26 am November 6, 2019

Bouke, we are doing Scrum at the moment. We have build the website using Scrum. And we have been maintaining and adding new features the last 2 year while using Scrum. And it worked great.

We most definitly view this situation as a great oppertunity to improve things. We just never expected that a new version of the CMS would have such a huge impact on the things we build on the system.  E.g. the supplier decided to implement new search engine software. This means the whole search functionality must be rebuild. Which by itself will cost around 2 sprints for the whole team. But for this functionality to work we must complete the upgrade, which also takes about 4 sprint to do. So we will try to reduce technical dependencies as much as possible. But at this time we feel we are between a rock and a hard place. ;-)

03:28 pm November 6, 2019

Going back to the Sprint Review and delivering a working increment.... 

As for the working increment each Sprint...that's what the team should be striving for, however, there may come times when it's not feasible to do so. If that's the case, is this transparent to the stakeholders? The team could identify logical milestones to show progress and functionality even if it's not release ready. 

For the Sprint Review, there's a lot more that can be done here aside from just collaborating on the Done Increment. For example, timelines and budget can be reviewed based on progress towards the established milestones or the Done work. The Product Backlog can be updated with feedback, new learning, etc. The team can discuss the challenges in relation to developing the product. 

01:06 pm November 7, 2019

We are doing Scrum at the moment. (...) We just never expected that a new version of the CMS would have such a huge impact on the things we build on the system.

That realization sounds like an important result of inspection. To me there seems to be no reason to throw Scrum out of the window for this "project". The opposite, in fact, all the more reason to redouble your efforts and improve your product (at least by reducing the dependencies) and processes.

Scrum seems to have been (at least part of) the path that led you to the realization that you are too tightly coupled to be nimble and quick in the first place :)

01:08 pm November 7, 2019

Thanks Tony. I will ponder some more on this. You certainly gave me some food for thought..

01:10 pm November 7, 2019

Well Bouke, that is some insight I might have overlooked. And when I combine this with the information from other posts. I actually see that Scrum might actually be the way to go.

 

Thank you all for your time and view of things.

01:11 pm November 7, 2019

Well Bouke, that is some insight I might have overlooked. And when I combine this with the information from other posts. I actually see that Scrum might actually be the way to go.

 

Thank you all for your time and view of things.