I think that almost no one from the community has any hate for "Agile" as in the manifesto. Quite the opposite.
The problem is that the Agile that is pushed in the corporate world is nothing at all related to the spirit of the manifesto.
Management took over to keep control over developers.
So you have scrum, you have scrum masters, product owners, t-shirt sizes poker, ... All of that bringing more stress to devs than having empowered them to be trusted to deliver what the real client wants.
Can you provide me an actual way to practice these things? Like, specific, exacting ways to execute each of these? Or any of these? Because they don't make any sense.
"Value individuals and interactions over processes and tools". So, rather than put an update in a Jira ticket, DM it to a single person in Slack?
"Value working software over comprehensive documentation". So, never write documentation? And how do you define "working" software? What about features in development? (etc)
"Value customer collaboration over contract negotiation". Lol. I have never talked to a customer, in my entire career. I have also only heard about contracts, and usually they are ridiculous. I guess this is supposed to be different... but kinda hard to make it different if you aren't allowed to get close to a customer or a contract negotiation. (Why the fuck is this in an engineering guideline?? Do you find a lot of developers doing contract negotiation?)
> Value responding to change over following a plan
?????????? Does anyone know what the fuck this means?
....
The rest of the "12 principles" are equally stupid and nonsensical. They only "seem right" if you don't think about them for more than 5 seconds, and you live in some kind of fantasy world. It is absolute bullshit, completely disconnected from reality. (But boy do executives love to eat this shit up, because they will never have to figure out how to implement it)
Agile was a reaction to waterfall and other heavy-process software development practices. You have to understand the bigger picture to fit the Agile points in there.
For example your
>> Value responding to change over following a plan
> ?????????? Does anyone know what the fuck this means?
In waterfall, once you start developing, it's very hard to change something during the process. Due to Agiles iterative and incremental approach (principles 1 & 3), it allows you to change priorities, features, integrations, etc, during development.
New technology also allowed this iterative approach. For example in the past, software was released on disk or CD-roms, which meant a huge release cycle. Nowadays with SaaS, you can constantly release and improve your products (using CI or CD for example, widely adopted now).
Maybe you have to look into other software development processes to really understand what sets Agile appart, for example Waterfall, Spiral, Incremental, Rational Unified Process, etc. A good overview is here: https://en.wikipedia.org/wiki/Software_development_process
Maybe I'm not understanding it completely indeed. To make it more clear to me, can you explain what software development process you prefer so I can contrast it with the points of agile?
> “Value individuals and interactions over processes and tools". So, rather than put an update in a Jira ticket, DM it to a single person in Slack?
Stand up. Walk out of office. Get on train. Arrive at user’s office. Go sit next to user. Spend afternoon understanding how they use the software you are supposed to be building.
Bin the sprint planning, retros, gantt charts, standup and whatever fucking sprint poker is.
Go. Speak. To. User.
> “Value working software over comprehensive documentation".
> So, never write documentation?
Read the phrase again, with a slightly different word in place
Prefer working software over comprehensive documentation.
I.e. working on building the thing instead of obsessing about gant charts.
You can do a Gantt chart if you want. But focus primarily on the software. That’s more important.
> And how do you define "working" software? What about features in development?
Intentionally left vague. “Working”depends on many factors that only the people involved with the building of it can know.
Mainly by getting on a train and sitting down with your users to figure out exactly what they consider to be working software. See above.
> “Value customer collaboration over contract negotiation"
You’ve not been around much contract consultancy work then?
Hey, company X we’d like some software that does Y.
Do you
1. Enter into a lengthy process to establish exact requirements and agree on exactly what needs to be delivered up front, without having touched any software, and trying to cost it all out etc etc
2. Get on a train and sit with the user developing some proof of concepts quickly to figure out what the hell it is they want.
1 is waterfall and contract negotiation. 2 is responding to change. example is a user saying “oh, actually, could we try the page header in pink instead please” after asking for it to be blue last week.
> lol. I have never talked to a customer, in my entire career.
You’ve never spoken to a user?
You need to start.
Ideally right now.
Stand up. Walk away from your desk. Find a user to speak to. Ask them what they think of the software.
> Why the fuck is this in an engineering guideline?? Do you find a lot of developers doing contract negotiation?
Well it’s not in the contract so I’m not going to work on that feature because we won’t get paid for it.
Even though some enterprising engineer went and got on a train and sat with the user for a day and figured out “oh shit, we’re actually building the wrong fucking thing”.
Nope, not in the contract. User doesn’t get what they want because we negotiated a contract.
> Value responding to change over following a plan
Waterfall: We have an agreement and WILL ONLY BUILD ACCORDING TO THE PLAN. We will never deviate from the plan. The plan must never change. Ever.
agile: shit, I went and got on a train and sat with the user and we’ve been building the wrong thing. Time to rethink this.
> The rest of the "12 principles" are equally stupid and nonsensical. They only "seem right" if you don't think about them for more than 5 seconds, and you live in some kind of fantasy world. It is absolute bullshit, completely disconnected from reality. (But boy do executives love to eat this shit up, because they will never have to figure out how to implement it)
A lot to unpack here.
No, they’re not stupid. They may be “of their time” but they’re definitely not stupid.
They seem more right the more I think about them. I think about agile a lot and how to teach the attitudes contained within the principles to my juniors.
Just to reiterate the important point there — the principles are a collection of attitudes. They are not explicit instructions.
No, it’s actually useful. Would I base an entire team methodology solely on this? No. But it informs a significant part of it.
Executives don’t care about by he agile manifesto. Mostly because no one posts about it on linked in and they’d rather pay someone ridiculous sums of money to make the team “Scrum” and fuck about doing whatever the fuck sprint poker is (execs always want to spend money instead of doing the work).
According to the LinkedIn post it made some other team really efficient. They read about it on linked in. It must be true.
—
FYI — just because you don’t understand or see the value in something does not mean it isn’t valuable.
>> So, never write documentation?
>
> Read the phrase again, with a slightly different word in place
I spent way too many years working at an Agile shop that had been doing Agile for a very long time. (This is me saying "This place definitely wasn't Doing Agile Wrong.".)
At that place, "Prefer working software over comprehensive documentation" ended up actually meaning "Do not write documentation. Go speak verbally to the SME for that thing or section of code if you ever have questions. Documentation maintenance is a cost that we never have time to pay. Ditto for code comments... all code MUST be self-documenting.".
It -uh- didn't work out so well.
> You’ve not been around much contract consultancy work then?
Honestly? IME, this is about the ONLY environment where the Agile stuff makes sense. It's just such a very, very, very poor fit for long-running projects that require continuous work that may extend for decades.
> > You’ve not been around much contract consultancy work then?
> Honestly? IME, this is about the ONLY environment where the Agile stuff makes sense. It's just such a very, very, very poor fit for long-running projects that require continuous work that may extend for decades.
I disagree. Like, I was just working at a place that did both analytics consultancy and in-house products. Go. Speak. To. User. worked in both.
For consultancy, yeah we had to go off and sit with the customer and figure out with them exactly what they needed. Do iterative PoCs. Eventually work out, together, what the 'user'/customer wanted to get out of the project(s).
For product, I sat down with one of the lead scientists and asked her what she actually wants. Like, be real with me. It's me here. I don't care if you want to use the products or not. I want to help you do the job you want to do and help you solve those problems you face on a daily basis. What will help you do this.
Answer: Bin the vaporware in-house software product and move to an established off-the-shelf third party system (Benchling).
Repeated the same thing with Data Science.
(Eventual) Answer: Bin the vaporware in-house software product and move to an established off-the-shelf third party system (databricks).
Of course, that didn't fly with the management people who wanted their magical 'guaranteed revenue stream' (which didn't exist). They weren't Go. Speak. To. User.-ing. So they were divorced from the reality of what was going on and stuck in the blue sky management vision.
Agile-manifesto-agile doesn't just apply to engineering. You can apply the principles of Go. Speak. To. User. And. Stop. Making. Gantt. Charts. To. Solve. The. Real. Problem. to a lot of places.
Yes, but "Go speak to the fucking users so that you build the right thing" is such a tiny slice of Agile shit, and it's a product management rule that predates Agile by ages. This is like one of THE big things that Product and Field people are supposed to do, and has been for roughly forever.
As for the rest of Agile? Maybe the idealized Agile (just like the idealized Marxism) works great, but my personal experience at a place that very, very, very much was NOT Doing Agile Wrong[0], along with the personal experiences of an assload of others who work at Agile (and "Agile" shops) indicates that Agile as she is implemented in the real world is incompatible with long-running continuous [1] projects.
[0] I'm afraid you're just going to have to take my word that I know what I'm talking about here.
[1] "Continuous" as opposed to the "parachute in, mitigate the biggest problems, and then airlift out" engagements that are SOME of what contract shops are hired to do.
Is fine. Imaginary internet points are just imaginary internet points.
> It's clear people don't want to talk to users. But in the end, it gives people like us an excellent advantage.
The best kind of user to me is the one who is convinced they’re “dumb” when it comes to software. I always get so much more useful info from them compared to the folks who think they know something.
I don't think people are really unhappy with the manifesto, but with applied Agile as it is experienced out in the world where you're having your workday ordered by high powered productivity consultants and LinkedIn-brained middle managers.
Big A Agile is an exercise in making management happy because they read about it on LinkedIn while having a poo. It usually involves paying several consultants a lot of money.
In my personal experience, pretty much. Theatrically feigned agile is extremely aggravating and grating. Actual agile is in my experience fine and doesn't produce that kind of strong aversion because it 'just is'.
My main point of dislike is that I have never experienced the actual practices called "Agile" on the ground by the consultants/managers introducing them bearing any relation to the oft-quoted Agile manifesto.
"Value individuals and interactions over processes and tools", says the Agile consultant as they open the meeting; they then proceed to shut down any interaction between individuals that is not on the agenda, or that is on the agenda but takes longer than a sentence or two.
"Value working software over comprehensive documentation", says the Agile consultant as they open the sprint planning. "These tickets should contain enough detail that a new hire coming to them cold can pick up the work."
"Value customer collaboration over contract negotiation", says the Agile consultant. "Value responding to change over following a plan. Also, these items must be delivered by end of Q4; let's schedule some meetings with management to discuss why the team's burndown chart is going up and not down."
Agile is like true communism: always preached, never reached. It is a fig leaf for toxicity. The ideal true Agile practitioner cannot be faulted; and you will never encounter them. The word "Agile", when encountered in real-world corporate scenarios, does not mean the things described in the manifesto, though the manifesto will often be quoted; rather, hearing it invariably means the frog has reached boiling temperature and it is well past time for anyone who can still flee to flee.
"Agile consultant" is the modern term for an outsider that management have brought in to whip the thoroughbreds so that the resulting negativity falls on the outside party - which can then be let go again - and not anyone permanently employed by the company. We may want the word to mean nicer things, but that is not how it is actually used.
> "Value working software over comprehensive documentation", says the Agile consultant as they open the sprint planning. "These tickets should contain enough detail that a new hire coming to them cold can pick up the work."
A ticket that tells you what needs to be done / reviewed / tested is indeed in the pursuit of working software. Having detailed class diagrams drawn 18 months ago that you have to follow is what this point is talking about.
No one criticizes the manifesto itself I believe. But there's a huge difference between the abstract idea and principles of the manifesto, and an actual implementation that usually differs from company to company. So, yeah, the idea of babies is nice and all (everyone loves the manifesto), but you need to change diapers and that gets dirty. No one likes to changes diapers (no one likes Agile).
Many, many, many, maybe most people have implemented Agile as a recipe. Without understanding how it could work or why. Since they have no idea what they are doing, people who are forced to use this cargo-cult implementation find it onerous. Just another stupidity forced on them.
The question is how can people collaborate? That is the question. Complex Adaptive Systems (CAS) begins to help us think about how we can do that. Simplistically we can just throw bodies at problems and we get "the mythical man month" mentality. Or we can do it with militarism - we all get marching orders. Unfortunately, good programmers do not do well with this mentality.
So is there another way? At this point, as a community, we do not really understand how people work together. Despite the face that millions of people can live in a large city, we have no clue as to the mechanism that allows this to happen. $. The city does not degrade as the Mythical Man Month predicts, nor are the people ordered about in a militaristic manner. So what gives? How does that work? $.
Why do I keep putting $ in this post? Because $ is a "messaging bus". (You tell me a better word - signalling system?). Everyone can read (get money) and write (spend money) on this messaging bus providing signals to other people.
Agile is a very fuzzy attempt to provide a messaging bus. But if you have no clue as to the mechanism, you can descend into madness - for example "If one scrums are good what if we do ten a day?".
1. Value individuals and interactions over processes and tools
2. Value working software over comprehensive documentation
3. Value customer collaboration over contract negotiation
4. Value responding to change over following a plan
And then there are the 12 principles:
1. Customer satisfaction by early and continuous delivery of valuable software.
2. Welcome changing requirements, even in late development.
3. Deliver working software frequently (weeks rather than months).
4. Close, daily cooperation between business people and developers.
5. Projects are built around motivated individuals, who should be trusted.
6. Face-to-face conversation is the best form of communication (co-location).
7. Working software is the primary measure of progress.
8. Sustainable development, able to maintain a constant pace.
9. Continuous attention to technical excellence and good design.
10, Simplicity—the art of maximizing the amount of work not done—is essential.
11. Best architectures, requirements, and designs emerge from self-organizing teams.
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly.
So in total 16 points to cirisize! For everyone who hates Agile so much, please make it concrete.