Scene: Surprise meeting with the project owner 0-3 days before the go-live date
“Hey team, the business and I have decided to postpone the project release by n=1-3 months because [they aren’t ready for it / it isn’t finished /regulatory reasons]. And since we have some extra time now, we can tie up all the loose ends on this project (i.e., ‘we’ve added n+1 months worth of backlog items to the MVP’).”
I’m still a greenish dev, 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. In the beginning, I was optimistic. Now I just hope for the project to fail, or me to get off somehow, but this thing just won’t die.
Anyone with experience on similar projects able to share words of advice? Do they ever end up working out? Seems there’s a death spiral, since we are always rushing to a deadline, forgoing tests and quality but never cleaning up our mess because we’re already behind. Yet I somehow feel like I’m the crazy one for thinking this 6-month “quick” side project turned 2+ year half-rewrite will have trouble meeting it’s Nth deadline.
@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.
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.
deleted by creator
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.
I admit it’s possible the project “succeeds” and gets out the door. My prediction in that case is that we limp along and eventually give up after maintaining it for a while.
I only work my ~40 hours a week. When I did much more than that, I think my output went negative.
I think I learn a lot, at least. The project has a more “modern” stack than the company’s other main product. And management/leadership being hands-off means I make a lot of big decisions myself. Many bad decisions, but at least I learn what not to do next time.
If you see a real chance of it shipping soon, that might be good experience. As I mentioned, a surprising number of grizzled senior devs have never actually shipped anything.
But if you see better opportunities elsewhere then just go. Sad reality is that job hopping early is what gets most people a good salary. Very few companies give real raises. The only time you have bargaining power is when you haven’t joined yet or when you’ve already made plans to leave.
Sadly not. This post comes after my frustration of this same exact meeting, and now the project is delayed by a nebulous 2-4 (or more?) months. Sounds like I may actually be moving off of it temporarily since it’s been pushed so far back, to another, slightly less ambitious project that’s getting started. To be determined if I can help this next project go much better.
A big fear I had was that a failed project would reflect poorly on me looking for jobs. But hearing how common dead projects are, I guess it’s no surprise that many people go so long not seeing a successful one.
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?
It turns from Minimal Viable Product into Maximum Valuable Product!
Or Modified Viable/Valuable Product
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.
My experience has been that it’s often not the team that’s the problem, it’s the management. I’ve seen a team full of talented developers who know how to successfully launch, only to barely get anything done because management keeps reprioritizing everything. It seems in OPs case the org itself might be the issue. Even if they move to a team where the PO actually does their job instead of letting the MVP balloon the team keeps fighting business just to deliver something.
If I was OP I’d probably look for a job in a different company.
My experience has been that it’s often not the team that’s the problem, it’s the management.
Absolutely. Most developers are fine. It’s the management style of the organization that causes the continuous stream of project failures.
