I once worked at a place full of Agile cultists, including a bunch of "certified" "coaches." They spent about 1/4th of the time in planning meetings, retros, grooming sessions, sending emails about updating percentage complete on jira tickets, etc.

They made some of the dumbest technical decisions I have ever seen, were perpetually rewriting things, changing core APIs, breaking other parts of the system. The stuff barely worked, and this was after 5 years and dozens and dozens of developers.

The place was so dysfunctional, you could not even create your own branch in source control. You had to request it from the IT group that maintained the "enterprise" SCM server. The IT groups were doing their own form of Agile, so these requests could take weeks.

Truly awful.

Heh centralized teams to request something as simple as a branch to commit code... or to deploy a feature, and not at scale or anything, where “services” are a simple CRUD API with like 4 people who are customers.

Bloated IT organizations. Reminds me of working in the energy industry. Made up jobs, unmotivated workers, and incompetent management including the CTO. C level exec magazines says to literally eat shit? Here, let’s eat warm turds everyone.

Seems to me that place would have been dysfunctional with or without their dysfunctional form of ”agile”.

You are correct. The Agile-esque nature of the place was just added icing on the cake, so to speak.

I've worked in several places that each had their own unique snowflake take on "Agile".

With Agile being constant, the experiences were wildly different between them.

The key variable to whether they were dysfunctional or not wasn't Agile. It was the quality of the people in management.

My pet peeve with agile is it is so rigid at most places. Our team had a bug a while back. We all failed to understand something until it was getting QA'd. We told the PO that we'd need at least part of a sprint to fix it and asked if we could get that prioritized in the next sprint. You would have thought we'd asked to kill someone. We wasted a couple hours debating why it couldn't be finished in this the last day of the sprint. WTF?

This is literally the opposite of the agile manifesto and the original intent and the origins from Lean manufacturing.

Take a look at original agile folks who discuss this extensively on twitter.

Look at John Cutler's incredible blog posts: https://medium.com/@johnpcutler

The "Agile" most people complain about is the same thing we had before "Agile" came. You've got 2 broad camps: people who really want to do adhoc development and would like an industry accepted word to call doing whatever-the-heck-I-feel-like. The other side are the people who, having risen to a position of influence are desperately trying to add value, even though they don't actually do anything that results in code being written.

In the former camp, the people tend to like "Agile" because of the doctrine of writing code over doing planning. Often you will find PGMs/PMs who will write a story like "Make the site awesome!" with no other details. They usually want an estimate of how long that's going to take, but will refuse to add any more details -- because that's over-complicating the issue. They really just want to take credit for anything good that happened and punish people for anything bad that happened, all while doing absolutely no work. Usually they are actually deluded enough to think that their role is vital.

In the latter camp, usually there is a feeling that the programmers are stupid and this is why everything is in a complete mess. In order to fix things, they want to take control over everything and throw things over the wall at the programmers. Often the people in these camps used to be programmers (or may still think of themselves as programmers) and have always thought, "If only I could make everyone do what I want, then I can fix all the problems". So they spend their days dictating what everyone will do. It gets even more fun when similar people band together to form elite troops of specifiers -- that's where you get the endless meetings.

We've had this since programming in groups began. This is nothing to do with Agile. It wasn't any better at all before Agile. After Agile was introduced, nothing changed at all except now these guys have another name to incorrectly describe what they are doing.

My biggest problem with Agile is that it says nothing at all about how to accomplish the stated goals. That's why it is so attractive to people who don't have a useful methodology for producing software.

Do I want to continuously deliver software? Tick. Do I welcome changes to requirements? Tick. Do I want to deliver software frequently? Tick. Do I want business people working with software developers? Tick. Do I want motivated developers? Tick. Do I want to have face-to-face conversations? Tick. Do I want working software? Tick. Do I want to sustain a constant pace indefinitely? Tick. Do I want excellent software and design? Tick. Do I want simplicity? Tick. Do I want self organising teams (as long as "self" means myself)? Tick. Do I want the team to tune itself to get better? Tick.

