15 ms·

Agile as a full-featured religious dogma (2016)

49 points by Melchizedek 7y ago

amadeuspagel 7y ago
See: https://slatestarcodex.com/2015/03/25/is-everything-a-religion/ https://slatestarcodex.com/2015/03/25/is-everything-a-religi...
- crimsonalucard 7y ago
  Yeah most things are isomorphic to religion. It's better to ask what isn't religious? Mathematics and science and all things isomorphic to either.
  - cjfd 7y ago
    When everything is a religion the word no longer holds any meaning. Maybe we should attempt to distinguish between a ritual and a habit? What is the distinction? I think the amount of emotion people attach to it. To me religion is like a hamster wheel for the emotional life of people. Too much activity with no observable gain. A habit is more reassuring and only lightly emotional in a lightly soothing sort of way. Agile could be a religion if it comes with lots of worry whether we are doing it the right way. It can also be a set of habits if you just do some practical things regularly. You all do understand that you cannot really be working together if you never talk in some kind of lightly structured way about what is to be done, right?
    - crimsonalucard 7y ago
      The article poses the question, is the agile structure the best way? Is it the only way? Also, people do not need formal "structure" to communicate concepts. Is strict formal structure over projects better or less strict? The closest way of knowing is to run scientific experiments. However, this is akin to running experiments to determine whether communism or capitalism is better. It's brutally hard to come up with an experiment or even the resources to run such a thing. This is the article's point. If there's no science or theory backing agile or OOP up.... why do we, by default, consider it the "best" way and make it so ubiquitous? His answer is religion. OOP and agile are religions.
      - kthejoker2 7y ago
        I guess I disagree that agile is defined by its structure. I think it's defined by its value proposition - that shipping early and often and getting direct feedback from users produces better products than not doing so. Which itself rests on the assumption that a product's value cannot be objectively asserted and is only the sum of its users' perceptions.
  - patcon 7y ago
    I've recently been intrigued by the Leiden Theory of language evolution. It basically suggests that language is perhaps better conceptualized as a separate organism that has co-ecological niche which happens to be the co-evolved biology of our minds. This semiotic organism is made of our neural components in a similar way to how simpler biology is made of atoms and molecules. http://www.himalayanlanguages.org/files/driem/pdfs/prague.pdf http://www.himalayanlanguages.org/files/driem/pdfs/prague.pd... It also has some hypotheses on how God is an invitable emergence from all language, as it is the base type: > The Leiden theory explains religion as a disease of language and predicts the existence of God and other such parasitic mental constructs as artefacts of language. God is the quintessential prototype of the non-constructible set because it can mean anything. This makes God the meme almighty. And so, in that viewing, everything contains elements of religion, because religion is just some sort of super-meme, like the catch-all mail filter when things don't yet match another category ;) (sorry, just read the other post on mail)
overgard 7y ago
Very anecdotal, but in my experience the higher employee turnover is, the more dogmatic a place tends to be about being "agile".
jacques_chester 7y ago
This analogy is starting to feel older than religion.
- pvg 7y ago
  It's telling that one of the early popular essays on the topic, "Extreme Deprogramming" (2003) is itself now a lost text.
compiler-guy 7y ago
I’m pretty sure the author’s exposure to agile wasn’t agile done right. Rather it was surely just someone who read a few books and didn’t implement it correctly. Is the above paragraph satire, or real?
- james_s_tayler 7y ago
  Hahahaha. You got me.
- crimsonalucard 7y ago
  I don't know if it's satire or real, but I would say it's definitely religious.
- Gibbon1 7y ago
  X can't fail it can only be failed.
