Is randomly refactoring code allowed in scrum

Question

Background

• My team uses scrum
• I have currently no task assigned
• There are no more pending task in the backlog
• Today is Labor Day for my client.

Not having many things to do today I wanted to start refactoring some code I keep on seeing in the project I am working on, but currently I am not assigned to any sprint task to do any large scale refactoring.

Is it OK in Scrum if I start randomly refactoring code that I have and have not written that always bother me but don't have time other days to fix it because of other days assignments?

What about other days that I have spare time between sprints.

I actually do and believe in continuous refactoring. I always do it on the pieces of code that I am working when assigned a story but what about some other code I see that is not currently related to what I am working on at that moment?

Answer 1

I really don't mean to attack other answers, but is nobody else writing automated tests here? Here's a fun reading from Martin Fowler for anyone doing Scrum without proper software engineering practices. Robert C. Martin also says a lot about this here.

So, to my answer... In short, it goes like this:

Yes, "randomly" refactoring code is allowed in Scrum, as long as the team decides that it should be done. (After all, it is self-organizing)

And now for the long answer:

It's evident that leaving more and more technical debt after each Sprint is a recipe for disaster. Soon, everyone will slow down as the code bocomes more messy; every change will be harder to make because the code is so tangled and messy that it takes longer to find the spots to change than to make the actual change. It gets even worse if you have to make a change in a big and messy module that you know nothing about, it becomes impossible to gain/keep productivity when adding/switching people in the project, and so on.

If a team wants to keep its velocity steady, they must be able to keep the code base clean in order to continuously increment the software. Refactoring is a mandatory practice if you want to keep your velocity throughout the project's life cycle, and if you want to mitigate the risk of adding/switching people on the project, and if you want to be able to make changes in modules you know nothing about, and so on.

However, refactoring is a very dangerous activity. I repeat - it is a very dangerous activity. That is, unless you have enough test coverage to be able to safely and freely change the code base. If you can just hit a button to check if nothing broke, refactoring becomes a very safe activity; so safe, in fact, that it is part of the cycle of TDD, which is the practice that allows you to create such a test suite in the first place.

But, as the teams in Scrum are self organizing, in the end your team must decide what is the right thing to do. I hope to have given you some arguments in the case you have to convince anyone. (Give special attention to the links in the first paragraph, and every other article they point to)

Answer 2

Scrum doesn't really say anything about refactoring.

