What do you do when you get X months into a project which is using Scrum and either a story, a developer, a review or planning session makes it clear that a serious architectural problem is evident, which was not evident at the start of the project? Ignoring why it is so, whose fault it is or the reason the current architecture was chosen.
Currently, I'm not working in Agile or Scrum daily so this may sound naive but couldn't you try to turn the architecture issue into a story? Support teams, DBAs, and future dev team can be described as a "user" and can have viewpoints on usability, scalability, DR/BC, etc. and you can toss them into the same evaluation process as any other user story.
This may seem like an obvious or overly simple answer, but usually the right answer is to address it as soon as you see it. Simply put, it is usually better to fix it now than build a bunch more features on top of a flawed architecture before fixing it.
Also be open to the idea that you may need to fix some parts immediately to stop additional work from making the problem worse while other parts may be less urgent. That may help it be a little less massive of a refactoring effort.
PBI's Not User Stories
Scrum does not demand user stories. The idea that every backlog item can be a user story is a nice academic exercise, but don't get hung up on it. Put in the needed product backlog items to course correct your architecture.
As for producing a valuable increment, if the architecture is truly problematic, there is user value. Maybe it deadlocks after 100 concurrent users or you get data mixed between sessions or, maybe the technical problem is all code-related and your ability to develop fixes and user-requested features in the future will be hindered. Either way, there is value in that increment.
It is hard to come up with the perfect architecture from the beginning. Decades of software development has taught us this. Use architectural constraints to help keep your architecture "in bounds" and help alert you when you're drifting too far. Progressive web apps offer a great example of architectural constraints. Some of those rules include:
- App must work offline
- App must work on all browsers
- App structure should load and fill in content
These loose rules let the team make better architectural decisions without having to set an architecture in stone at the start.
This, of course, won't completely prevent your situation, but when it does occur, one or more constraints can usually come out of it to bring things back on track.
In Scrum, like most agile approaches to development, the whole team is responsible.
This is the 11th principle of the Agile Manifesto:
The best architectures, requirements, and designs emerge from self-organizing teams.
So I must point out, it is very likely that the same issue would have revealed it self at a much later stage (time wise) in a BDUF approach. At least now, instead of blaming an individual, the team will own the issue, fix it, learn from it and move on.