Code cleanup / refactoring / touching code not related to the story

There's an adage in software development, colloquially called the Boy Scouting Rule, that states that a developer should always leave code being worked on in a better state than it's found. This comes from some of the "Leave No Trace" principles from the Boy Scouts of America. On paper, it's a good idea. Doing a lot of small refactoring over time can help keep code cleaner and more maintainable, and perhaps delay the need for larger refactoring or even rework. Clean, easy to read code also makes modifying or building upon the code later faster.

But there's a question of what it means for code to be worked on. Is it any code in the same function or method? Class? Package or module? File? That's something that the team needs to define. Especially since a developer could go down a rabbit hole of cleaning up code that is irrelevant to the problem at hand instead of doing work that adds more value. Professionalism plays a role in making the determination of how much time to spent cleaning and refactoring versus getting the job done and delivering value to the external stakeholders.

Risk also plays a role. Refactoring of any kind is always safer when there are robust automated tests that can be run quickly and easily on changes. If you can quickly and easily, with a high degree of confidence, assert that a change does not introduce a defect or have unintended side effects, it becomes easier to make those small changes in line.

Coming from regulated environments, I tend to favor a very narrow definition for what it means for code to be worked on, favoring function/method or maybe the class level associated with the change. Traceability from requirement through code changes and associated testing tends to be important. Changes with an unclear origin or rationale can also make code review more difficult. This usually does mean more overhead in terms of creating something to track the work, order it, and do this technical work, but it comes with less compliance issues that could come back to haunt the team later. But I can definitely see why teams would want to have broader definitions for keeping code clean.

I really dislike this; they are 'spending' time on something which is not agreed in the sprint planning

I quite like it. It sounds like those Developers are pro-active about remediating technical debt, and I'd feel positive about that.  I'd just wish it was agreed in Sprint Planning, and that time actually was reserved to do such things. 

I'd also bear in mind that the Sprint Backlog is subject to change, and is a forecast of the work to meet a Sprint Goal. It isn't a frozen plan to be slavishly followed.

When you say…

“they are ‘spending’ time on something which is not agreed in the sprint planning”

What was agreed upon at Sprint Planning? Was it a Sprint Goal with a desired outcome? Or a set of backlog items (‘stories’)?

Is the code being changed related to the outcome of the Sprint Goal? As Thomas mentions, is the scout's rule being applied and Developers are leaving code better than when they found it? Or is the work completely different from what is needed for the outcome of the Sprint Goal? How do you know as Scrum Master? Are you also one of the Developers?

“Example: for a story we need to create a new method in a class.”

Is the story really about creating a new method in a class? Or is it about a customer/user requiring some functionality from your product? Are the developers still achieving the objective of the story while also cleaning up and refactoring? 

Is the team not achieving Spring Goals as a result of this clean up/refactoring?

Could there be an issue of technical debt build up that the team is addressing through their work? 

Is the team adhering to the Definition of Done when they clean up and refactor? If not, do you feel the Increment has been compromised?

If you see an issue that impacts the effectiveness of the Scrum Team there is nothing wrong with raising it with the team. Crashing the Developer's Daily Scrum to raise this is not ideal. Retrospective is a great time to do this. Perhaps you are venting here in the forum, but telling the Developers their approach is weird may not be the best approach to gain their support. Openness shouldn't compromise Respect or the other values.

@Ian
I'd just wish it was agreed in Sprint Planning, and that time actually was reserved to do such things. 

If it was known before the sprint planning took place, the team should have mentioned this. But they did not. Instead during a chat over coffee I heard one of the developers saying that are cleaning up a lot of old code which took more effort then the entire story, and not once this was mentioned at the daily. The result was that another story was not finished (although the sprint goal was not affected). If it was addressed, it would be transparent and the team could have a discussion which might have led to a scope change.

@Thomas

Indeed the term boy-scouting was used.

Doing a lot of small refactoring over time can help keep code cleaner and more maintainable, and perhaps delay the need for larger refactoring or even rework.

I agree. I'm a big fan of reducing technical debt, but it is not up to a single developer to decide he wants to clean up something if takes a significant amount of time. That's my strongest objection.

@Ryan

No I am not a developer anymore; stopped doing that some years ago and swicthed to scrum master. So I know the desire to deliver good code and the urge to fix/ cleanup messy code.

Ofcourse the new method is added because of what the customer wants to achieve with our product. And yes, they are still achieving the objective of the story. But the effort needed was more then double then estimated (if only was done what the story was about, the estimate would have been accurate and another story (also a wish from the customer) could have been completed and delivered to the customer. So the customer now has 4 out of 5 requested functonality. 

And no, I did not actually used the word 'weird', more in the line of I was suprised to hear.... I do agree I should not have brought this up in the daily but should have saved for the retrospective.

So, all, thank you for the responses. I'll discuss with the team that I do agree with small boy-scouting improvements, but ask them to be open and realistic about it.

I agree with @Ian.  I think this is great!!  Almost every developer I have ever worked with in my 36 years of software development has done this.  But as a Scrum Master I have never once suggested anything about it one or the other.  That is because as a Scrum Master, the way the developers choose to do their work is not my concern. My concern is that they understand the Scrum framework, appreciate the values and principles.  I don't care how they do their job as long as they are producing usable increments of value that support the Sprint and Product Goals. 

As @Ryan says, if this appears to be impacting the Developers' ability to product Sprint Goal satisfying usable increments of value, then bring it up in a Retrospective and let the entire Scrum Team discuss it. But if it isn't having an impact, I see it as a practice that is increasing code quality which is a good thing.

I don't necessarily see a problem with leaving the code in better shape, either, as long as there is transparency established. A few Scrum Teams I worked with had a working agreement whereby the Product Owner agreed with the Developers to set aside some capacity for each Sprint to clean up tech debt (usually 10%). 

Other Scrum Teams I've worked with made the tech debt visible in the Product Backlog, and when the team was working on a Sprint Goal where there were similar Tech Debt PBIs, they pulled them in. 

Product Owners often tell me they don't care about tech debt, but they should. It slows down the Developers when trying to get things done and less potential value is produced each Sprint. And we all want happy, healthy teams, yet I can tell you that when I was a Software Developer I didn't enjoy working with code that was riddled with tech debt. It was very frustrating.

Hope this helps.

I agree. I'm a big fan of reducing technical debt, but it is not up to a single developer to decide he wants to clean up something if takes a significant amount of time. That's my strongest objection.

It sounds like the team needs to think through their working agreements around the scope of this clean-up, in terms of what parts of the code should be touched and the maximum effort to spent on such clean-up beyond implementing the feature. But, at the end of the day, I would argue that it is the Developers who do get to decide how much to spend on this type of work - "no one else tells them how to turn Product Backlog Items into Increments of value". Other stakeholders - including the Product Owner or Scrum Master - may raise concerns, but the Developers have to make these decisions on their own and then be accountable for the ramifications of those decisions.