Cargo Cult Agile
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.
What does “cargo cult” mean?
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.
What is Cargo Cult Agile then?
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.
What’s missing?
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.
Continuous Improvement Mindset
A truly Agile organization adopts a mindset of ruthless Continuous Improvement.
This means:
- no more talk of “best practice” or “standard procedure”. You continuously change and improve how you work, no exceptions
- no more blame culture; attack the problem, not the person
- every person and every team has a responsibility to define and perform experiments, both on the products you are building and the way you are working.
Technical practices
There are a collection of technical practices that are really necessary to be considered Agile software development.
They are at the very minimum:
- Continuous Integration (all developers merge at least once per day, no long-term shelving of code, no messy integration hell)
- Automated Testing (you can’t manually test every change when you are merging 10 or 20 or 100 or more changes per day, you need to automate regression testing).
But you should probably look at:
- Test Driven Development (or its cousin Behaviour Driven Development): test first, then develop, and refactor mercilessly
- Continuous Delivery (automated build and test pipelines that go all the way to production)
- DevOps (No organizational barriers between development and Operations).
Organizational change
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.
Is Cargo Cult Agile the same as Zombie Scrum?
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.
How to detect Cargo Cult Agile
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.
How to fix Cargo Cult Agile
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.
