“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:
- 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.
- 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.
- 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.
- 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.
- However, the full product will almost certainly require a larger, more powerful, more robust infrastructure.
- 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.
- 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.