I’ve been working with Agile for years and I worked with people who burned out, but there was not even a single case where Agile contributed to burning out, directly or indirectly. In fact, Agile contributed to unload pressure off developers and prevent people from overworking and burning out.
The main factors in burning out we’re always time ranges from the enforcement of unrealistic schedules and poor managerial/team culture. It’s not Agile’s fault that your manager wants a feature out in half the time while looming dismissals over your head.
It’s not Agile’s fault that stack ranking developers results in hostile team environments where team members don’t help out people and even go as far as putting roadblocks elsewhere so that they aren’t the ones in the critical path. Agile explicitly provides the tools to make each one of these burnout-inducing scenarios as non-issues.
that managers want to stay in control of everything, and they decide whether they do it or not.
That’s fine, it’s a call from the manager.
That doesn’t make it Agile’s fault though. In fact, one of the key principles of Agile is providing developers with the support they need. Blaming Agile for the manager single-handledly pushing for something in spite of any feedback does not have any basis.
I have a cure for all cancers. Except that bodies refuse to use its molecules, but it still cures cancer in theory. That’s how agile have always been used around me.
Agile wants to empower devs, but managers do not want this.
Yes, yes it is. You don’t judge a system by some ideal that can’t be achieved. If it’s a system meant for humans you judge it based on what it does to said humans.
If agile makes managers more insufferable, then maybe it’s not a good tool for the problem at hand, working in companies with managers.
This is why you should always visualise and multiply by 4 when people ask for an estimate. If someone gives me a ticket that’s expected to take me 1 day I’ll let them know it’s very likely not going to be done in 1 day but rather 4 which I’ll finish comfortably in 3.
I’ve been working with Agile for years and I worked with people who burned out, but there was not even a single case where Agile contributed to burning out, directly or indirectly. In fact, Agile contributed to unload pressure off developers and prevent people from overworking and burning out.
The main factors in burning out we’re always time ranges from the enforcement of unrealistic schedules and poor managerial/team culture. It’s not Agile’s fault that your manager wants a feature out in half the time while looming dismissals over your head.
It’s not Agile’s fault that stack ranking developers results in hostile team environments where team members don’t help out people and even go as far as putting roadblocks elsewhere so that they aren’t the ones in the critical path. Agile explicitly provides the tools to make each one of these burnout-inducing scenarios as non-issues.
that managers want to stay in control of everything, and they decide whether they do it or not.
It’s like real communism: it’s perfect but it’s not possible to implement in our universe.
That’s fine, it’s a call from the manager.
That doesn’t make it Agile’s fault though. In fact, one of the key principles of Agile is providing developers with the support they need. Blaming Agile for the manager single-handledly pushing for something in spite of any feedback does not have any basis.
I have a cure for all cancers. Except that bodies refuse to use its molecules, but it still cures cancer in theory. That’s how agile have always been used around me.
Agile wants to empower devs, but managers do not want this.
Yes, yes it is. You don’t judge a system by some ideal that can’t be achieved. If it’s a system meant for humans you judge it based on what it does to said humans.
If agile makes managers more insufferable, then maybe it’s not a good tool for the problem at hand, working in companies with managers.
Agile is not a system. It’s a set of principles, set by the Agile manifesto.
The Agile manifesto boils down to a set of priorities that aren’t even set as absolutes.
I strongly recommend you read upon Agile before blaming things you don’t like on things you don’t understand .
true, scotsman
This is why you should always visualise and multiply by 4 when people ask for an estimate. If someone gives me a ticket that’s expected to take me 1 day I’ll let them know it’s very likely not going to be done in 1 day but rather 4 which I’ll finish comfortably in 3.
Ranking devs is toxic though
“Never tell them how long it will really take! How else will people see you as a miracle worker?” - Scotty
Underpromise overdeliver