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


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.


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.

  • 3
    You could set up a internal Nuget repository and put common/framework projects in there. Then it's pretty easy to share and re-use components in that fashion.
    – Jon Raynor
    Commented Feb 2, 2016 at 18:01
  • Tried that. It worked better for integration, but didn't address the overhead of switching projects or improving code reuse.
    – jwiscarson
    Commented Feb 2, 2016 at 18:10
  • The code reuse issue is huge and solvable is there is a project named XYZ.Common. As developers refactor and get to "generic" they need a leader to teach them to put that code into common. But, how do they find common reusable code? You must use code commenting and create an API. Host the API on a web server and use it (just like we use MSDN .NET API everyday) to get answers to our questions. Commented Feb 14, 2016 at 5:48
  • @jwiscarson what is the "overhead of switching projects"? Commented Mar 2, 2016 at 3:13
  • @EdmundYeung99 - This is like an interruption tax on your productivity, and studies show that, after an interruption, it can take 20-30 minutes to pick back up on your work. In this case, since we have so many different projects, switching from one to another creates the same kind of burden.
    – jwiscarson
    Commented Mar 2, 2016 at 20:12

2 Answers 2


It sounds like you have several problems, not all of which can be addressed by Scrum alone.

  • Referencing older versions: this sounds like a job for continuous integration and automated testing.
  • Architecture: the project structure you are describing isn't atomic. Can you test each part of the application in isolation? If not, you may want to consider a change in the whole architecture that resembles a suite of services than one giant web project.
  • Overhead: Here I'd suggest two approaches. 1) Implement coding and architectural patterns and practices; and 2) Create zones of expertise, associating one person with a set of services. This person becomes the go-to person for technical questions on how to move the functionality forward.
  • Recycle/Reuse: You all are generating a large amount of code, but it sounds like you are creating plenty of single-use code. Could a generalized approach work better?

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.

  • 1
    What does Scrum have to do with your bullet points or the rest of your answer?
    – RubberDuck
    Commented Nov 12, 2016 at 10:30

My suggestion is to fix your priorities first and ask yourself.

Does the business really need it?

If not the nice part about Scrum is the notion of a backlog. Just dump your ideas there and let it grow. The backlog itself can have multiple weights (e.g. technical and business) to help you prioritize.

Then when you have a "healthy" enough backlog where you have a a set of business requirements see which ones of the technical ones can be fit in.

Ensure you give your team proper capacity. (i.e. don't allocate 8 hours a day for your developers) and factor in a known unknowns bucket to figure out what needs to happen.

What if business does not want to pay for it?

And why should they? It does not improve their bottom line... or does it? When you put in the effort estimate you can simply say with this technical fix the story point cost would drop from 13 to 3 thus helping us reduce our work going forward at the expense of having less features on an earlier sprint.

You can also add that by adding this technical fix in we can further reduce our known unknowns bucket sizes further.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.