Wow! I'm Agile! Whoo hoo! How do I accomplish the above? To quote someone I worked with in a previous job: "Most of this stuff is common sense. We're all the best in the industry and so this should be second nature to us. If anyone can't do these things then they really don't belong on this team". Now that's a strategy!

Mark my words: within the next 10 years there will be a new word for people to rally behind. At first it will make sense and some people will do cool things. But then the people who want to do nothing and the people who want to force others to do their bidding will grab the word and crush any meaning it ever had.

It’s not really common sense, and the agile I know of says quite a lot about how to accomplish goals, if your goal is “delivering quality software products/services”.

There also is bullshit Agile of course, which you describe well, but that’s no different from any old software process that’s more bureaucracy than content.

My point is that the cynicism ignores actual differences in practice and process that can have an order of magnitude impact on performance, and its not always “obvious” for smart people to adopt such practices.

Consider Lean manufacturing: the Japanese thought it was just a common sense extrapolation of Henry Ford’s system of organization. It still took decades for the US auto manufacturers (including Ford!) to wrap their heads around it.

There were plenty of crooks and charlatans in that field too. It didn’t negate the importance of what Toyota had figured out.

Brutal. Accurately brutal.

What’s your preferred methodology to Agile? Waterfall?

I quite like this as a good resource:

https://agilemanifesto.org/.

Whatever gets the work done and doesn't cause unnecessary burdens while adding no measurable value is good with me at this point.

I'd make do with anything but Agile, which needs to be shot. Out of a cannon. Into the Sun.

Genuinely curious, what is it that you don’t like about Agile? I mean, the concept, the processes? The lack of something or too much of something?

Not the parent, but I agree fully with their point - agile is good; but there is a difference between "agile" and "Agile".

Especially in the enterprise world, agile has been overran by worthless certifications and so-called "Agile" consultants/experts, who broadly fall into 1 of 2 groups: project managers looking to cash in, and technically inept "senior developers" looking to cash in by turning consultant.

Every one of which has their own incredibly dogmatic view of what it means to be Agile. And all of whom are skilled bullshit artists, adept at gaining the ear of upper management, proficienct at indoctrinating them into "the one true way"TM. Every one proficient at making developers miserable - all while charging exorbitant fees, and leaving just in time so management is convinced the failures are down to the heathen devs not following The Agile Way.

Standups where you literally have to stand up (simultaneously, even if spread across 3 continents and numerous time zones) and invariably go on for an hour, constant complaints (and of course meetings) about stories not finished before the sprint ends, endless meetings about the line on the bastard burndown chart, backlog refinements that last days or even weeks (invariably followed by story refinements that last days), telling the devs "decisions are up to the team... but you will choose my way", meaningless identikit retrospectives when the devs just want out so they can actually ship something...

Honestly, I'm not sure whether these "consultants" actually believe the dogmatic, quasi-religious snake-oil BS they are selling, or they know full well, but know just as well how much money they make from it.

All I know, is these people give agile a bad reputation, and bring absolute misery to many a developer.

GordonS gets it.