crimsonalucard 7y ago
The person is actually talking about a broad range of things that don't just apply to agile. It's a little bad to compare this area to religion but, for agile, the analogy is apt because people feel it's the "only" way to do things. What this person is talking about is a part of engineering where no theory or science applies. Take these two examples: 1. Solving the problem of the shortest distance between A and B involves a line... this is covered by mathematical geometric theory. 2. The best way to travel from point A to point B in the United States is not covered by theory. The two examples illustrate a dichotomy: 1. Problems that can be solved with mathematical theory or science. 2. Problems that can be solved with "Design" Problem space 2 is the umbrella that agile falls under. Usually when we hit a problem related to 2 we employ the word "design." The design of a house, Object oriented design, the design of a bridge, the architecture design of the program, UX design... etc. etc. "Design" is a method to find a solution to a problem space that is either too complex or we have little theoretical understanding. Designing something is akin to guesstimating a solution. We do not have any proof that a "design" solution we arrived at is the "best" solution, we only know that it is "a" solution (after verification of correctness). Agile is like object oriented programming because both are methods created by guesstimation aka "design." There is no theory or proof (though there could be correlations) that either is the best possible solution. Agile is especially religious because of the specificness of it: A series of random rules to manage a project out of a solution set where trillions of rules and external factors apply. Intuitively, there is literally no way agile is the "best" solution. Until we can quantify the effectiveness of a project and until we experimentally employ other structures and methods for project management and SCIENTIFICALLY compare the effectiveness of all these methods can we begin to iterate toward a solution that is closer to "best."
mrkeen 7y ago
"Proper" (haha, yes I know) agile is anti-dogma. You throw out the rituals ("processes and tools", "plans") when they don't work. That's called a retro. How do you know if you're doing it right? You'll have "working software". That's a pretty subjective idea, so you'd better have someone to help you judge that, i.e. a "customer".
- crimsonalucard 7y ago
  Do retros allow you to throw out agile and retros? In practice I find retros to be a special place where engineers can vent their discontent and nothing will ever be done about it.
  - mrkeen 7y ago
    I worked somewhere where we made a conscious decision at a retro to not do them so often. But to be honest that was probably the most agile place I've been at. But perhaps good retros are the exception, not the rule. At the place I worked, we started with a pretty regimented scrum - Monday morning planning poker, fixed-length sprints, which were closed and groomed, etc. I hated that crap. There was also a tech lead bully that insisted on doing things his way, and would use the code review process to keep other people's code out of the system. It was a real death march. By the time we had the basics of the system running, it was a dozen layers of synchronous blocking code where simple REST requests would take between 2 and 60 seconds to complete. Eventually the bully left, and after that we eventually wore our (non-tech) team lead down into getting rid of discrete sprints and planning poker, and the devs tended towards just 'working on the next thing'. I think the biggest factors we had in our favour were: 1) The team lead (pretty much the boss, too) was not technical, so he had no choice but to leave the tech decisions to us. 2) The tech bully left us in such a shitty state that it became obvious we'd need big changes, rather than token ones. 3) We got quite a bit of rapport happening and eventually the team lead understood that we actually wanted to get the system working nicely. The devs also got better at pitching ideas, like why a certain large changes were necessary. I can't imagine we would have gotten to steer the ship in any meaningful way without a bunch of factors lining up like that.
  - 7y ago
hcarvalhoalves 7y ago
Agile is fine, but I believe it was born as an overreaction to Waterfall and excessive processes, the generation that followed blindly adopted it as a dogma, even when the project at hand doesn't benefit from it (also because "agile" is a great marketing word w/ positive meaning, and leaders suffer from FoMo.). People who've been at the trenches long enough seem to be waking up to this fact, and we must be careful to not overreact on our own. Agile seems great when both you and the customer have zero idea what you're doing, but not all projects are creating something completely new. I've seen enough projects fall into the trap of reinventing the (square) wheel by 1. not trying to state the problem correctly 2. doing zero research 3. not even interviewing more experienced people. Creating something that nobody asked for and failing fast is supposed to be agile, but agile says nothing about how to calculate risk/reward, or just assumes prototype are super cheap. That's rarely the case in practice - I've never see a prototype being tossed away, just turning into technical debt. Nowadays I much prefer the Cynefin framework [1] to reason about problems and projects, even if it's not super clear on how to apply, because it at least makes you consider two degrees of freedom. [1] https://en.wikipedia.org/wiki/Cynefin_framework https://en.wikipedia.org/wiki/Cynefin_framework
- eterm 7y ago
  You've made a good point and touched on something I feel is sometimes the case: Agile is used as an excuse not to spend money on market research.
- ryanmarsh 7y ago
  Agile coaches love to name drop Cynefin, having zero understanding of it and having never read anything of David Snowden's. Cynefin is great, but it is merely an abstract set of principles.
