Unfortunately while the intentions around agile were noble it's pretty much a direct way to burnout or worse. The human mind is not designed to "sprint" run a marathon, metaphorically speaking, forever.
I see older devs being active in the trade well into their 60s but even as I much younger person I don't see how agile development is sustainable for a ~50-year career.
The thing is, the core agile points from the manifesto are pretty much universally fine and can pretty much be boiled down to, "make changes fast, get feedback, gain more understanding faster".
Pretty much everything that's been layered on top though has either nothing to do with the manifesto, or actively breaks it. i.e. there's a burning issue, I'll get to that after my sprint commitment, which was sold to let me finish work, but now only exists to stress me out to squeeze more widgets per unit of time, where the widgets pretty much never actually map back to anything actually tangible.
> Pretty much everything that's been layered on top
...and that /is/ topic of discussion every time this discussion happens
Every agile criticism conversation goes like this
A: agile as practiced is bad
B: but the manifesto is solid
It's predictable as the sun rising
Because it's true.
Scrum is like Spaghetti Carbonara in America. The ingredients are simple and there's a tiny bit of technique involved that anybody can figure out after a few tries. For some reason though almost everybody that makes it decides that they know better than the people that invented it and so adulterates it with peas and onions and garlic and cream and cream cheese and Italian seasoning and parsley and chives until it ends up being Olive Garden Alfredo. If they wanted Carbonara then they would have cooked the Carbonara, not the waterfall with a bunch of JIRA workflows and four-hour meetings layered on top. They just did what they would have done anyway while attempting to sound fancy via obfuscation.
"If it had ham, it would be closer to a British carbonara..."
https://www.instagram.com/reel/DK3aeJjyv98/?hl=en
It's not just Agile but the same applies to DevOps.
DevOps is a culture. It can also be the specific subset of highly skilled individuals who were part of or an outcome of said cultures cross pollination. Today DevOps most often means fairly unskilled person hitting pipelines with hammer.
In the end, the same old people with the same old commercial interests adopted the term in a way that benefited them but changed the meaning of the term because change was not actually something anyone wanted.
And usually:
C: Therefore you’re doing it wrong.
And once an “agile guru” enters the conversation:
D: You need my book / seminar / services.
Is agile the socialism of software development methodologies?
(Not for any deeper reason, only that whenever socialism fails, people tell you that 'real socialism' hasn't been tried, yet.)
It's the same with every *-ism.
That's not actually true. To give a silly example: does anyone (seriously) claim that 'true fascism' has never been tried?
Or: liberal democracy (I'm sure you can find a synonym that ends in *-ism) has been tried. It's been doing ok-ish. Obviously it has warts and all. But more importantly: approximately no one ever seriously claims that 'real liberal democracy' hasn't been tried.
Similar for constitutional monarchy, or 'social market economy', or dictatorships, etc. People can mostly agree that the real deal has been tried.
I don’t agree with that though, plenty of places practice agile well. Maybe big corporations don’t practice it well, but startups often do agile correctly and understand the philosophy.
Any principle or practice falls apart when tied to an economy. See also: religion, politics, society at large. I don't foresee that changing in our lifetimes, so make money doing it the wrong way, and do it the right way in your free time.
Nobody gives a fuck about the Agile Manifesto.
Inasmuch as Agile was adopted at companies, it's because it was sold to them as a way to provide greater transparency, accountability, and control into a chaotic software development process. The vice president behind the company's "Agile Transformation" probably can't even name point one of the manifesto; "we're doing Scrum with JIRA, therefore we're agile" is the extent of his concern.
You say that, but it was way more stressful pre agile with the fixed date, fuck around for a few months planning, then dev, run out of time then death march to finish, etc.
A lot of young guys like that D-Day style work, then goof off for a while, but not me. Continuous sustainable work is much preferred.
That's not really Agile's fault. That's PMs overcommitting the team. Those bad PMs would also make unrealistic waterfall schedules.
There's a difference between "bad PMs using the tool wrong" and "ordinary, human PMs using the tool in the way that common business incentives would lead you to predict they'll use it".
If the tool is used wrong most of the time, it's at least partially to blame.
"If the tool is used wrong most of the time, it's at least partially to blame."
Only if there were other tools that didn't fall victim to the same business incentives, but they all do.
I've had PMs that find a balance with the business incentives and make it work. If you’re human and make the wrong choices, then most people, including me, will likely call you bad in that context. If they can't stand up to find balance with the business incentives, then they're a bad PM. That doesn't make them a bad person.
I mean if something doesn't ever work in real life then its not good. Intentions aside.
I have seen Scaled Agile Framework (SAFe) work in multiple real program teams. Doing it successfully requires total commitment at multiple levels and many organizations are culturally incapable of making the transitions.
To be clear I am not claiming that SAFe is necessarily the best possible methodology. There is certainly room for improvement. But empirically it can work in real life.
The organizations I've seen do SAFe at the top level "coincidentally" have so much in the way of resources that if they do software at the group level at all, they do it like a gentleman farms.
"I mean if something doesn't ever work in real life then its not good."
Are you talking about Agile, Waterfall, or project management in general?
I've seen Agile work just fine. I've also seen it fail miserably. I've seen both of these at the same company with the main difference being how aggressive/delusional the leadership is. The easy test is if your leadership is legitimately ok with your team going home early if you complete your sprint commitment early, and it actually happens on occasion.
"Are you talking about Agile, Waterfall, or project management in general?" lol, yes
Agile isn't sustainable for younger people either. But they just get replaced by more younger people. Burn-out in IT is way too common.
It feels like over the past decade or two, every company that builds software has gradually adopted the same terrible practices as is commonly found in game development studios.
Since tech has largely stopped hiring younger people, sounds like a problem.
I have never seen Agile used correctly in practice. Its just mini waterfall with additional annoying ceremonies lumped on top.
That is why more advanced agile methodologies such as SAFe use the neutral term "iteration" rather than "sprint". It doesn't imply anything about team velocity or individual workload.
The term "iteration" was in common use by many of the big 90s proto-agile methodologies (think RUP et al). And XP - which I guess is what most people would regard as the first "true" form of agile - used it too.
SAFe is just an attempt to mush something that like looks like agile to delivery teams together with something that fits into more traditional program management, governance, and strategic direction lifecycle models.
There's no particular magic to it, and it's probably better to think of it in terms of being an "enterprise variant of agile" rather than a "humane variant of agile".
Yes, that's accurate. In the real world sometimes software programs have to make compromises in order to align with actual business needs. Like if you're going to be manufacturing hardware to go with the software or scheduling training for users then you have to apply strict program management discipline to ensure everything comes together at the correct time.
SAFe is not "advanced" Agile. It's training wheels Agile for managers and execs who can't give up control and devs who want to be told what to do.
Sure, that's fair. In the real world there are a lot of developers who want to be told what to do, or need to be told what to do because they lack business domain knowledge. A defined methodology like SAFe allows large enterprises to move forward at a steady pace and get some productive work out of those people.
The reality is that in some domains there just aren't many developers who are highly motivated, self directed, and thoroughly understand customer needs. Those people just aren't widely available in the labor market regardless of wages or working conditions. So if management doesn't impose a fairly strict methodology then then the program will collapse.
I'd make a separate case that learned helplessness is a reversible thing, and more highly motivated and self directed devs can be grown.
But leadership has to incentivize not just being a ticket monkey, and needs to mindfully empower people. You can't just flip a switch in a feature factory and say "fly my pretties, be free!"
Sure, that's also fair. But it takes a long time to turn culture around. And in the meantime the company has to continue shipping releases to customers or else they run out of cash and everyone gets laid off.
> developers who are highly motivated, self directed, and thoroughly understand customer needs
Why would someone with these qualities work for someone else?
In my experience of it though (only two workplaces, but not one) it's used for higher level planning, rather than being a 'more advanced agile'. I.e. a SAFe iteration spans some number of sprints greater than one. What are we going to deliver this quarter versus how are we going to break down and monitor progress of the quarter's deliverables week by week. (Don't read that like I like it.)
I think you're confused about the terminology. SAFe doesn't have sprints. Depending on the program planning horizon, several iterations can be grouped together into a larger program increment which typically lasts about a quarter.
I didn't implement it or name it, just worked in it.
Why is anything supposed to be sustainable for a ~50-year career? That’s a long time! Things change and people change.
It’s not like my great grandparents had a passion for farming in South Dakota and that’s why they did it until they dropped dead. It’s all they knew and what they did to survive.
If you gave them the option to tap on a keyboard in an air-conditioned room for 10 or 20 of those years they would’ve taken it.
Not so sure they would if they knew what it means, beyond tapping keyboards.
Too much software and you start turning into a computer, which obviously doesn't work very well.
They know it's not backbreaking labor...
Agile (or rather modern management) converts human capital into capital as fast as possible. Considering the endless supply of developers and lack of accountability there is no downsides to doing that, you are an externality.
Where can you get an endless supply of (good) developers from?
If you only hire young, there will be new yield every year.
There's a new yield of 40 year olds every year, too.
That doesn't make it endless.
Green cards
There's an endless supply of green cards?