How do you handle big CMS upgrades?

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. 

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.

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.

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.

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.

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

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. 

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 :)

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

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.

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.