
Agile as a full-featured religious dogma (2016) - Melchizedek
https://www.linkedin.com/pulse/agile-full-featured-religious-dogma-darius-blasband/
======
hcarvalhoalves
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)

~~~
ravenstine
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?

~~~
cglong
I was on a team at Microsoft that was strictly Waterfall; our business reps
wanted to release functionality in six month cycles, so Waterfall was a good
fit.

We eventually moved to Lean (a type of Agile) which worked well with this six-
month requirement. It gave engineers the ability to work on different pieces
and in whatever order they pleased, as long as everything landed in the six-
month block.

------
theworld572
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
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
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?

~~~
kthejoker2
I definitely fall strongly on the anti-dogmatic side.

Agile is built around the simple value proposition that shipping products
earlier, more often, and with more direct feedback from customers creates
better products. We might even call this "The Golden Rule" of Agile. (This
certainly verges on being a philosophy.)

If you believe that, and always act in accordance with that idea, and your
team and stakeholders and users do so as well, there's no need for dogma. You
will deliver great products and life will be good.

But the sad truth is a significant fraction of people are skeptics and cynics
and doggerels and hairsplitters and technocrats and incompetents and martinets
and apathetics and fusspots; in simple terms, they're only human.

So instead of one Golden Rule we have law after law after law and with law
comes lawyers on both sides (or pharisees if you like.)

But if you inspect and adapt according to the Golden Rule, you'll always be
doing Agile because you focus on the outcome and not the process.

Either you ship or you don't. Either you add value or you don't. Either you
talk to users or you dont.

~~~
theworld572
I'm not trying to be antagonistic but you sound exactly like the religious
people we're talking about. And your response still doesn't answer the
question - at what point does Agile stop being Agile?

Are you saying that any team that "ships products earlier, more often, and
with more direct feedback" is following Agile? If thats all that Agile is then
why do we need whole books on Agile, coaches, training seminars etc. if it can
be summed up in one short sentence?

EDIT: Your definitions is also a tautology - nobody is going to argue that you
should ship products late and with little feedback from customers.

~~~
AnimalMuppet
> at what point does Agile stop being Agile?

When you make it a procedure - especially when you make it a rigid one. "Let
us take this rigid approach to become agile" is just as stupid as it sounds.

> nobody is going to argue that you should ship products late and with little
> feedback from customers.

No. But some approaches result in more customer feedback than others do. So
_in practice_ , people do in fact choose to ship with less customer feedback.

------
compiler-guy
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?

~~~
crimsonalucard
I don't know if it's satire or real, but I would say it's definitely
religious.

------
mrkeen
"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".

~~~
ch_123
> How do you know if you're doing it right? You'll have "working software".

This is _exactly_ the problem - agile is never defined by itself, it is
defined in terms of some desirable outcomes. Project was on time and
succesful? Great victory for agile. Project failed? Need more agile in the
future.

In my experience, all this is used as a smoke screen by management types who
have no real idea what they are doing to externalize their own accountability.

~~~
UK-Al05
Agile = reflect and adapt.

Replace agile word with that in your paragraph and it makes sense without
sounding silly.

If you've done well you've probably learned and adapted.

If you havent done well, you probably need to reflect and work how to do it
better next time.

Things arnt 'proper' agile when they are not about adapting but instead
following a specific process your team cant change.

~~~
Melchizedek
So we as developers have the power to throw out things like daily stand-ups
and sprints? And if we don't have that power, we're not being agile?

Cool, tell that to your "scrum master" next time you see him.

~~~
UK-Al05
Yes, as a team you should be able to make that decision. A good scrum master
would want you experiment and improve if there is reason behind it.

The key thing is that the changes have to make things better. You should be
able try those things and see if they improve things.

Lots of teams use kanban, and some teams mob. If you mob as a team what's the
point in standups?

What's the point in sprints, if your continously improving, continously
releasing, continously getting feedback and able to forecast well without
them? Your better than scrum in my opinion then.

Scrum is a bit basic these days, but it's a good baseline start from. Thats
the problem with a lot scrum purists. They will never get beyond a fairly
basic level of performance.

------
ThrustVectoring
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
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."

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

------
cryptozeus
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?

------
crimsonalucard
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."

------
stillbourne
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
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.

------
jacques_chester
This analogy is starting to feel older than religion.

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

------
amadeuspagel
See: [https://slatestarcodex.com/2015/03/25/is-everything-a-
religi...](https://slatestarcodex.com/2015/03/25/is-everything-a-religion/)

~~~
crimsonalucard
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
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
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
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.