- ravenstine 7y ago
  Has any software or creative company ever actually adopted "waterfall"? It seems like a straw man used to criticize inefficient processes and promote Agile, but has it ever been implemented in the way that it's described? More importantly, is there any actual evidence that Agile is works better than alternatives?
ThrustVectoring 7y ago
I don't think "religious dogma" is narrow enough terminology to describe what is going on. The real distinction is between system-based and teacher-based ideas and practices. With a system-based idea (such as Newtonian mechanics), you can learn it and use it correctly merely by reading some set of canonical works. Everything you need to know is in a book, and if you understand the book correctly you get the right results out of it. Agile, on the other hand, seems to me to be much more teacher-based. If you want to know if you're doing Agile right, you have to talk with an Agile expert, and your own understanding is always under threat of being declared "not Agile" by the experts. The choice between approaches is a tradeoff, IMO, there's not one best way. Interactive teaching is better at accurately providing the state-of-the-art opinions and practices of experts, while systematic ideas are much more testable and falsifiable. If you want to copy what a successful expert does, go talk with the expert; if you want to know whether the expert is right or not, read their book.
- kthejoker2 7y ago
  I'd divide it differently: waterfall is process based, Agile is outcome based. You know you're doing Agile right when you have code in front of a user and they're telling you what they like and don't like and what they wish they could do but can't and are connecting your product to their goals and stories. Agile gives you some structure and best practices around shipping early and often, communicating ina particular way with stakeholders and your team, and measuring progress. But ultimately everything - ceremonies, comms, management, PM software - is subordinate to the idea of "a user using your product to do the things the product is designed to do."
theworld572 7y ago
Another way in which agile is like religion: its evangelists always have a jargon-loaded answer to every possible criticism of it. They really remind me of being a kid in Sunday school and asking the teacher questions like "but if god created all of us, who created god?" or "what if somebody was born and raised in the middle of the amazon and never even heard of Christianity - will he go to hell?". There was always some bizarre logic-twisting response to those questions which didn't really answer them but was enough to try and shut you up. Similarly, if you say "Agile doesn't work because X" - they will say "thats not REAL Agile...". But if you say "Agile is dogmatic" they will say "Agile lets you do what you want, its not a dogmatic rule based approach". So there is simultaneously one "real" way of doing Agile and also no real way because it is not dogmatic.
- UK-Al05 7y ago
  You sure your not getting these answers from different people? Someone new to agile might go on a scrum course and think this is the one way of doing agile. People who've been around awhile know you have inspect and adapt your process to specific implementations. There is no agile 'process' for this reason. It's also the reason agile mostly relies on having good people who can inspect and adapt. Agile is basically means creating a process that has been shown empirically work in your situation.
  - theworld572 7y ago
    Its true the examples I gave are probably a bit exaggerated but I think the general point still stands. I think you have even demonstrated that contradiction yourself although in a much more eloquent way? If Agile lets you inspect and adapt freely, then at what point does Agile does stop being Agile?
    - UK-Al05 7y ago
      When your forced to follow a specific process without any input. A lot companies are like that. Getting good at agile means getting good at inspect and adapt.
    - 7y ago
stillbourne 7y ago
I went to the Denver Agile conference a few months back and I mentioned to my boss that I felt the way they were presenting was very cultish. Instead of saying: if you follow this practice it has these benefits, I just felt the entire conference was a presentation on dogmatic adherence for the sake of holistic enlightenment. You must do this or condemn you entire project to the ninth level of programmer hell. If I wanted dogma I would go to church. I came here for a logical application of a standardized practices based on axioms not holistic bullshit.
ryanmarsh 7y ago
Agile Coach here. This is spot on. The field of Agile coaching, books, conferences, and personalities is the most self referential circus of bullshit anyone could dream up. Not to be a Talmudist but the vast majority of people who advise others on Agile haven't even read the foundational texts behind the prevailing theories. The truth is Agile in all its forms is merely a reaction to what came before it and has precious little basis in any sort of proven first principles. For all the ink spilled on Agile it has failed to produce a unified field theory. Instead it is a collection of camp fire stories, post hoc assertions, and petty disagreements over style. It's a bunch of fucking muppets. I hate most of my colleagues, I really do.
cryptozeus 7y ago
We had “agile coach” come in 5 months ago. Upper management completely changed all the processes. all teams were broken into scrum teams without consulting developers or other members. Everyone I have talked to is unhappy. Any random decisions are justified as agile. Is this normal process of adapting agile in the company?

