4 ms·

The problem with "The Agile Manifesto" and the cargo cult that arose around it, is that while the manifesto pretty accurately described what a lot of people fel

The problem with "The Agile Manifesto" and the cargo cult that arose around it, is that while the manifesto pretty accurately described what a lot of people felt was wrong with the "Civil Engineering" approach to software development it never represented an reliable methodology for how to actually fix those problems. This is why we keep seeing those "no true scotsman argument" against any real world attempt to "be agile" where no failure can ever be seen as an argument against the usefulness of "The Agile Manifesto", and it's not really a new or surprising process but something that happens to most movements created around a loose manifesto. What will change things for the better is pragmatism based on observations and currently thats not the way the Agile movement seems to be moving.

exitb 3y ago
What if there is no methodology to Agile? What if the whole attempt is akin to finding a methodology for becoming a rockstar, or a famous painter? It kind of seems like the manifesto points out that the best way to create software is to get the right people and don't disturb them. And, if fact, if I try to think of examples of good software, this is usually how it came about, doesn't it? A small, talented, motivated group of people just working passionately on a problem. Obviously, though, this does not scale at all.
- jasonwatkinspdx 3y ago
  Yeah, I worked with one of the authors and their perspective was that conversations between developers and subject matter experts were what was primary, and methodology was just whatever helped a team enable that. They were quite disappointed with the consulting industry that sprung up and its many variations of "the one true way to do agile."
SAI_Peregrinus 3y ago
The other issue is that it was written by contractors, as advice for other contractors. It's not as applicable to long-term work for entire companies. "Customer collaboration over contract negotiation" doesn't apply at all for most engineers; they're not the ones negotiating the contracts!
mpweiher 3y ago
I have been on teams that were agile in the best way, and on teams that did Agile, in the worst way, though I am sure there is plenty of room on top and on the bottom. So I strongly reject your implication that it's not really possible to get it right and that all the consistent failures are true-scotsmanned away. Being agile is awesome, and it is not actually hard, with the right people and mindset. I also don't agree that the manifesto is as loose as you appear to think, as almost all the places where Agile falls down can be shown to be in contradiction to the manifesto. (Looking at you, Scrum, and you, Jira, etc.) However, it is fairly loose where many people would like it to be tight, that is in prescribing certain fixed processes. For example, nowhere in the manifesto does it say you should have lots of meetings and you should stand during those meetings, but for some reason that is one of the key takeaways people seem to have from Agile. The standups actually come from XP (which is sadly mostly ignored, though it contains most of the real gems), and are not even mandated. The key idea is to eliminate meetings altogether, and to keep the ones that the team finds unavoidable as short as possible by making them somewhat uncomfortable.
- lisasays 3y ago
  Being agile is awesome, and it is not actually hard, with the right people and mindset. And those with the "wrong" mindset -- i.e. who can't seem to force themselves to mouth all the nonsense and claptrap behind the Agile cult -- are just a bunch of uncooperative dolts, who you wouldn't want on your team anyway.
  - mpweiher 3y ago
    Ironically, it was exactly the worst teams that mouthed the nonsense and claptrap behind Agile, the Cult™. The teams that were agile didn't do any of that crap, never mind mouth it. We were busy getting stuff done. In fact, in one instance we had two of these teams right next to each other. The one that did all the claptrap of The Agile Cult™ right, the standups and whathaveyounot, and got cancelled, because they couldn't deliver (the software was still needed so the effort was rebooted). The other did no standups, no biweekly sprints, no retrospectives, no planning game, no story points, no epics or whatever. But we did do the technical practices such as TDD, YAGNI, DTSTTCPW etc. And we accomplished something that people, including many on the team, did not consider possible. And with a team that of people that were mostly not considered very good. And one of the best teams actually predated the Agile Manifesto by quite a number of years, and even XP was only publicised afterwards. When XP came out, there was a lot of recognition, a lot of what we were doing was XP. And there were definitely things we were doing differently, because our situations were not the same.

exitb 3y ago

What if there is no methodology to Agile? What if the whole attempt is akin to finding a methodology for becoming a rockstar, or a famous painter? It kind of seems like the manifesto points out that the best way to create software is to get the right people and don't disturb them. And, if fact, if I try to think of examples of good software, this is usually how it came about, doesn't it? A small, talented, motivated group of people just working passionately on a problem. Obviously, though, this does not scale at all.

jasonwatkinspdx 3y ago
Yeah, I worked with one of the authors and their perspective was that conversations between developers and subject matter experts were what was primary, and methodology was just whatever helped a team enable that. They were quite disappointed with the consulting industry that sprung up and its many variations of "the one true way to do agile."

SAI_Peregrinus 3y ago

The other issue is that it was written by contractors, as advice for other contractors. It's not as applicable to long-term work for entire companies. "Customer collaboration over contract negotiation" doesn't apply at all for most engineers; they're not the ones negotiating the contracts!

mpweiher 3y ago

I have been on teams that were agile in the best way, and on teams that did Agile, in the worst way, though I am sure there is plenty of room on top and on the bottom. So I strongly reject your implication that it's not really possible to get it right and that all the consistent failures are true-scotsmanned away. Being agile is awesome, and it is not actually hard, with the right people and mindset. I also don't agree that the manifesto is as loose as you appear to think, as almost all the places where Agile falls down can be shown to be in contradiction to the manifesto. (Looking at you, Scrum, and you, Jira, etc.) However, it is fairly loose where many people would like it to be tight, that is in prescribing certain fixed processes. For example, nowhere in the manifesto does it say you should have lots of meetings and you should stand during those meetings, but for some reason that is one of the key takeaways people seem to have from Agile. The standups actually come from XP (which is sadly mostly ignored, though it contains most of the real gems), and are not even mandated. The key idea is to eliminate meetings altogether, and to keep the ones that the team finds unavoidable as short as possible by making them somewhat uncomfortable.

lisasays 3y ago
Being agile is awesome, and it is not actually hard, with the right people and mindset. And those with the "wrong" mindset -- i.e. who can't seem to force themselves to mouth all the nonsense and claptrap behind the Agile cult -- are just a bunch of uncooperative dolts, who you wouldn't want on your team anyway.
- mpweiher 3y ago
  Ironically, it was exactly the worst teams that mouthed the nonsense and claptrap behind Agile, the Cult™. The teams that were agile didn't do any of that crap, never mind mouth it. We were busy getting stuff done. In fact, in one instance we had two of these teams right next to each other. The one that did all the claptrap of The Agile Cult™ right, the standups and whathaveyounot, and got cancelled, because they couldn't deliver (the software was still needed so the effort was rebooted). The other did no standups, no biweekly sprints, no retrospectives, no planning game, no story points, no epics or whatever. But we did do the technical practices such as TDD, YAGNI, DTSTTCPW etc. And we accomplished something that people, including many on the team, did not consider possible. And with a team that of people that were mostly not considered very good. And one of the best teams actually predated the Agile Manifesto by quite a number of years, and even XP was only publicised afterwards. When XP came out, there was a lot of recognition, a lot of what we were doing was XP. And there were definitely things we were doing differently, because our situations were not the same.