Why is Refactoring a “Must”?

“In order to do Scrum or XP or any form of Agile successfully, you must refactor. Sorry, not optional. Necessary.”

Some post somewhere griped at my recent declaration that to do Scrum, you “must” do refactoring. My little discussion there ended with the quote above.

The poster, whoever it was, got all upset about being told what to do because their Scrum teams are really providing benefit, thank you, and anyone who says they have to do refactoring is wrong. Yes, well.

I’m not saying that refactoring is a rule, and people must follow it because I say so. I honestly don’t care whether people refactor or not: I don’t get a royalty on it. Refactoring is a law of nature for fully successful iterative projects. Using Scrum terms, here’s why:

  1. Scrum requires that “DONE” software must be delivered at the end of every Sprint. The team gets to decide what DONE means, but basically it means running, tested, integrated, ready to ship.
  2. Sprints are a month long in classic Scrum, shorter in most modern implementations. So the team has to deliver DONE software in the first two weeks or first month of the project.
  3. The software in question has to be from the Product Owner’s backlog. It must be features. To do Scrum correctly, we can’t be delivering infrastructure items: we must deliver features.
  4. Therefore, in the early Sprints, there will not be time to build the entire robust infrastructure that the final product will require. We will only be able to put in a limited amount of infrastructure.
  5. However, the full product will almost certainly require a larger, more powerful, more robust infrastructure.
  6. So the infrastructure for the project must change, not because I say so but because at the beginning we can’t have it and by the end we need it.
  7. There are only a couple of ways we could change the infrastructure. We could write it over again every Sprint, or we could evolve it. Writing it over again is inefficient. Therefore we must evolve it. Software evolution is refactoring. That’s what refactoring is.

We must evolve the infrastructure. It’s not a rule, it’s worse. It’s essentially a law of nature. Until we learn to evolve your design, our Scrum may be providing benefit, but we’re almost certainly not performing as well as we might be, and we are probably in peril of slowing down as time goes on.

Any questions?

2 Responses to “Why is Refactoring a “Must”?”

William Pietri

February 6, 2009

5:59 pm


Hi, Ron. It seems like a lot of people lately get all riled up when somebody says “X is not Agile”. I think it’s great that people say that, and that a lot of the grumbling is based on a misunderstanding. I’ve tried to explain that misunderstanding, and I’d love feedback from you and your readers.


February 10, 2009

10:22 am


I am more inclined to say something like “That’s not what I teach,” or “That’s not what XP says (as I understand it),” or the like.

Personally, I think the question “Is X Agile,” is a waste of time. Teams don’t get paid for being Agile, they get paid for producing good software in short amounts of time. There are ideas in Agile (well, at least there are ideas in XP and Scrum) that can help.

One thing that is less useful than asking “Is X Agile” is to bash Agile, especially when one doesn’t know much at all about it. To do that is to display ignorance at multiple levels. Just unwise.

Recent Articles

Emergent Design

Martin Alaimo asked about the Manifesto Principle "The best architectures, requirements, and designs emerge from self-organizing teams."

XProgNew – Pivot?

Experience with Sinatra, and some thinking, cause us to look at a shift in approach. Martin Fowler was probably right.