What Scrum does say is that if you don't have any tasks within the sprint to work on, you should support the rest of your team to reach the sprint goal. Even if that means fetching coffee for them.
If your team agrees that refactoring the code is the best way you can support them (and that includes having the infrastructure in place to ensure the refactoring doesn't introduce too many new bugs), then by all means go for it.

Answer 3

I'd say no, it's not. This is regardless of the type of work (refactoring, etc).

At minimum, tasks should be created and pushed into your current sprint. The purpose of time tracking is to capture your velocity in order to effectively be able to plot out future sprints. If you're working on things without tracking them, you will impact the velocity and it will not get better over time as it's intended to with proper tracking (you will likely regularly not have enough work because your projected velocity is less than your real velocity).

As for refactoring work in itself, I can go on a tirade about that, but I won't as I don't think it's the core question you're trying to have answered.

Answer 4

I am going to say no as well. Re-factoring often leads to unintended bugs if it is not managed the right way.

As a GM, periodically I would put everyone on another project and spend a week doing code reviews / re-factoring / renaming and enforcing conventions on a project. These re-factoring sprints would almost always be cosmetic in nature. Any functional re-factoring would be planned ahead of time and involve the original developer.

Functional re-factoring should always be planned and coordinated as part of the scrum process so the time can be tracked and all necessary team members are available to validate the process. One developer should not go off changing code written by another off track because most likely it is just going to mess up the current sprint for everyone. Especially when it comes to code merge time.

If it is a project which you are the sole maintainer and it is your own free time then it can be different assuming you take steps to ensure that you don't cause unnecessary delays in your current sprint.

When in doubt, ask your manager.

EDIT: I also want to mention that a given piece of code you do not like may have a certain performance target associated with it. You may not like it but it may be faster than anything you could build that suits how you want to use it. Just another reason why functional re-factoring should always be a managed process.

Answer 5

Scrum does not say anything about refactoring (see a lecture of Robert C. Martin, "The land that scrum forgot").

In Scrum tasks are targeting features of your software specified by the customer, not technical debts to repay by refactoring. These are totally different abstraction levels. The customer mostly is not able to evaluate the neccessity.

Scrum is statistical project management. To get meaningful measures of "how long does it take" you have to know the performance (output per sprint). You compare the estimation and the real duration for a feature for at least more than 1 sprint to get into the statistic. I recommend 5 sprints. But that depends on your team.

The main thing is to keep measures meaningful and comparable to make any forecast possible. That will not be the case if the performance is decreasing because of technical debts.

If you now still think of refactoring tasks you have two problems: 1. A customer, that does not understand, why he has to accept a task that will not produce a new feature 2. You totally distort your statistics and therefore your ability to forecast as you suddenly change a different variable that was not considered in previous sprints

In both cases you compromise the idea of scrum as you want to talk about features with the customer AND make reliable forecasts for "How long does it take?" in a statistical way. To be safe you have to keep your code base in a constant (maybe high) quality.

Refactoring is most of the time an underground task. "Great" refactorings mean that "little" refactorings haven't been processed in the past.

One last note: If you do refactorings make sure you have the component under test you are refactoring. Ohh, you do not have tests? Make a task to write tests. Your customer will be happy to know that the software he is currently using has not enough test coverage...

Keep the technical stuff away from the customer and do your job as a professional developer.

Answer 6

Here is one approach: do both !

Refactoring is often error-prone or more time-consuming that originally estimated as @misterbiscuit points out.

So consider an attempt to do it a draft or a spike. You don't ned to seek approval or advertise if at this stage.

Then, look to include it through one of two channels:

• an existing ticket that touches the same code / functionality where you can reasonable wrap this in. Reasonably as agreed on with fellow team members.
• entire a ticket for review at the next ticket grooming (or weekly meeting, etc. if waterfall). At that time you can make the case for it.

Once you get actual buy-in, you can look to apply or redo your spike and having the code actual get merged into the mainline (master, etc.) branch.

This will have several advantages:

• All your code codes through the same process, gets tested, QA, in the release pipeline, etc.
• You get formal buy-in, including from the product manager, that refactoring is part of the craft and not something that needs to be 'sneaked in' on a holiday. Ask yourself why you aren't 'sneaking in' an actual feature may help for perspective.
• You can ask for pairing, code review, qa, devops and all the other support that may be needed for the factoring code change. It will all be official, according to Policy and Procedure and above board.
• If you are a publicly traded company with SOX compliance you likely want/need to do this sort of formal process (i.e. document it and then follow it).
• You get a better reputation with both the product manager (change was done quickly) and the development team (codebase was improved).
• The organization is seeking to care about code quality which is good for productivity, morale, employee retention and many other reasons.
• The effect on project velocity can be more easily tracked when all work is included. It can be ok not to appoint any points as the presence itself can be used to affect velocity.
• Developers are likely to see out tools that encourage easier code reviews such as Fisheye, Github, etc.
• Developers are more likely to see out some basic standards (sometimes documented, sometimes not) that make sharing code and hence refactoring easier. Sometimes a big part of refactoring is picking a style and then applying it broadly (replacing a mixture of approaches with one).

A final comment: Avoid the product manager hearing the word 'random'. They may respond more favourably with 'targeted, strategic, performance enhancing' code upgrade. Or application service pack. Or whatever language gives you coverage.

Answer 7

Random refactoring makes no sense. What makes sense is refactoring of a code that will introduce most benefits. That means :

• fixing a design or architecture problem
• improving the implementation

---

Is it OK in Scrum if I start randomly refactoring code that I have and have not written that always bother me but don't have time other days to fix it because of other days assignments?

From this answer :

Keeping code maintainable needs to be an item on your burn-down list (if you use a Scrum). It is just as important as new development. While it may not seem like something that is "visible to the user", ignoring it increases your technical debt. Down the road when the technical debt piles up enough that your code's lack of maintainability slows down development, the delays in new feature development will be visible to customers.

In my previous work, we had some kind of scrum, with larger sprints (2-3 months). Since we had some delays between sprints (1 month), we used this time to analyze the software, and refactor the code.