The cult of Agile

The case against Agile (and a counter proposal)

Hi all - this is a work in progress. I'd very much like to get your feedback - both positive and negative. Please explain your reasoning. I'd also like your input - could you help me phrase some of this stuff better. At the moment this is more of a 'stream of thoughts'...

Thanks.


I propose that Agile in some ways is to many people, similar to a cult.
From Characteristics Associated with Cultic Groups  :

‪The group displays excessively zealous and unquestioning commitment to its leader and (whether he is alive or dead) regards his belief system, ideology, and practices as the Truth, as law.

‪ Questioning, doubt, and dissent are discouraged or even punished.

‪ Mind-altering practices (such as meditation, chanting, speaking in tongues, denunciation sessions, and debilitating work routines) are used in excess and serve to suppress doubts about the group and its leader(s).

‪ The leadership dictates, sometimes in great detail, how members should think, act, and feel (for example, members must get permission to date, change jobs, marry—or leaders prescribe what types of clothes to wear, where to live, whether or not to have children, how to discipline children, and so forth).

‪ The group is elitist, claiming a special, exalted status for itself, its leader(s) and members (for example, the leader is considered the Messiah, a special being, an avatar—or the group and/or the leader is on a special mission to save humanity).

‪ The group has a polarized us-versus-them mentality, which may cause conflict with the wider society.

‪ The leader is not accountable to any authorities (unlike, for example, teachers, military commanders or ministers, priests, monks, and rabbis of mainstream religious denominations).

‪ The group teaches or implies that its supposedly exalted ends justify whatever means it deems necessary. This may result in members' participating in behaviors or activities they would have considered reprehensible or unethical before joining the group (for example, lying to family or friends, or collecting money for bogus charities).

‪ The leadership induces feelings of shame and/or guilt in order to influence and/or control members. Often, this is done through peer pressure and subtle forms of persuasion.

‪ Subservience to the leader or group requires members to cut ties with family and friends, and radically alter the personal goals and activities they had before joining the group.

‪ The group is preoccupied with bringing in new members.

‪ The group is preoccupied with making money.

‪ Members are expected to devote inordinate amounts of time to the group and group-related activities.

‪ Members are encouraged or required to live and/or socialize only with other group members.

‪ The most loyal members (the “true believers”) feel there can be no life outside the context of the group. They believe there is no other way to be, and often fear reprisals to themselves or others if they leave (or even consider leaving) the group.

  - You must believe in Agile

  - Disbelieve in Agile is punishable by ostracism  (this is just personal experience - need to have better backing than that)

A good software methodology does not require you to believe in it in order for it to work. (self evident or does this require a proof?)

  - Failures cannot be attributed to Agile. The reason you failed was because you were not Agile enough...

  - Agile is for everyone. It is a 'one size fits all' methodology.

Even the 'ceremonies' sounds 'cult-ish' (this criticism is meaningless - remove or  tie it back to a previous point).

You must tithe to Agile in the form of literature, courses and consultants. Attempts to 'go it alone' will be met with calls of ''but that's not Agile!" (I don't like this wording)

A good software methodology does not require you to spend any money, seek professional help/hire consultants in order for it to work.

  - This is virtually guaranteeing that the cycle is repeated (? try to present idea of self fulfilling prophesy)

You should not need a product manager to write a user story etc etc etc .... to fix the text on a button control. (What is the Agilist's rebuttal here?)

Agile doesn't seek the 'right answer' - only an average answer

  - people playing cards to guess how long something will take

  - smart people in the room are overridden/outvoted by the mob

With Agile, developers are considered as interchangeable cogs in a machine

  - Agile doesn't encourage the individual to work on the parts they are most familiar with (true? needs backing up)

Agile doesn't work well for teams that are geographically distributed. (Put in difficulties with team standups)

Fixed width sprints are too arbitrary and fail to be useful. New work (e.g. features) should be demonstrated to the customer as soon as possible (e.g. a tech preview - even if it is smoke & mirrors) and a final demo when finished/complete.

Velocity is a broken metric. As far as I know, all metrics can be gamed. Any subtle changes render the metric meaningless.

I believe that Agile is simply the next 'fad'.

Agile does not present a silver bullet to software development.

I believe that Agile like previous fads, simply emphasises aspects of software development differently to other methodologies. This approach cannot be appropriate in all circumstances.

Good software development is about making good choices.

I believe that good software cannot be produced by just tweaking the method.

Good software requires people to be proficient at their work.

Smarter people are more likely to make smart choices - wisdom of the crowd does not work with small scrum teams.

Opinions/estimates of people who are less knowledgeable in a particular area should not carry the same weight when it comes to making decisions.

"A better way" should identify the best person/people for the job and have them work on the development of feature/defect/whatever. Others on the team are to provide support (wingman). Support might be taking sub-tasks from the 'lead' coder on the defect/features, setting up reproduce-able test cases, reviewing log files, reviewing code, QAing alpha/beta builds, running performance tests, analysing for security vulnerabilities, writing automation, writing documentation, provisioning resources, updating project management/time tracking software and (possibly?) liaising with the customer.

To the very best of my thinking ability - this approach yields the fastest time to delivery of fix/feature.

(Criticism - this does appear to lack parallelism. Perhaps this only applies to 'unknown' tasks? Could the 'yep - that's simple' task be considered differently to the 'my best guess' task.)

 

A feature must be considered done by all prior to the feature being considered done. This can be known as 'riding your kill'. (is there a better phrase?)

*quote: > Keep your eyes on the enemy and do not let him deceive you with tricks. If your opponent appears damaged, follow him down until he crashes to be sure he is not faking. *

More to follow....