In agile development how do you deal with the “less-well-architected” code that results from a sprint-focussed mindset [closed]

Question

I work on an agile project using Scrum.

Sprints have come and gone and we have fulfilled milestones successfully. The system works well enough to meet the current customer requirements.

However, we are left with a system in serious need of refactoring, as much of the development was performed with little eye on the future (instead the focus was on the sprint at hand).

How best to deal with this? Sprint(s) dedicated to refactoring?

Answer 1

Yes, the occasional one of those is sometimes not a bad thing. But if you're agile using Scrum, then you are presumably trying to follow Test-Driven Development (TDD), and it is important that you remember that the sequence is red-green-refactor, not just red-green. Bad quality code is not the output of agile development, but of poor agile development.

Answer 2

Do you have a definition of 'done'?

When you have finished coding and are ready to check in, you should have met your teams definition of 'done'

This definition should amongst other things include meeting your acceptance criteria / code review / test review / and meeting agreed coding standards.

If after several sprints your code base is in need of serious refactoring I would suggest your definition of done needs reviewing.

Here's an article from Scrum Alliance on defining your 'definition of done'

Answer 3

You don't necessarily need to dedicate a whole sprint to refactoring, it can also work at the task level. When you have a story that requires working with some hairy piece of code, include a refactoring task in that story as a kind of prerequisite for getting anything sensible done with that part. That way, you make progress with the features but also get some refactoring done incrementally.

Answer 4

For my team I typically start a refactoring sprint roughly once every three to four months. Considering we run 2-week sprints, that's one refactoring sprint roughly every seven sprints.

I run the refactoring sprint like any other sprint - strictly 2 weeks time limit. Sometimes we even run just 1 week refactoring sprints (when something urgent comes along).

A note on refactoring sprints: don't be too ambitious:

1. Realize that refactoring is an infinite cycle: you'll always find a better way to do things.
2. It's OK if you refactor only 10% of what needs to be refactored.
3. Treat refactoring like any other stories so that you are forced to prioritize what to refactor and recognize where in your code is in most need of refactoring. The only difference is that for refactoring stories I let developers set priorities.
4. A partial refactor will still leave your code in a better state than no refactor at all. Plus, it tends to make further refactoring easier.
5. Refactoring happens even outside of refactoring sprints when working on stories, but only if the refactoring is a low-hanging-fruit that doesn't interfere with stories being completed.

This is what I personally use as a guide to refactoring. It not only make refactoring managable but also serves as a good indicator for when you're overdoing it.

Answer 5

Where I work, we will have sprints dedicated to bugs and technical debt. It works well for improving things and having a spirit of continuous improvement to some extent.

Something to also ponder here is whether or not there are enhancements that the customer wants but hasn't requested. Does the customer seem genuinely happy with the current system or does it just work good enough that he doesn't want to complain?