This is true. Not long ago (about six months) a project I was working on was assigned a scrum-master (tip: You can just be the person saying "any blockers?" and "next". You don't need to be master of anything.)

Genuinely nice person, it's anecdotal, but just making it clear I'm not bashing them. Regardless, after a stand-up in the very first week they just volunteered that they had no technical background whatsoever, and couldn't write a line of code. They were at the same time actively making architecture decisions outside of the stand-ups and relaying this to the P/O.

It was a nightmare.

The above is right, Agile (with a capital A) has become little more than a way for non-technical people to have lucrative careers in software by destroying the otherwise promising careers of technical people in software.

Appreciate you explaining this point further, I didn’t realise there was a difference between ‘agile’ vs ‘Agile’ and the only other methodology I had heard of was waterfall which also seems to be universally disliked.

"Agile" is just an instance of "agile" which is an abstract concept. Hence you can't actually do "agile". Therefore every form of agile you see is "Agile" and they're quote "doing agile wrong".

Read the manifesto. It literally says handful of almost completely meaningless, unimplementable things.

Any attempt to actually take that and turn it into something is destined to be sharply divorced from reality.

But the real fun comes when you do "white water rafting" style development. This is when there is all the ceremony of "Agile" (read: a "fast paced environment") with all the planning of waterfall and absolutely everything is top priority. You and your coworkers are constantly thrown around trying not to smash into rocks or capsize the boat, meanwhile being pulled violent in every direction. Somehow you continue to make your way down the river eventually with fewer and fewer co-workers as she casualties mount.

Fun times.

The actual methodology is completely irrelevant. Working under terrible management is terrible. Working under terrific management is terrific.

You should read the original waterfall paper as it is basically agile in spirit: http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...

Waterfall had its place in military and aerospace, where the requirements and API were well-defined, and to a lesser extent in life-critical medical systems development.

But in even those cases, it was largely replaced by Spiral, which is similar to agile and pre-dates it.

Edit: Spiral is like going down the Waterfall two or more times. Similar to agile, but formally documented, with management and customer sign-off up the line, and with a much longer cycle time.

My experience of that which has been called 'agile' is that it's an excuse by programmers not to do the boring stuff, so they can got straight into the coding.

Not to plan, or even think too much, definitely not to document (sometimes not write anything down at all), often not to test except in a token form and sometimes not even that.

Is that agile? That's how 'agile' has been done where I work anyway. Maybe I've been unlucky but 'agile' like that is a loathsome, unprofessional practice that can't produce good results.

Yes, I understand. While I’ve never only attributed that to Agile alone, but also this sort of brogrammer-code-is-the-real-product, it sometimes feels like a maturing industry sort of rolled back into its teenage years. Diagrams? Solution models (up front thinking)? Document for future reference? Nah, we don’t want to do that.

It’s sad. Just recently had an experience like this with developers I manage. I do loathe the brogrammer culture more than anything...

A significant chunk of software is a dead simple one off and does not need much in the way of design or maintenance. At the other end you have software that risks human lives and or billions in damages.

Picking the right process for where each project fits on that continuum is surprisingly difficult. Cowboy coding can be anything from a horrific idea to the most efficient setup, unfortunately people are rarely flexible enough to know the difference.

That’s why I always push the message that we choose the right amount of bureaucracy for the task at hand. Simple change / feature? No need to make a lot of documents for that? Fluffy idea that several people needs to work on? We need some mocks, diagrams and take requirements from client.

I think that’s a healthy way of doing it, but sadly many almost have to be pushed to do it, even with bigger things.

> feels like a maturing industry sort of rolled back into its teenage years

Beautiful description! That is so on the nail.

There are cult-like tendencies in part of the agile community. I don't see it in the teams I have worked in, but in forums on LinkedIn, by those that see their career as agile specialists, experts in coaching the true way to perform agile software development. Many of them see themselves as catalysts, and that they with clever questioning will make teams grow. They don't themselves want to have a delivery responsibility, but they want to stand on the sidelines and "coach".

That I can understand and I’ve seen that too. And now Scaled Agile Framework is coming in hot as the enterprise version.

I’m actually proud of the parts of agile we work with, which primarily enables us to react changing needs and priorities quickly (unlike heavy waterfall).

After 22+ years in the industry I’ve come to realize that any new concept or concept that gets traction (CQRS, Event storming, AI) will produce a religious following. It’s kinda sad, because causes as lot of noise and friction.

Shape Up sounds interesting, particularly for remote-only teams in non-massive companies. Haven't tried it but it sounds interesting.

https://basecamp.com/shapeup

agile, lowercase a, is not bad.

Right, I didn’t understand there was a difference. Thanks for that, I’ll look into it.

It is not a formal difference, but agile has evolved into an industry itself, with certification ladders and gurus. So on one hand you have the one page agile maniefesto, on the other people who make their living on preaching how teams should work, shouting from the sidelines.