49 points by Melchizedek 7y ago

See: https://slatestarcodex.com/2015/03/25/is-everything-a-religion/ https://slatestarcodex.com/2015/03/25/is-everything-a-religi...

crimsonalucard 7y ago
Yeah most things are isomorphic to religion. It's better to ask what isn't religious? Mathematics and science and all things isomorphic to either.
- cjfd 7y ago
  When everything is a religion the word no longer holds any meaning. Maybe we should attempt to distinguish between a ritual and a habit? What is the distinction? I think the amount of emotion people attach to it. To me religion is like a hamster wheel for the emotional life of people. Too much activity with no observable gain. A habit is more reassuring and only lightly emotional in a lightly soothing sort of way. Agile could be a religion if it comes with lots of worry whether we are doing it the right way. It can also be a set of habits if you just do some practical things regularly. You all do understand that you cannot really be working together if you never talk in some kind of lightly structured way about what is to be done, right?
  - crimsonalucard 7y ago
    The article poses the question, is the agile structure the best way? Is it the only way? Also, people do not need formal "structure" to communicate concepts. Is strict formal structure over projects better or less strict? The closest way of knowing is to run scientific experiments. However, this is akin to running experiments to determine whether communism or capitalism is better. It's brutally hard to come up with an experiment or even the resources to run such a thing. This is the article's point. If there's no science or theory backing agile or OOP up.... why do we, by default, consider it the "best" way and make it so ubiquitous? His answer is religion. OOP and agile are religions.
    - kthejoker2 7y ago
      I guess I disagree that agile is defined by its structure. I think it's defined by its value proposition - that shipping early and often and getting direct feedback from users produces better products than not doing so. Which itself rests on the assumption that a product's value cannot be objectively asserted and is only the sum of its users' perceptions.
- patcon 7y ago
  I've recently been intrigued by the Leiden Theory of language evolution. It basically suggests that language is perhaps better conceptualized as a separate organism that has co-ecological niche which happens to be the co-evolved biology of our minds. This semiotic organism is made of our neural components in a similar way to how simpler biology is made of atoms and molecules. http://www.himalayanlanguages.org/files/driem/pdfs/prague.pdf http://www.himalayanlanguages.org/files/driem/pdfs/prague.pd... It also has some hypotheses on how God is an invitable emergence from all language, as it is the base type: > The Leiden theory explains religion as a disease of language and predicts the existence of God and other such parasitic mental constructs as artefacts of language. God is the quintessential prototype of the non-constructible set because it can mean anything. This makes God the meme almighty. And so, in that viewing, everything contains elements of religion, because religion is just some sort of super-meme, like the catch-all mail filter when things don't yet match another category ;) (sorry, just read the other post on mail)

overgard 7y ago

Very anecdotal, but in my experience the higher employee turnover is, the more dogmatic a place tends to be about being "agile".

jacques_chester 7y ago

This analogy is starting to feel older than religion.

pvg 7y ago
It's telling that one of the early popular essays on the topic, "Extreme Deprogramming" (2003) is itself now a lost text.

compiler-guy 7y ago

I’m pretty sure the author’s exposure to agile wasn’t agile done right. Rather it was surely just someone who read a few books and didn’t implement it correctly. Is the above paragraph satire, or real?

james_s_tayler 7y ago
Hahahaha. You got me.
crimsonalucard 7y ago
I don't know if it's satire or real, but I would say it's definitely religious.
Gibbon1 7y ago
X can't fail it can only be failed.

crimsonalucard 7y ago

