You sometimes hear about “Cargo Cult Agile”, and you might be wondering what that means. It’s a cute term with an interesting and funny history. But the thing itself is not funny at all. This article will explain what it is, where it comes from, and what to do about it.
There were some tribal peoples in the South Pacific who were visited by US airplanes during World War II. These planes would arrive and drop off piles of cargo. The people who lived on the island associated the airstrips and paraphenalia with the arrival of the planes.
After the US troops stopped visiting, they wanted to summon the magical cargo planes, so they built big airstrips out of wood and built make-shift radio towers, thinking that those were what summoned the airplanes. Of course, no planes arrived and nobody got any cargo. These practices were called “cargo cults” by anthropologists.
The term is now broadly used to describe behaviour where people mistakenly think they can summon some benefit by going through empty motions. They don’t understand the real consequences or causes, but they try and get a result anyway.
You can see this is science, in programming, and in agile software development. In fact, it is quite common indeed.
Cargo Cult Agile is where an organization hears about Agile, thinks it sounds great and will let them do software “faster” and “cheaper”. And suddenly project managers are renamed “scrum-masters”, BAs and stakeholders are renamed “product owners”. The Waterfall phases are swept under the rug but really just renamed “dev sprint 1” and “dev sprint 2” and “SIT sprint 1” and so on. Putting a new label on an old wine bottle.
The organization thinks that it is the names and rules and rituals that suddenly make you “agile” and do things “faster” and “better”. They are focusing on “doing Agile”, not “being Agile”. It is classic cargo cult mentality.
And just like putting on coconut headphones and waving tree branches won’t summon a cargo plane, changing everyone’s job titles and hiring agile coaches doesn’t make you Agile.
So what are the cargo cult people missing? Agile is not about a particular set of names and rituals. Those are part of an organization beginning a journey to Agile.
But it is more about a particular mindset, a set of practices (not just rituals). Plus a bunch of tricky organizational change.
A truly Agile organization adopts a mindset of ruthless Continuous Improvement.
There are a collection of technical practices that are really necessary to be considered Agile software development.
They are at the very minimum:
But you should probably look at:
There are also some fundamental organizational changes that need to happen.
You need to move from feature teams to cross-functional teams, from project funding to product funding, and from silo or federated IT to embedded IT.
I’ve talked about cross-functional teams before; it’s very important, it’s basic stuff, you need to do it. I’ve talked about product funding before; it’s a bigger change, and might be too hard for a lot of large organizations to do.
I haven’t talked about embedded IT yet, but basically, we have to stop thinking of IT as a separate “service” that the “business” goes and “pays someone to do”, and rather embed business and IT together.
There shouldn’t be any separation between the two. Product owners and developers should be not only working in the same scrum team but responsible to the same managers and department. And that department should be a business capability, not a feature or a skillset.
People have been talking about Zombie Scrum lately. It’s a very similar concept to Cargo Cult Agile, but applied more specifically to Scrum. I would say 90% of what I’ve described above you could find and apply when talking about Zombie Scrum. If you know and understand that Agile != Scrum, you should be able to fill in the blanks.
There are usually some pretty clear signs. The presence of the classic scrum “bad smells” that I wrote about recently can be a clear sign of cargo cult Agile.
If your organization hires a lot of change agents and agile coaches and transformation specialists but not much seems to be changing, that’s a clear sign. Or if everyone changes their job titles but not much else, that’s a clear sign.
If you’re talking about Continuous Delivery but only releasing every six months, that’s a clear sign.
Fixing it is much harder than detecting it. Books have been written on this. Maybe I’ll write one someday. Think about the missing components I described earlier. Don’t try to do all of them at once. I would say the fundamental ones are cross-functional teams and continuous integration. If you don’t have those, you have problems, and a cargo plane won’t fix them.