It's very common. I'd bet most software projects still fail. I once met a guy who'd been a gamedev for over 10 years at some big companies, and every game he ever worked on got cancelled.

Sometimes these long, poorly managed projects do succeed though. Usually because they launch a beta or get publicly scheduled for release, and the sudden reality check causes someone senior to trim the scope down dramatically.

It might be worth sticking around if you think you're learning things, but impose some personal limits. Don't kill yourself trying to meet some idiot's impossible schedule. Work your contracted hours and no more. Be blunt and unashamed about how long tasks really take. Share your concerns when the month's schedule looks unrealistic, referring back to previous tasks that overran. This is how you learn to one day become a lead who doesn't run shitty projects like the one you're on.

This sounds like the old waterfall approach to development.

Design the whole system, create the whole system, test the whole system.

The problem with this approach is that requirements almost always change or scope creeps in those timeframes.

Now most companies are bad at agile. But even moving slightly towards it is better than nothing.

This will continue to happen until the project management changes unfortunately.

If the system can't be worked on in small independent chunks this is basically guaranteed to happen.

We do agile very loosely. But we have a two week sprint and at the end we, hopefully, have the features we decided on done and deployed. Then we can get feedback and add the required changes to the backlog for a future sprint.

This way you get feedback a lot quicker and as you pick work every two weeks you can keep things moving forward.

Chances are the company won't change so if it bothers you looking for another job may be a good shout.

Look for another job.

Companies like that are very unlikely to change their view that engineering’s quality and sustainability practices are a perpetual waste of money.

That, and product doesn’t know what they’re doing, and they’re okay with making engineering also suffer for it.

Nor do they care in practice about the engineers getting burned out.

After you leave, when you glance back at the company at any time for the next 5+ years, you will see that they have learned pretty much nothing.

I’ve been burned out once, and I’ll never let it happen to me again, or anyone I work with. It’s like depression; it’s an indescribable experience.

Here’s one self-test to measure how burned out you are: https://www.peoplestorming.com/burnout-assessment.

I don't have experience with that in particular. I'll share my more general, tangential thoughts.

MVP is minimal. Extending the scope like that makes me very skeptical (towards scoping and the processes).

Everything you are concerned with would be important topics for retrospectives, or even meetings with management. But of course those don't exist or are open in all environments. In my team I could openly raise such concerns.

If you're always rushing to a deadline, or feel like that, think of what you can do and influence to improve that. Retrospectives? Team disuscussions? Partly tuning out of management given focus and doing what you deem important and right? Look for a different team or employer?

@yournameplease These things are, unfortunately, pretty common.

OP admitted they were pretty green though, so they'll learn with time what makes a good employer for their work style.

Honestly, I'd say stick with it for a bit just to have the experience. Then move on to a different company, which will be a different experience. If it's better, they'll appreciate their new job; if it's worse, they'll know that their first job wasn't as bad as they thought.

In my experience this does happen on occasion, it absolutely shouldn't be happening all the time though.

Generally when this starts to happen my team lead puts his foot down and says, no more changes until you sign off on what we have and we've released the MVP. After all, if the core functionality is done, then the MVP is done and we don't need to keep sitting on it.

That's the agile mentality, where PO are pressuring you to deliver on your Sprint goals. In my opinion working on Scrums really burns down people

It's said that 80%-95% of software projects fail.

Of course, that was before we slapped the word "AGILE" on our planning document and kept doing the importany things exactly the same way.

So now the success rate is much better.™

Narrator: It was not.

What people miss is that the actual realized rate of project failure, in an average software team, is much worse than 95%.

A typical team isn't releasing 1/20 successes. They're doing much worse than that. (Edit: As GoodEye8 points out - most of this is due to how these teams are mismanaged. The same developers thrive in better run teams.)

Well structured teams with healthy habits consistently deliver dramatically better results.

So it's eye-opening to realize that the 5% of projects that succeed are, on average, being delivered by the exact same 5% of software teams, over and over again.

The reason this matters to you is: you should change teams. The next project very probably won't be better, in that team.

so maybe this is normal, but I’ve had the same story going on for over a year now, and it’s really starting to burn me out.

Get used, it's normal in some cases - projects that are most likely failing and will never deliver anything productive.

Think about this way, that . While they're postponing you're making a couple of improvements you're getting payed for something that is now very in your comfort zone and you've to do a little to no effort to deliver some progress.

This is a management issue, may have come from poor requirements, high expectations, ineptitude in software dev. project management or all of the above combined.

Your best course of action is to realize that it's not worth for you to burn yourself trying to deliver more than expected or jump ship. Just do whatever you've to do at the pace you feel comfortable, wait for the project to fail and move on. Jumping ship won't help you much, it will essentially degrade your professional image and force you to learn an entire new architecture of another project that may end up just like that one. :)

:/ im a bit jaded, so maybe this perspective isnt for everyone. I have abandoned several long term software projects from changing jobs and now try not to invest emotionally in my work projects. To compensate and keep enjoying software development I have a personal project that I am invested in but approach as a long term goal to avoid pressuring myself into completing it quickly and burning out.

Sit back, get some popcorn and keep those green eyes open.