The person is actually talking about a broad range of things that don't just apply to agile. It's a little bad to compare this area to religion but, for agile, the analogy is apt because people feel it's the "only" way to do things. What this person is talking about is a part of engineering where no theory or science applies. Take these two examples: 1. Solving the problem of the shortest distance between A and B involves a line... this is covered by mathematical geometric theory. 2. The best way to travel from point A to point B in the United States is not covered by theory. The two examples illustrate a dichotomy: 1. Problems that can be solved with mathematical theory or science. 2. Problems that can be solved with "Design" Problem space 2 is the umbrella that agile falls under. Usually when we hit a problem related to 2 we employ the word "design." The design of a house, Object oriented design, the design of a bridge, the architecture design of the program, UX design... etc. etc. "Design" is a method to find a solution to a problem space that is either too complex or we have little theoretical understanding. Designing something is akin to guesstimating a solution. We do not have any proof that a "design" solution we arrived at is the "best" solution, we only know that it is "a" solution (after verification of correctness). Agile is like object oriented programming because both are methods created by guesstimation aka "design." There is no theory or proof (though there could be correlations) that either is the best possible solution. Agile is especially religious because of the specificness of it: A series of random rules to manage a project out of a solution set where trillions of rules and external factors apply. Intuitively, there is literally no way agile is the "best" solution. Until we can quantify the effectiveness of a project and until we experimentally employ other structures and methods for project management and SCIENTIFICALLY compare the effectiveness of all these methods can we begin to iterate toward a solution that is closer to "best."

mrkeen 7y ago

"Proper" (haha, yes I know) agile is anti-dogma. You throw out the rituals ("processes and tools", "plans") when they don't work. That's called a retro. How do you know if you're doing it right? You'll have "working software". That's a pretty subjective idea, so you'd better have someone to help you judge that, i.e. a "customer".

crimsonalucard 7y ago
Do retros allow you to throw out agile and retros? In practice I find retros to be a special place where engineers can vent their discontent and nothing will ever be done about it.
- mrkeen 7y ago
  I worked somewhere where we made a conscious decision at a retro to not do them so often. But to be honest that was probably the most agile place I've been at. But perhaps good retros are the exception, not the rule. At the place I worked, we started with a pretty regimented scrum - Monday morning planning poker, fixed-length sprints, which were closed and groomed, etc. I hated that crap. There was also a tech lead bully that insisted on doing things his way, and would use the code review process to keep other people's code out of the system. It was a real death march. By the time we had the basics of the system running, it was a dozen layers of synchronous blocking code where simple REST requests would take between 2 and 60 seconds to complete. Eventually the bully left, and after that we eventually wore our (non-tech) team lead down into getting rid of discrete sprints and planning poker, and the devs tended towards just 'working on the next thing'. I think the biggest factors we had in our favour were: 1) The team lead (pretty much the boss, too) was not technical, so he had no choice but to leave the tech decisions to us. 2) The tech bully left us in such a shitty state that it became obvious we'd need big changes, rather than token ones. 3) We got quite a bit of rapport happening and eventually the team lead understood that we actually wanted to get the system working nicely. The devs also got better at pitching ideas, like why a certain large changes were necessary. I can't imagine we would have gotten to steer the ship in any meaningful way without a bunch of factors lining up like that.
- 7y ago

hcarvalhoalves 7y ago

Agile is fine, but I believe it was born as an overreaction to Waterfall and excessive processes, the generation that followed blindly adopted it as a dogma, even when the project at hand doesn't benefit from it (also because "agile" is a great marketing word w/ positive meaning, and leaders suffer from FoMo.). People who've been at the trenches long enough seem to be waking up to this fact, and we must be careful to not overreact on our own. Agile seems great when both you and the customer have zero idea what you're doing, but not all projects are creating something completely new. I've seen enough projects fall into the trap of reinventing the (square) wheel by 1. not trying to state the problem correctly 2. doing zero research 3. not even interviewing more experienced people. Creating something that nobody asked for and failing fast is supposed to be agile, but agile says nothing about how to calculate risk/reward, or just assumes prototype are super cheap. That's rarely the case in practice - I've never see a prototype being tossed away, just turning into technical debt. Nowadays I much prefer the Cynefin framework [1] to reason about problems and projects, even if it's not super clear on how to apply, because it at least makes you consider two degrees of freedom. [1] https://en.wikipedia.org/wiki/Cynefin_framework https://en.wikipedia.org/wiki/Cynefin_framework

eterm 7y ago
You've made a good point and touched on something I feel is sometimes the case: Agile is used as an excuse not to spend money on market research.
ryanmarsh 7y ago
Agile coaches love to name drop Cynefin, having zero understanding of it and having never read anything of David Snowden's. Cynefin is great, but it is merely an abstract set of principles.
ravenstine 7y ago
Has any software or creative company ever actually adopted "waterfall"? It seems like a straw man used to criticize inefficient processes and promote Agile, but has it ever been implemented in the way that it's described? More importantly, is there any actual evidence that Agile is works better than alternatives?

