My team leverages feature flagging heavily. Developers want to clean them up but product doesn't prioritize the tickets, and it creates more burden for QA as well having to do a full regression test.

Sounds like a great reason to include cleanup as part of the initial work.

The issue is not about feature flags then.

It's stakeholders not giving engineers necessary time for upkeep, probably caused by engineers lacking ownership, or failing to communicate

It’s a system where engineers are signing off on work that isn’t actually complete. Which is a problem we had in Waterfall and mostly solved in Agile, except for feature toggles.

In my experience engineers usually want to remove the outdated flags but product does not prioritize that work.

I have found it very professionally unsatisfying to have a clear and documented reason I was unable to code up to my own standards. It doesn’t help of it’s somebody’s fault or everybody’s fault instead of just mine. It might actually be more upsetting, but I’d have to reflect more on that.

At the end of the day it’s still fuckery I was unable to avoid.

We had an experience where it was product that pushed for cleaning up the flags.

The best companies I've been at where those where product and engineering really operate as one team.

Then that is simply a bad lead on the team. "Do your job." (Not you)

At the risk of sounding like a broken record, I think this is a problem that is compatible with Kanban and incompatible with Scrum. The end of sprint encourages people to mark a task as done that still has several steps and about eight business days before it’s “Done”. But WIP limits in Kanban could be tweaked to account for this and I believe still provide the correct sort of pressure for you to finish what you started before starting something new.

In Limited Work In Progress (LWIP aka WIP-Limited) processes, if you are blocked on your story you help someone else get unblocked on theirs. And then escalate if there is no movement.

As someone whose current team process is Kanban and a previous team were also, tech debt like this still inevitably piles up. Sure maybe you can squeeze some time in but even getting a week to spend solely on cleanup is rare, if it comes up at all.

The distinction I’m talking about is marking the feature milestone for deployment but not counting the feature as done until the toggle is dispensed with. Either removed, or declared a configuration we intend to keep indefinitely.

Admittedly, there’s still a gap there where a toggle may be needed until the end of an initiative (an Epic in Scrum terms) but that’s going to be at least an order of magnitude, and likely 2 orders, fewer toggles to deal with.

When the order of magnitude changes so does the solution.

At one of my first jobs, the codebase was massive and feature flags were heavily used. My first task given by my boss was to remove flags that have been enabled in all environments for a while. Great and engaging way to introduce someone to a new codebase, it's relatively easy and can be done with little assistance right of the bat, you also get to commit code in your first days and it reduces tech debt making everyone happy.

Been doing that with my new hires in other jobs.

This is one of the reasons we built type-safe feature flags at Hypertune. When a developer deprecates a flag, they get type errors everywhere it's still used. This fails the build so they're forced to remove all the flag references, and they get a nice IDE / compiler driven workflow to do that. Otherwise it's easy to leave flag usages around.