I don't really believe in an "Agile transformation." It's not as if most orgs can just stop what they're doing and transform into something else. The goal is not to "become Agile;" it's to solve specific problems using approaches that improve agility. Bit by bit.
You say you must produce crap code because "they're" forcing you to? Ofc, you'll be blamed when that code fails. A win is impossible. Make it so that you can live w/ yourself by doing the best work possible. The absolute worst outcome is the same as both outcomes for crappy work.
Putting it in a Scrum context. Stories are a couple sentences up until Sprint Planning. Then collaborate with customers & bus ppl to flush out details and split/narrow the scope of the stories as much as possible. Throw out the stuff that's not worth doing. →
Want to plan the number of things to pull into a Sprint? Use throughput (avg. # of stories completed per Sprint). If avg throughput is 4, pull in 4 stories. Doesn't matter at all what the stories actually are. Focus on the work, not the spec. Small stories increases accuracy.
The point of showing your software to someone else is to get feedback. "Stakeholder" feedback is not particularly valuable, tho. That's mostly about politics. To provide real value, you need feedback from actual users/customers.
Break up big stories into very small ones. Build the essential ones (customer literally can't get any work done w/o it) first. Throw out everything else. If your customers are not asking for the thing you removed, you never needed it to begin with.