Something is rotten in the state of a refactoring sprint

Something is rotten in the state of a refactoring sprint

When a technical team demands a sprint just consisting of refactoring you know there is some fairly hefty dysfunction hiding somewhere in your process. It is questionable if this would be a sprint at all, yes there may be a potentially shippable product at the end but to the product owner it will have the exact same functionality. The sprint review would be fairly dull. It is however a sign that you’ve built up so much technical debt that your team can no longer take the strain. Here is what I’d suggest you look for.

  • Are your team doing TDD? If so then that process encourages refactoring. Write test, write code to pass test, refactor code until it is solid and fit for purpose. If that’s not happening then maybe they need a refresher on the approach. If they’re not doing TDD then perhaps it’s time to give it a try.
  • Code review or paired programming? Another set of eyes (or brain cells) will spot things that you didn’t. It also focuses developers on coding for the good of the team rather than the good of themselves. Example: If developer X knows that developer Y is going to look at her code they are more likely to make it understandable and efficient. If developer X knows they’re the only one who will look at this code then perhaps they’re the only one who needs to understand it and perhaps they feel it’s better for the business to get it done quick and move on so that as a team we can deliver more.
  • The Definition of Done. Has this got anything to suggest that refactoring or adherence to code quality standards should be met? Sometime this is implicit. If there is nothing and the team are not doing it then see if they want to add something to ensure it gets done.
  • Check that the team are not being put under undue pressure to churn out functionality at the expense of quality. It can often be pressure or perceived pressure from the business that makes the developers think they should for-go quality to push through functionality. It is the Scrum Masters role to protect the team from this form of pressure. If there is pressure from the business then it is the Scrum Master who should be explaining the need for quality and the pitfalls of ignoring it.

As with real debt the best way to avoiding painful debt payments is not to take one out in the first place. The worst thing to do if you are in debt is ignore it and hope it goes away. That’s not to say all debt should be paid off immediately, some debt can be lived with until the right moment. Understand your debt and ensure you are not adding to it.

Leave a Reply

Your email address will not be published. Required fields are marked *