"Agile has not only done a lot for making software development visible to the wider audience, but also for helping us avoid the so-called death-march: working all hours to meet some arbitrary deadline and screwing up our routine in the process."
IME Agile "Scrum" produces nothing but a series of every two weeks death-marches to "complete the sprint". I've had managers tell me "You have to complete it. Agreeing to do it means that you will do it by the end of sprint no matter how many hours you have to work. You 'promised it'!"
This leads to overly cautious estimations plus tons of extra hours because the task turned out not to be as simple or straightforward as the requestor's description said it was, but since you "agreed" to do it in the sprint, now you are obligated to do it by the end of the sprint.
Then this leads to garbage commits, hard coded secrets, and other cowboy coder shortcuts just so you can get some sleep.
I think the standard industry implementation of Agile is deeply flawed, and contributes toward more overtime, not less.
I have long since realized that it is up to me to push back on uncompensated overtime expectations, because companies and management will never do so.
I'm a developer with (way too) many years of experience, originally from the UK but now in NYC having co-founded a real-estate startup and an AI driven content engine platform.
It's clear agile can fail when problems crop up and I think I've been fortunate in that in my experience the developer's have had the deciding vote on what goes into the sprint as opposed to the requestor.
You're right to push back though. Often the requestor has no idea of the complexity of a given task and is under pressure themselves from senior people desperate to see something shipped. If they're good at managing upwards, they can create room for developers to give accurate estimates and deliverables without obligation to the death-march.
I guess we're at least lucky that agile breaks a project down into sprints as these problems are exponentially worse in a waterfall environment where the scope is much wider with a lot less visibility.
You said:
"Agile has not only done a lot for making software development visible to the wider audience, but also for helping us avoid the so-called death-march: working all hours to meet some arbitrary deadline and screwing up our routine in the process."
IME Agile "Scrum" produces nothing but a series of every two weeks death-marches to "complete the sprint". I've had managers tell me "You have to complete it. Agreeing to do it means that you will do it by the end of sprint no matter how many hours you have to work. You 'promised it'!"
This leads to overly cautious estimations plus tons of extra hours because the task turned out not to be as simple or straightforward as the requestor's description said it was, but since you "agreed" to do it in the sprint, now you are obligated to do it by the end of the sprint.
Then this leads to garbage commits, hard coded secrets, and other cowboy coder shortcuts just so you can get some sleep.
I think the standard industry implementation of Agile is deeply flawed, and contributes toward more overtime, not less.
I have long since realized that it is up to me to push back on uncompensated overtime expectations, because companies and management will never do so.
Thanks for your response and for the insight.
It's clear agile can fail when problems crop up and I think I've been fortunate in that in my experience the developer's have had the deciding vote on what goes into the sprint as opposed to the requestor.
You're right to push back though. Often the requestor has no idea of the complexity of a given task and is under pressure themselves from senior people desperate to see something shipped. If they're good at managing upwards, they can create room for developers to give accurate estimates and deliverables without obligation to the death-march.
I guess we're at least lucky that agile breaks a project down into sprints as these problems are exponentially worse in a waterfall environment where the scope is much wider with a lot less visibility.
Scrum is fine, garbage managers will find ways to be garbage managers in any possible framework