Background
I'm a technical lead on a small team of three developers who work at a community college. Because of the nature of our environment, our projects are typically related (since the core set of data we use is relatively small), but all of our work is done in separate, independent C# solutions with ASP.NET front-ends.
I'm responsible for maintaining the core set of shared code, our college's framework, but I also have a full plate of projects. Because I wrote most of the framework code, neither of the other members of my team wants to modify or expand it (for reasons I can explain in greater detail).
Problems
Our entire team (the three of us and our manager) attended Scrum training last year, and are all busily trying to engage our internal stakeholders in the Scrum process. However, when we have to switch from one project to another (and we have about 25 separate projects), we incur a pretty high transition penalty.
Older code doesn't get maintained or brought up to new standards as easily because we simply add a reference to a specific version of the framework, which is then long-gone by the time we re-open older projects. We don't really take new code that we could reuse and integrate it into the framework.
Although our manager is supportive of us revising older code, our projects are always scheduled back to back – even now that we're using Scrum, we have internal pressure pushing new items to the team instead of us having room to pull new work when we're ready.
Solutions(?)
My team and I pair program, team program, or perform code reviews (if we can't pair) regularly. I have emphasized that I do not own our shared framework and regularly solicit feedback from my team for new features or bugs.
I proposed to the team that we try to find a new way to integrate our code together, which is through one large web-based project (I can hear you all inhaling sharply as I type this). I'm at my wits' end trying to build my team's skillset and confidence to the point that we can share code and we feel comfortable updating each other's code; however, progress is extremely slow while the amount of code we're maintaining grows much faster.
When I suggested this option to my team, everyone was really excited by the thought of being able to work together and improve our code reuse. We all feel like we could better support each other under this scenario. However, we're also concerned about approaching a project of this size, and we also don't know about logistical issues like the time it would take to run unit tests or even simple project builds. I recognize my own level of ignorance here, but at the same time, I'm really constrained by resources and personnel, so in spite of sitting with the idea for several weeks, I don't have any better options.
Best Answer
It sounds like you have several problems, not all of which can be addressed by Scrum alone.
You are dealing with a particular difficult set of circumstances. If you are raising issues out of your retrospectives, ensure that you are tackling at least one of the issues in each sprint. If you aren't getting the support from management to do so, a frank chat might be in order.
Just remember that you and your team are the world's foremost experts on this code. All of you can come up with a better solution when you work it out together.