Don't live with broken windows...
This is my favorite motto when it comes to software development processes and software architecture. The broken window theory is quite well known and pretty good summarized in this post by Francisco Sáez: "Review your system regularly, keep it current, and fix any imbalance as soon as you discover it." When nobody cares and no one feels resonsible, every system will rod.
But there is even more to consider about broken windows...
... fix them
This is pretty straigt forward. But how to do this? You should be an example. As a developer, you repair the windows without being asked. As a manager, be consistent and insist on the "repair" of broken windows. And provide "budget" (time) for the repair. If you can't decide on the budger, "hide" the budget in the effort estimations for upcoming features and changes.
... don't break them again
This seems to be obvious. However, are you really sure to identify a crack when you see it? Or if one of your developers do so? Everyone working on the software has to be aware of the principles and architecture in place. And has to have the skills to understand them. As a manager you should make sure that your developers are skilled enough and know your particular architecture. If not: train them, educated them!
You also should "publish" and talk about new damages. In the moment you detect them. Tell your colleagues why you think this is a broken window. Not in order to blame anyone. But to give examples of "better" coding and encourage a very important habit: practice and reflect. Nobody is perfect and in a team (particular a scrum team) you should be willing to learn and embracing the discussion.
... safeguard them.
How do you protect your most important possessions? With an alarm system, ie automatic monitoring.
Make the same for your software. Install an alarm system that monitors whether some windows are broken. Install appropriate alarm systems into the build process. Not just automated testing. Also monitor you specific architecture and code quality with appropriate tools such as SonarQube or dependency analysis tools like JDepend.
... (re)design them
Sometimes, things change. Requirements to your software evolve with your customers need. So it might happen that you don't need the window in this particular place any more. Maybe a window must be walled or a small window should be a door. Consider refactoring and architecture changes for broken window surveillance.