How to adopt Continuous Refactoring?

This is a question that I have been asking myself, as well as received from others, a bunch of times. I am posting it here in the blog since I don’t have a ready-made answer. Please leave some comments on this if you have suggestions.

To clarify the question, let me begin by setting the scene for you;

Let’s say you are introducing Scrum. The team is, as always, a bunch of developers with varying experience, competence, and ages. You have read my blog ;-) as well as other even better sources of Scrum & Agile ideas and opinions, and you understand that the concept of “continuous refactoring” is central. You realize that anything is less likely to succeed if you try to solve everything at once in one single shoot; so it is better to work iteratively and deliver in increments, in order of priority. How do you get this message through to the developers, so that they really adopt it, wholeheartedly, in practice?

Because the problem here, in my experience, is that most people take a lot of pride in their work and “continuous refactoring” is easy to mistake for “rushing things out”. Some people just can’t get used to the idea of not attempting to do it “perfect” or “complete” from the beginning, and thereby find it extremely hard to deliver something that “just works” and is “good enough” for that particular product increment. Obviously, people are different (and so are programmers ;-)), so some will easily adopt this way of thinking, while it will be much harder for others.

How do you do it? It probably has much more to do with psychology and leadership than with Scrum per se, but I still think it is a relevant topic to bring up within the boundaries of this blog.

My suggestion on how to go about this is to educate. Talk about it. Have trainings. I have had lengthy discussions about this topic in the Scrum training sessions that I’ve held, and I can’t say that it has magically solved anything just like that, but I think the key to any change is for people to understand the need for it – and the first step for that is to talk about the problems surrounding BDUF (Big Design Up-Front, which is sort of the opposite of Continuous Refactoring).

Please leave some comments.