I'm inclined to believe proper agile is a myth. I have never seen it done correctly, and it's always spoken about ideally. All forms of agile I have seen or heard about always breaks down in real businesses environments.
It's not.
> I have never seen it done correctly
I have. And it wasn't hard. In fact, it seemed entirely effortless at the time.
https://news.ycombinator.com/item?id=36727366
The Agile Industrial Complex is a horror show, but that doesn't mean it's not possible to do agile well.
There absolutely is a way of doing agile well, I've been involved in a number of teams that did. And it worked extremely well. In fact, we did agile way before the agile manifesto came out, and before I was aware of there being a name for the things we were doing. We were just doing them because they make sense, they make us go fast and they let us have fun while doing it. Which is basically what the XP people said when they started writing things down. They never claimed to have invented a brand new way of creating software. No, they were observing that certain teams were very productive, and looked at what those teams were doing. If there was a pattern. Spoiler: there was.
Anyway, I also introduced agile "practices" in a large company. Well, in a small team in a large company. We didn't do a single one of the practices the Agile Industrial Complex proposes and often mandates. The much more important team next to us did. They did all the AIC practices. We did the technical. And interacted closely. Did TDD, worked on trunk, paired when necessary, did stuff alone when not. Did the simplest thing that could possible work. ("Where's your database?" "We'll put it in when we need it". <later> "Oh we're done. I guess we didn't need the database ¯\_(ツ)_/¯" ).
The more important team next to us that was doing Scrum with the standups and whathaveyounot failed. We delivered. Hmm.
And if you can point to the practices being promoted by the AIC as being in direct and obvious conflict with, for example, what's written the Agile Manifesto, and can in fact point to ways of doing it right that are in harmony with the AM and in conflict with the AIC, then it ain't a No True Scotsman fallacy. It's a simple case of the AIC doing it wrong.
In most companies, it seems management is incapable of measuring progress other than “will X be done before Y date”.
Awesome. It is a sight to behold and experience to savour.
> it required the team to be in control of its own destiny
Absolutely. If only someone had written this down. What a missed opportunity!
"The best architectures, requirements, and designs emerge from self-organizing teams."
https://agilemanifesto.org/principles.html
> goal reporting timetable.
"Responding to change over following a plan"
"That's not agile"
Has become one of the most annoying arguments I've ever heard. As someone who experienced a corporate takeover of agile "consultants", I can tell you, it is one of the hardest things to try and deal with people who have their own idea about agile.
"Proper agile" is too "team specific" that maybe it shouldn't have been a "manifesto", just call it good "team practices" and maybe it wouldn't have become such a cult
Now it has been abused to create a whole business with bullshit "agile coaches" who sell agile "bibles" and teach cargo cult.
It joins: - Innovation departments being built the least innovative departments you’ll ever meet - HR departments being the worst at dealing with people
Well, this strongly evidences that these agile coaches are fraudsters who don't know the elementary basics of their specialist field ... ;-)
All of this is to say that I agree with you. 'Agile Methodologies' are a crutch for companies that cannot tolerate agility
I've never seen it done poorly. It's the standard for a reason.
Across my sample size of about 7, half were maybe better than terrible, but only two were good enough where I would say it helped more than it hurt.
The tech industry I think would do well to more rigorously study "Agile" and do some A/B testing. Unfortunately this problem space feels like trying to A/B test forms of government. The downsides are generally known after the fact, are context specific, and there are few good ways to run a control
Yep. Because we currently don't have any way of clearly, concisely and obviously expressing the architecture in the code.
https://2020.programming-conference.org/details/salon-2020-p...
What if we could?
I'm starting to think that if we want to maintain this "race to the bottom" pace, we need a more industrialized/blue collar approach and be more less about the person and more about the tool. Most jobs in my area are web crud controlling a transaction script. there is no problem to solve.
I agree but I also wonder why we would expect them to.
Many coming into the industry have had little formal education in CS or SE. Employers providing substantial training is mostly a thing of the past because retention and professional development for employees has mostly been deprecated in favour of the rapid job-hopping culture. And for a while now it's been such an employee's market that developers haven't needed to invest their own time and money into professional development in order to progress their careers.
So even for relatively senior devs it's easily possible that they could have little academic education, little professional training provided by any of their employers, and little incentive to spend their own time studying. Their understanding might come from nothing but a few years of experience working on only 2 or 3 different products and - if they're lucky - some ideas they've been exposed to through more experienced mentors, team leads and code reviewers.
I personally believe our industry would be infinitely better if we could get back to the idea that professional development is important and employers should both look for people who've been learning and then support their people's ongoing learning themselves. Maybe we can even do that now that the gold rush is over and job-hopping every five minutes for a pay and title bump is no longer the most reliable way to climb the career ladder.