Cargo Cult Everything

ScrummerFall.
Cargo Cult Scrum.
Big Agile Up Front.
Cargo Cult Extreme Programming.
Fake Lean.

For some reason, there seem to be a lot of people who "just don't get." What's that all about?

Well, my first answer would be that our development methods are often characterized by faith. People who have a faith /believe/. Hearing failure stories is disheartening. So it's much easier to simply pry and pry until you find something you don't like, then declare the person wasn't /really/ doing Agile, or XP, or lean anyway. The technical term for this is the "No True Scotsman" fallacy, where you claim no Scotsman could have committed the crime. Then, when it turns out the criminal was Scottish, you reply "well, clearly, he isn't a true Scotsman, as no true Scotsman would commit such a crime."

But I suspect there's more to it than that.

My opinion, my very strong opinion, is that companies exist inside a system of forces. For example: Consider two software teams.

Team A works for an IT shop of a large company. The software they write is developed and released only to employees - people inside the company. The VP of accounting can send an email to the entire company that says "From now on, expenses will be tracked with our ExpenseTracker application." Additional money spent on making the software pretty will not help adoption; everyone has to use the software to get reimbursed. The small projects are relatively isolated and only have to support one browser.

Team B works for a commercial, web-based software company. They make money by viral adoption of services. They need to support every popular browser - and ever popular browser version - on the planet. The software does a lot of complex, GUI thinks that use a large amount of javascript or flash.

Now imagine you are a 'coach' with experience with company A, hired to help team B.

You come on site. You learn the process of team B.

Why, team B has this complex regression test process - what waste! We need to eliminate that, move to weekly iterations, get the logic out of the javascript so that we can test below the GUI using some sort of business-logic application.

Sure. You could try that. And fail. And someone will come along and say you are doing 'cargo cult continuous release' or "doin' it wrong" or whatever. After all, what you /really/ need is scrum, or XP, or DSDM, or ...

Wait. Stop. Please. Here's a crazy idea:

Scrum, XP, Lean, Continuius Deployment, and KanBan all evolved to solve a specific problem that your team may or may not have. They also introduce problems that may or may not be a big deal for your team.

So to understand what improvement means, we actually have to model the system of forces, come up with a strategy, simulate it, see if it will make sense, try it, then adjust it over time. That's what a great deal of this blog is about.

But Jerry Weinberg suggested we have a rule of three, and I've only come up with two explanations for ScrummerFall and the Cargo Cults. What do you think?

UPDATE: I think it's worth noting that in the example above, the consultant is not a liar, a faker, or a charlatan - he could be /wildly successful/ at Company A and yet fail at company B. As an industry, we need to equip people to cross that chasm, instead of using universal labels and best practices. (Quick litmus test for a consultant: Get to a specific recommendation, and ask when that idea might /not/ apply. If he claims it's universal, be very careful. I used to say the best practices I recommended were things like "Wear deodorant", but Ben Simo pointed out that some people are allergic to deodorant ... :-)