[zwieback]

I'm working on a couple code bases that are 10+ years old in a mature organization, but for internal customers only. In those cases there's definitely awareness that paying down technical debt is worthwhile since everyone can remember times where the debt ballooned and it was painful.

Other projects not so much, especially in this day and age where rapid delivery and throwaway is actually an accepted form of SW development.

The fact that Agile and its ilk sprung up and mostly failed to address these issues shows how hard a problem this is.

[jacques_chester]

Where I work, the basic doctrine is that Engineering can schedule "chores" -- refactoring, tech debt paydown etc -- according to its best judgement. We don't interrupt Product's priorities willy-nilly but depending on the cadence you'll find a certain amount of tidying working going on all the time.

There's also a fairly high bar for what gets marked as "Done", so the rework is a bit lower. I've been on stories where we spent as much time dealing with the architectural consequences of a new feature as we did on the visible bits.

Sometimes it can be hard. Especially in the anchorship role. I've once had to tie up an entire track of work to fix the tech debt equivalent of a toxic spill for weeks and weeks. It sucked, there was zero user-visible value gained, but it simply had to be done or we would suffer more and more.

I dunno if that's considered agile or not. At some level it doesn't bother me.