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?

Maniacal

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.

Unbrace

+1 More if I could - it makes me sad when agile gets a rep of poorly architected code, when agile with TDD is explicitely designed to improve the architecture of code through continuous improvement. – Voltaic

I disagree, TDD does not often equate well architected systems. Also, TDD should be used as an "when appropriate" approach. While I agree with red-green-refractor, I believe a lot of people get hung up on this and as a result - prolong development significantly. TDD is great for focusing in on micro portions of an app. It obviously will expand and grow into a more well designed workflow, but that doesn't really always result in a good macro design. Sprint level refractors are critical for this. – Tensible

@Chance: (1) Any methodology poorly applied or misapplied will lead to a poorly architected and written system. (2) TDD is a development methodology that is often applied within an overall agile process, and my comment if you read it talked about the output of agile development, not specifically TDD. If you try to use TDD to solve higher level problems like architectural ones, you'll fail. TDD does not ever equate to well architected systems, just like a driving test does not ever measure ability to cook an omelette! But well done TDD does not exacerbate the situation. – Unbrace

This might be a bad thing if your organization is seeking to achieve the productivity gains associated with high-performing (aka hyper-productive) SCRUM teams. Jeff Sutherland is very clear on the prerequisites for such performance gains, including a more disciplined definition of "done" than is described here. Carl Manasters answer provides more details. – Simulcast

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'

Soapberry

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.

Shoifet

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.

Stratum

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?

Debtor