Is Agile actually dying
Posted by branh0913@reddit | ExperiencedDevs | View on Reddit | 17 comments
I feel the more I hear about Agile, the more I hear it associated with negative experiences. Even for myself I have actually kind of grown a bit of a distain for agile. Whenever I go to interviews and ask about Agile and they say “yes we’re big on scrum” I almost whence. And it feels like my experiences aren’t unique. I’m constantly hearing how people just dislike it.
Now we all know the story. x and y aren’t doing real Agile. Or “scrum is the problem, not Agile”. Or “they are bastardizing scrum”.
I would say I’ve seen Agile work very well. But here is the secret. It only works on fantastic teams. However I think good teams are good with or without Agile.
And that’s why I think Agile could be dying. Because sure under the perfect circumstances, Agile works good. But isn’t the promise of Agile to fix broken processes or teams. If I can’t apply Agile to one of the worst teams, and it doesn’t make it better. Then what is Agile actually doing. The reality is that bad teams will never do true Agile or true scrum. And nothing about Agile prevents extreme bastardization of its ideas.
So what are your opinions? Have you seen Agile work well? Do you think there is a way to save Agile. If so what does that look like?
theavatare@reddit
Agile can’t die because is everything and nothing.
But im seeing more upfront work done in projects and longer iterative cycles or just kanban style with releases
ninetofivedev@reddit
This is correct. The "service" version of agile, which is what everyone refers to... is dying. Turns out hiring a bunch of college flunkies who spent 8 weeks getting a certificate certifying their "Agile" skills is all bullshit. Who could have seen that coming?
Now if your company is like "Hey, let's be flexible in our process, iterate on our product, deliver software bit by bit, and constantly try to improve our process and workflows"...
Well, you'll have more success.
diablo1128@reddit
Isn't that what Agile is at it's core?
My understanding is how you get there is something that teams were suppose to define on their own. That's because every team is different and has different needs from a process.
xcrszy360@reddit
It is..., the problem I think is the gap between principles and actual steps needed to get it implemented, that everybody has a different view on it
Also, I think most people don't work well under uncertainty, and when you try to force push constant changes to these people, what you get is get is resistance, and low engagement
diablo1128@reddit
This is definitely true from my experience. This is not just in terms of process, but just general work. I think I lucked out in this department because uncertainty doesn't bother me.
I have seen many SWEs get all flustered when they are giving some open ended task and are told to investigate, come up with a solution, and come back to them to discuss. I love these tasks because I feel like I'm in control and get to come up with ideas to how I think things should happen. If I'm wrong or miss things then I just take that as input moving forwards.
It seems like many SWEs I have worked with, from senior to junior, want clear tasks because they fear being wrong or something.
ArcanePariah@reddit
I think that's partially driven by fear from product/management, because those groups are even MORE fearful of uncertainty. So they seem to want to shift responsibility down to the engineers. Which might work except engineers are rarely given the power to make systemic change, so you get all the responsibility and consequence and no power to make things successful. Basically setup to fail. So engineers correctly want nothing to do with that, they want all the uncertainty removed BEFORE, so they can the deliver the certainty desired by management.
How many times have we heard stories of engineers asked to make an estimate only for that estimate to either be taken as gospel/hard commitment, or instantly ignored in favor of whatever the deadline is, decreed from on high?
The_Krambambulist@reddit
To add unto this, there is a lot less complaints if something takes less time than the other way around.
A lot of incentives to either pad the estimate or get to a place where a decent estimate can be made.
The deadline from above is just horrible, either results in shittier products or people working extreme overtime. Usually also with a lot more mistakes because people aren't well rested.
Key-Sympathy-3615@reddit
Amazing !
The_Krambambulist@reddit
Ow please we don't need more bots on Reddit, you ahole
ninetofivedev@reddit
Sure. That's what it's supposed to be.
But like most things, if it can be packaged up as a product or service and sold to the masses, it will be. Today, you can't talk agile without talking about a bunch of BS rituals that come along with it. Or worse, some completely bastardized version of it like SAFe.
Today if you join a company that is strict on agile usage, what you'll find is a bunch of bullshit ceremonies that everyone spends 80% of their work attending. Fuck all gets done. A bunch of people, who aren't your boss, act like they have decision making power. When their job is literally to hop on meetings all day and try and direct things they don't even understand.
Some companies probably have success with Agile. But more often than not, those are companies that abandoned the "service" model and did things their own way.
Key-Sympathy-3615@reddit
Amazing read!
AideNo9816@reddit
I don't know if it is or isn't and quite frankly I don't care to waste brain cycles thinking about it. If you got ten smart people and just let them get on with it I'm sure they'd negotiate a working style that would be effective. Way too much time and effort is spent on process rather than just letting adults work it out for themselves.
Existing-Camera-4856@reddit
You've articulated a sentiment that's increasingly common within the industry: a growing disillusionment with Agile, particularly Scrum, despite its initial promise. It's true that Agile tends to thrive in high-performing teams, but the fundamental question remains: can it truly transform struggling teams? The reality, as you pointed out, is that bad teams often resist or misinterpret Agile principles, leading to "bastardized" implementations that fail to deliver the intended benefits.
To salvage Agile's reputation, a shift in focus is necessary. Instead of rigidly enforcing prescriptive frameworks, the emphasis should be on fostering a culture of continuous improvement, collaboration, and adaptability. This involves educating teams on the core principles of Agile, empowering them to tailor practices to their specific context, and providing ongoing support to overcome resistance and build self-organizing capabilities. Tools like Effilix can aid in this by providing data-driven insights into team dynamics, workflow bottlenecks, and the impact of different Agile practices, enabling organizations to move beyond theoretical adherence and focus on measurable improvements in team performance and value delivery.
Sensitive-Ear-3896@reddit
In most places it never really lived.
byronka@reddit
Not many of you have been professionals in a wholly different field. I was a licensed architect before I became a programmer. Think bricks, steel, cranes.
We had ways of executing our work that would seem strange to an outsider. Even to a neophyte designer. But they worked - and the risk of failure and history of our profession ensured that we would continue to pass down those strange but correct ways of working.
In software, like any other knowledge-based endeavor, there is a wisdom that takes time and repeated failures to carefully develop.
That wisdom was named agile.
In bricks and steel architecture, there are state laws and organizations like NCARB that ensure all licensed architects will acquire that knowledge. There is a mandated internship process for the experienced architects to bring new people into the fold. Because the cost and risk are so high (people dying in fire, etc), it is incredibly important to continue passing that wisdom along.
Programming, however, is still an immature industry, lurching from one short-lived trend to another. The concept of carefully building long-lasting systems is a pipe dream for a huge percentage of our industry. Unfortunately, ambitious people sensed an opportunity to exploit the nascent agile and bundled a flashy but deeply flawed shallow version to anyone willing to pay, even though they had not acquired the hard-won wisdom themselves.
Management doesn't know any better. Business is interested in business, and since they are very often in direct control of how the programmers behave themselves, they do not realize what they are foisting on their technologists.
Each new generation comes along, finds themselves essentially unled, learns the wisdom the hard way, only to move out of the practice of programming and into management, at which point a new generation arrives. Rinse and repeat. When I say they learn it the hard way, I mean it takes years or even decades for mindful people to slowly experiment through trial and error to an improved path.
Our industry will continue along its lurching path until an external force imposes itself. At one point, engineers and architects did not need a license. Look up "Engineer's ring" on wikipedia. That summarizes the seriousness of their obligation.
mjukvarecom@reddit
Yes, this answer is possibly the best I've seen on why tradition, expertise, and internship matters, and why "agile" in modern organizations is terrible.
Management imposing some stupid, shallow version of agile onto its development teams is just insane to me.
Own-Score-105@reddit
I appreciate this insightful discussion on the effectiveness of Agile methodology. It's concerning how Agile has evolved into a rigid process filled with unnecessary meetings, which often detracts from its original intent of flexibility and team empowerment. Many teams struggle with its application, especially when faced with inexperienced members or rigid frameworks like SAFe.
What I find interesting is the potential for tools that can enhance Agile practices without forcing teams to abandon their existing workflows. For instance, Effilix aims to streamline Agile processes without imposing strict changes to how teams operate. It provides real-time insights and supports Agile frameworks, making it easier for teams to identify what works for them. This kind of approach could help mitigate some of the frustrations mentioned here by ensuring that Agile remains true to its core principles of collaboration and iterative development.
Have others had experiences with tools that complement their Agile practices without dictating how they should work?