I first came across the phrase “Cargo Cult” in the book Surely You’re Joking, Mr. Feynman! by Richard Feynman. In the book, Feynman warned researchers against fooling themselves and thus becoming cargo cult researchers. The term is from a 1974 commencement address given by Feynman where he talks about learning not to fool yourself, because you are the easiest person to fool.
What is a cargo cult?
The cargo cults Feynman described were based on natives from the islands of Melanesia in the South Pacific. During the war, the islands of Melanesia served as a staging area for the military where they built temporary operations. The natives observed all the ways in which the allied forces landed the planes and learned the techniques. After the war, the planes stopped landing and the cargo disappeared. The cults decided that they must perform the allied rituals of landing planes and bringing out the cargo, and so they built runways, control towers, bamboo “headsets” and military uniforms.
Apparently they have learned the “rituals” very well, and continue to perform them in the hopes of bringing back more planes full of bountiful cargo. Unfortunately, no matter how well they duplicate the ritual, there is no result.
Waterfall: The Worst Cargo Cult
As I wrote this post, I realized that the Waterfall process is actually the worst cargo cult of all. Waterfall software projects fail at astounding rates, and we still create our gantt charts and do our huge designs up front, and wonder why the planes aren’t landing or why a simple project costs tens if not hundreds of millions of dollars to complete.
Asked for the chief reasons project success rates have improved, Standish Chairman Jim Johnson says, “The primary reason is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward.”
In 1970, W.W. Royce described a software development model in which each phase of the development process sequentially follows one another, and in the end results in a finished product. In this article, often cited by waterfall proponents, Royce points out that this “grandiose” model is prone to failure and recommends instead an iterative “feedback” model. Unfortunately this is the worst software process cargo cult of all because it never actually had anything to back it up as being a successful approach. The waterfall cultists stopped reading before they got to the conclusion.
In an ironic twist, about the time waterfall was losing popularity, the US military created a software development methodology called DOD-STD-2167 which not only reintroduced the otherwise failing software development methodology into widespread use, but lent it renewed credibility. I guess the natives weren’t the only ones easily fooled into hopeless ritual destined to failure. Somewhere some cargo cultists are laughing.
Unfortunately, cargo cults tend to yield to more cargo cults.
What does a cargo cult agile shop look like?
From the outside, it may look a lot like an actual agile shop. After all, a cargo cult shop is imitating what they have seen about agile. However, like waterfall proponents, cargo cult agile shops are led by people who have looked at pictures of agile models, “read” agile books, or “learned” agile development from PowerPoint presentations. Perhaps there are a number of developers who know agile, but they may not be able to move the company towards agility in the face of generations of managers and developers who have been indoctrinated by DoD-2167.
By definition, agility describes an ability to respond to changes. As such, any agile process is going to have some sort of iterative process in which the software is improved and responds to any changes that have occurred during development. In a cargo cult shop, keep a particular eye out for iterations that don’t include tasks other than programming. If the details of analysis, design, and testing are excluded, you are probably looking at a “cowboy” project or a waterfall project in disguise. An iteration should always include or consider changes. While possible, it is unlikely that the project will remain completely unchanged after an iteration.
With any agile process, the speed and effectiveness of adapting to change is the primary measure of how agile your team has become. If you are using an effective agile process, responding to change should be graceful. If a change causes a lot of disruption, or re-visiting a line of code that someone has already typed causes alarms to go off, you may be in a cargo cult.
If you are looking at a potential agile company, look at their process in as much detail as they will allow during the interview. If they use XP, ask to look at story cards. Do their unit tests actually test the functionality, or are they a check box to get past a sign-off? Are the story cards simply a requirements document created in one big design up front or do they add, change, and remove cards as they get further into the project. On a scrum project, ask how long a typical scrum meeting lasts. If their idea of a daily scrum is two hours, run, don’t walk, to your next interview because they have missed the point entirely.
If you are already in a cargo cult agile shop challenge your process. Good agile process encourages a constant feedback loop regarding both your product and your process. If an agile process isn’t working look into why and fix it. Go past the powerpoint presentations and the diagrams. Reproduce the results that created the processes you are attempting to emulate. If the agile process is printed and bound, and they haven’t made a single change to it in five years, it is highly likely they have not challenged and enhanced their process to fit their people.
Some agile models are a toolkit and give guidance on how to effectively use them, while other methodologies require practices to be used together to achieve a result. Some practices stand on their own while others may be interdependent. Understand the benefits and consequences of cherry picking from agile, especially if you are doing a project waterfall style.
Agile as a Cult
I am a fan of agile development in general because the Agile movement formally questioned and rejected the dogma of how software development should be done and, in particular, challenged the continuously failing waterfall model. Agile is just a step along the way and isn’t without fault and dogma itself. We sorely need to keep moving towards improving our understanding of successful software development.
Post-agilism is starting to take hold with a tempered view, absent much of the hype and absolutism that has formed in some Agile communities. I look forward to the thoughts of these people who refuse to be constrained by dogma and continually challenge how we write software. It is this sort of skepticism that I think Feynman is looking for when he says we must not fool ourselves.
Related links:
Cargo Cult Science
The Cargo Cults
Scott Ambler
Agile Alliance
Post-Agilism: Process Skepticism
Don’t draw diagrams of wrong practices – or: Why people still believe in the Waterfall model
There’s no such thing as the Waterfall Approach! (and there never was)
m