As a developer, I see Sprint ends as an artificial deadline that people end up strictly meeting to the bare minimum. I find technical debt accrues most quickly

As a developer, I see Sprint ends as an artificial deadline that people end up strictly meeting to the bare minimum. I find technical debt accrues most quickly with smaller stories. Agile coaches will blast you for estimating workload too high and blame you for technical debt and rushing. They will say we need to refactor as we go along. And that stories will need to be even smaller. Quite frankly, bigger changes are easier to review as a whole and there’s less wasted time updating the test automation after each small change. Personally, I like to take a few days to review a change and I like to review a whole feature at once to see how it all fits together. It can be hard to see that until all the pieces are ready. Polishing it up before merging is also nice. In the business world we are led by timelines and milestones and competitor products. We have fixed dates we need to get things out by. Ive not seen a business ever run on the agile principal of “take your time and release when ready and don’t commit to dates but commit to features blah blah”. And I’ve heard from a few coaches now that the whole organization needs to be agile for it to work because the business can’t be waterfall while engineering is agile. Small agile rant aside.. I see technical debt as natural and acceues because we are given limited time to do something that keeps our paycheques coming. It’s normal for engineering to whine and for managers to push back. This conflict keeps both sides in check. Reality would stink if either side dominated the business. So don’t feel bad about telling your engineers “no”, but also give them enough independance to manage themselves as responsible professionals. Find that balance point.