From stalking to hacking attempts, since I began work on researching the high failure rate of Agile projects and transformation initiatives, I’ve come face-to-face with the fundamentalism that exists amongst Agile’s most devout followers.
When a faith healer’s vulnerable patients succumb to a disease as a result of a sham treatment not working (having usually ‘donated’ a considerable amount of money), the ‘healer’ will often claim it is the patient’s fault as they did not pray hard enough. This has been a topic explored at length by Derren Brown in the TV special Miracles for Sale and theatrically in his Netflix special Miracle. Such a fallacy is often described as a version of the “No true Scotsman” fallacy or an “appeal to purity.”
Fundamentalists in the Agile community will often use similar claims when Agile projects will fail. For example, in the article “Failing at Agile? You’re Doing It Wrong“, Greg Kihlstrom writes:
As an example, you could have the most enthusiastic Scrum Master possible on your team, but if the product team has some naysayers or those who simply don’t follow through or understand what needs to get done, you are going to have challenges. Sometimes this is a matter of education or coaching, and sometimes this is a matter of team dynamics and culture. Determine what is the cause and deal with it accordingly.
However, the scientific basis for such a belief does not exist. A November 2021 paper entitled ‘“Best Practice” without Evidence – Agile Software Methodology as Example’ conducted a meta-analysis of numerous reviews of scientific Agile studies and found: “The result of the tertiary study is that, indeed, the evidence for the Agile methodology is scarce at best.”
However, this is far from the only cognitive bias adopted by those who take a fundamentalist stance when it comes to Agile. In this article, I would like to focus on the strawmen that are often used to justify the Agile methodology.
What is an Agile Strawman?
On LinkedIn’s Agile community, it’s not uncommon to see posts like the following – seemingly a conversation that makes an Agile practitioner seem quick-witted and vindicate the methodology in the face of a software engineer who dares question it. It is my personal opinion that these conversations seem to be generally fictitious:
The Oxford English Dictionary provides the following as a definition of a strawman:
In an argument, debate, etc.: an intentionally weak or misrepresented proposition, set up because it is easier to defeat than, or deflects attention away from, an opponent’s real argument, giving the superficial impression that the original charge has been refuted or defeated.
However, there are far more deep-rooted strawmen that appear to go to the very heart of the Agile proposition.
An article on the SecretGeek website put forward the question: “Is ‘Agile’ a religion? (or merely a cult)”. Whilst the author asserted that the other dogmatic elements of Agile were indeed in place, from rituals to doctrine, the one area they were on the fence about was whether there was a ‘mythology’ in Agile.
I believe these strawmen are fundamentally what forms the mythology of Agile.
The Waterfall Myth
It is hard to see Agile discussed without discussion of Waterfall. A supposed project management methodology that Agile stands in contrast to. A methodology that requires strictly documented steps and never making any changes.
However, this begs the question, where are the Waterfall conferences or user groups, even historically?
Perhaps the origins of the methodology will provide us with some clues. In Jon Pearce’s lecture notes at San Jose State University, he states: “The Waterfall Lifecycle Model is the straw man of lifecycle models. It was first described in 1970 by Wynn Royce as an example of a flawed process…”
The software developer Christian Findlay made a similar point in a post on X stating: “The waterfall approach is a straw man that never really existed”.
However, the situation becomes murkier as we delve further into the history of the Agile.
The Toyota Myth
The Toyota Production System (TPS) is the spiritual birthplace of the Agile methodology. Despite the overwhelming majority of transformation initiatives failing, many will point to the methodology used by Toyota.
However, Toyota itself has a less-than-ideal history when it comes to software engineering. A report in Capitol Weekly states that, “Without admitting liability, Toyota since 2014 has settled 537 claims blaming sudden acceleration for crashes that killed or seriously injured people, according to a court document Toyota filed” in September 2019.
These unintended acceleration defects were not just fatal in numerous cases, but in the case of Koua Fong Lee, the defect led not only to a car crash that killed three people and injured others when driving his pregnant wife and children home from church but also led to him being blamed and sentenced to prison. In court proceedings, Toyota had attempted to counter a theory of why the vehicle behaved erratically with claims of robust testing protocols, but shortly before trial, Toyota filed a declaration from that engineer stating that the company actually did no such testing.
After refusing to take a plea deal that would have freed him but left him branded as a criminal, Lee was ultimately freed after a retrial was ordered, and the prosecution refused to put the case back to court.
The case of Bookout V. Toyota brought Toyota’s software engineering practices to focus after another unintended acceleration defect led to fatalities. During these proceedings, which ultimately found that the software systems could cause unintended acceleration, evidence was shown, including internal communication within Toyota stating “in truth, technology such as failsafe is not part of the Toyota Engineering division’s DNA”:
Following this case, Toyota was reported to have adopted a traditional approach to software engineering for high-reliability projects, using the SPARK Ada language where strict design contracts help mathematically verify the correctness of software – an approach adopted in high-reliability environments such as aviation and defense.
This approach, known as “design-by-contract,” was originally invented by the French software engineer Bertrand Meyer, who himself wrote the book “Agile!: The Good, the Hype and the Ugly”. Amongst Meyer’s criticisms of Agile are the deprecation of upfront design and the focus on user stories over generalizable specifications.
These criticisms are described in more detail in the video – “The Ugly of Agile (with Dr. Bertrand Meyer)” by Edensoft Labs:
Conclusion
The various strawmen in Agile highlight to us the importance we all must have in being critical before adopting solutions that have not yet proven their efficacy. Don’t get me wrong, we don’t need meta-analyses of systematic reviews of randomized control trials to make every judgment in life, but we should be careful when discounting evidence of a higher evidential basis than that of a lower evidential basis (such as those presented to us as dogmatic truth by authority figures).
As humans, the stories of transformation, despite the odds, tug at our heartstrings, and we all want to believe there are superheroes who can heal us. However, blind cynicism too can often lead to us shielding ourselves away from the advances that progress society. By seeking to ignore these emotional aspects rather than acknowledge them, we find ourselves more at their mercy when we try to form rational decisions.
One of the things I found most remarkable since I wrote the book “Impact Engineering: Transforming Beyond Agile Project Management,” is how the most dogmatic on either side of the Agile opinion divide will ignore the emotional and psychological aspects that indeed form the bulk of the book and are, what the evidence shows to me, rests at the heart of truly successful transformation initiatives.
This presents a stark reminder that before we go too far down the rabbit hole, we must remember that the lessons of science and engineering are that questioning orthodoxy and collecting evidence rest at the heart of truly remarkable discoveries.
This article was originally published by Dr Junade Ali on HackerNoon.