ThrustVectoring 7y ago

I don't think "religious dogma" is narrow enough terminology to describe what is going on. The real distinction is between system-based and teacher-based ideas and practices. With a system-based idea (such as Newtonian mechanics), you can learn it and use it correctly merely by reading some set of canonical works. Everything you need to know is in a book, and if you understand the book correctly you get the right results out of it. Agile, on the other hand, seems to me to be much more teacher-based. If you want to know if you're doing Agile right, you have to talk with an Agile expert, and your own understanding is always under threat of being declared "not Agile" by the experts. The choice between approaches is a tradeoff, IMO, there's not one best way. Interactive teaching is better at accurately providing the state-of-the-art opinions and practices of experts, while systematic ideas are much more testable and falsifiable. If you want to copy what a successful expert does, go talk with the expert; if you want to know whether the expert is right or not, read their book.

kthejoker2 7y ago
I'd divide it differently: waterfall is process based, Agile is outcome based. You know you're doing Agile right when you have code in front of a user and they're telling you what they like and don't like and what they wish they could do but can't and are connecting your product to their goals and stories. Agile gives you some structure and best practices around shipping early and often, communicating ina particular way with stakeholders and your team, and measuring progress. But ultimately everything - ceremonies, comms, management, PM software - is subordinate to the idea of "a user using your product to do the things the product is designed to do."

theworld572 7y ago

Another way in which agile is like religion: its evangelists always have a jargon-loaded answer to every possible criticism of it. They really remind me of being a kid in Sunday school and asking the teacher questions like "but if god created all of us, who created god?" or "what if somebody was born and raised in the middle of the amazon and never even heard of Christianity - will he go to hell?". There was always some bizarre logic-twisting response to those questions which didn't really answer them but was enough to try and shut you up. Similarly, if you say "Agile doesn't work because X" - they will say "thats not REAL Agile...". But if you say "Agile is dogmatic" they will say "Agile lets you do what you want, its not a dogmatic rule based approach". So there is simultaneously one "real" way of doing Agile and also no real way because it is not dogmatic.

UK-Al05 7y ago
You sure your not getting these answers from different people? Someone new to agile might go on a scrum course and think this is the one way of doing agile. People who've been around awhile know you have inspect and adapt your process to specific implementations. There is no agile 'process' for this reason. It's also the reason agile mostly relies on having good people who can inspect and adapt. Agile is basically means creating a process that has been shown empirically work in your situation.
- theworld572 7y ago
  Its true the examples I gave are probably a bit exaggerated but I think the general point still stands. I think you have even demonstrated that contradiction yourself although in a much more eloquent way? If Agile lets you inspect and adapt freely, then at what point does Agile does stop being Agile?
  - UK-Al05 7y ago
    When your forced to follow a specific process without any input. A lot companies are like that. Getting good at agile means getting good at inspect and adapt.
  - 7y ago

stillbourne 7y ago

I went to the Denver Agile conference a few months back and I mentioned to my boss that I felt the way they were presenting was very cultish. Instead of saying: if you follow this practice it has these benefits, I just felt the entire conference was a presentation on dogmatic adherence for the sake of holistic enlightenment. You must do this or condemn you entire project to the ninth level of programmer hell. If I wanted dogma I would go to church. I came here for a logical application of a standardized practices based on axioms not holistic bullshit.

ryanmarsh 7y ago

Agile Coach here. This is spot on. The field of Agile coaching, books, conferences, and personalities is the most self referential circus of bullshit anyone could dream up. Not to be a Talmudist but the vast majority of people who advise others on Agile haven't even read the foundational texts behind the prevailing theories. The truth is Agile in all its forms is merely a reaction to what came before it and has precious little basis in any sort of proven first principles. For all the ink spilled on Agile it has failed to produce a unified field theory. Instead it is a collection of camp fire stories, post hoc assertions, and petty disagreements over style. It's a bunch of fucking muppets. I hate most of my colleagues, I really do.

cryptozeus 7y ago

We had “agile coach” come in 5 months ago. Upper management completely changed all the processes. all teams were broken into scrum teams without consulting developers or other members. Everyone I have talked to is unhappy. Any random decisions are justified as agile. Is this normal process of adapting agile in the company?