> sprints give more discretion to the teams

when they do. i was part of an 'agile' team in 2019 (6 mo contract). I wasn't there long enough to have strong views on work items or priorities, but did watch the interactions between others. It was a decently organized team inside a (fast) growing org - lots of challenges there. But overall, there was a decent balance.

Worked on another smaller team longer - 2 years. As the company grew, it got far more process heavy. The 'sprint' stuff was "as tech lead, you get 5 points to use however you want per sprint!" (yay?). that got taken over by the CTO getting involved and using those '5 points' for constant infrastructure stuff. I was reviewing code I delivered, and it was full of cut corners to continually hit deadlines. I begged on a few occasions for more 'cleanup' time. It was always denied (except for 3 days over xmas, because... literally no one else was working, so they couldn't say no).

The project transformed in to "here's our strategic goals for 2022" with every quarter mapped and filled to the brim with work. 0 time for anything but bare minimum MVP. The thinking was "well... you've been able to work at that pace before, and we added someone new, so we can increase that". In 2019, it was MVP - test the idea. Speed to market makes some sense. In 2022, millions of dollars and hundreds of lives affected each month... we need to take a bit more time to clean up existing code, retire legacy code, adopt a slower pace to focus on clarity, testability, even performance concerns etc. This seemed to fall on deaf ears.

"discretion to the teams" tends to ring hollow to me based on recent experiences, and ideally I'll work with another group in the future with a healthier balance.

On a 6 month contract you haven't been around the code long enough to know what is tech debt and what is a good solution for a complex solution.

Though your point is correct - you rarely are given time to fix tech debt. If you switch to a long term employee, then you should intentionally slow your velocity a little to fix tech debt. By the time management catches on you will have fixed enough that an improvement is visible and so you have proven yourself, and thus will be allowed to do more of it.

Also note that a story isn't done until refactoring is done. Sure it works, but if the code is a mess your story isn't done and you don't move onto the next one. Many developers fail to force this, but as a professional this should be part of your code of conduct and thus not optional no matter what the deadline.

In any case the point is you will never be officially given those 5 points - but you can take them by force.

I think the answer here is to point your current tickets higher. When someone asks for estimates on time, or points, you give a higher estimate so as to not leave as much tech debt behind. In theory or course, may not work in practice.

Potentially, some, yes. However, when goals have already been decided, and 'missing' those goals is a 'bad thing', there's only so much you can do. We'd gone from collaborative to 'command and control'. And... FWIW, we got a lot more done under 'collaborative', but it was mostly just 'me' on the dev side and one other person on the product side.

At some point though, many of the original assumptions about problems are understood to have been fundamentally wrong/misaligned, and need some revisiting. You need to touch old code, whether to delete it, or to have it align with new standards or new ... whatever. Touching anything that didn't relate to an explicit 'agreed on' jira ticket was seen as wrong/bad. I ended up bundling in 'fixes' of unrelated stuff when working on 'new' stuff because... it had to get done, but was ignored or rejected during any sort of planning.

I've heard it said that "to go fast, do it alone. to go far, you need a team". I can get on board with that, but you need a team in agreement and competent. I have a colleague working on a small team and... they're mostly just completely inexperience and bad, but there's no self-awareness. Taking direction from the guy who was in high school last year, while ignoring the person who's lead multiple teams and has delivered high value software for 20 years... that's a bizarre imbalance that can't be fixed with 'sprints' or process alone.

Agreed.

As an aside, one thing just came to mind. Even if you're bringing tech debt tickets into each sprint, there's a possibility they'll get picked up last - fine, unless they keep getting pushed back!

Part of me thinks this could be mitigated by reducing the velocity expectation. But there tends to be an overarching sprint goal relating to product work, and this often invites extra scope due to unforeseen impediments. So 'background' work like tech debt is easily pushed back.

I don't know of a better way. Perhaps it comes down to human factors such as limited focus.

There are two ways management can handle getting things done on time: commit to taking only 80% of the teams capacity, thus ensuring there is plenty of buffer; or commit to the full thing, and accept that some things won't get done. If (as most do despite Agile warnings about it being wrong) your management wants you to get done 100% of what you commit to, then as a team you need to hide 20% of your capacity from management.

Do not let formal debt and improvements compete on the same ranking.

Either do 2 of this, 1 of that, or have separated time slots, or whatever. But separate them.

Yep. We used to dedicate 20% of story points to tech debt, when we had quite a lot of it.