[brailsafe]

Absolutely agreed. I'm on a team that is presently working on some rewrites of major components in our app from an older frontend framework to React with TS. It takes a while to get to even parity, it's tedious, and tricky to get right, and 3 of us are independently working on separate major bits concurrently. We also have other stuff, code reviews, meetings, Jira, other bugs to fix, and the 2 week sprint just makes it feel like I'm constantly on edge, because it's not going to be anywhere useful in 1 sprint or likely 2, and it doesn't offer any breathing room. Having more two week blocks rather less longer blocks of time also introduces more of the overhead that accompanies agile crap, and reduces time to get the stuff done even further. If we know it'll probably take 4-6 weeks to do something to the standard we want it, we should probably at least be doing 3 week cycles, or dynamically change it depending on our goals, but that never happens.

2 week sprints optimize for fast, poorer quality work, and much less of it, because for a healthy practice one needs margin. Margin to accept other pointless meetings, margin to deliver hotfixes, margin to do work carefully without burning out.

Yes, I'm cynical.

[s2th4d]

You're not the only one. I too am also doing somewhat of a similar migration with similar staffing and not enough time, and the project managers and product owners are more concerned ed about the dates they committed to than what us devs need to make it all possible. The last site works, but it has dragons and monsters under the hood.these things take time, but because us devs are not able to clearly estimate.the end of the line, we stick with the too tight time frames...

[tartoran]

Exercise saying “No” as much as you can. The less you say it the more it becomes a like a right stripped away.