Agile Cargoism

In the South Seas there is a cargo cult of people. During the war, they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they've arranged to imitate things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas--he's the controller--and they wait for the airplanes to land. They're doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn't work. No airplanes land.

From a Westerner's perspective, the actions of the Cargo Cult are ludicrous, but ask the practitioners - they feel entirely different about the matter!


But - what is Cargoism?
Cargoism is the firm belief that by imitating hard enough, you will produce the same results as other practitioners. If you're not successful, it's because you didn't imitate well enough. A cargoist doesn't realize that they are missing something, that the big picture is different from their perception.

James Shore wrote a good article on Agile Cargo Cult teams back in 2008. It's worth the read.
But an entire organization can become an Agile Cargo Cult!
I've heard many times when people said "Google is successful with Agile, Spotify is successful ... so we can also be!". Then, they spend big money to send their Managers to CSPO or CSM training and establish Scrum. Of course, the executives hope that projects will run faster and more successful once practices are adopted.
They hear about Agile, they see all those successful projects and they firmly believe: "Let's do Agile, and we'll be much more competitive."
So, team managers are renamed to Scrum Masters, project managers become Product Owners - the Releases are renamed to "Sprints", each of which is started with a Sprint Planning Meeting. Every day there's a Standup. At the end of a Sprint, there's a Review and a Retrospective.
Now, we're set up. The world is just waiting for our greatness to become manifest! We'll be a successful Agile Organization in no time - and our stock will skyrocket far beyond Apple, Google and Microsoft!

Oh wait - I've described the typical organization that will stop "Agile" after maybe 2 or 3 years, shelving the concept for good. Disillusioned employees will say "Agile is just a different name for the same old wine" and managers will say "We've tried Agile. It doesn't work, it's just a fad".

Blinded by the promise of easy success, fast, high quality results at a low cost, thy adopt the practice in hopes of valuable returns: Cargoism at it's finest! Someone did make a good sale to them, probably earning good money on all the training and coaching. Ask deeper.

1. Do managers loosen the reigns?
   Agile means giving power to those who need the power to succeed. A Command+Control structure is not only inherently inefficient, but it prohibits success. Maybe people can't do what is right because they still need management approval. In this case, management may proclaim a million times "We're Agile" - but at the same time, they're agility's biggest impediment!
2. Do people understand that Agile methods like Scrum don't solve any problems?
   Scrum, for instance, just makes problems visible. Did a real, genuine problem solving process get established? Are fundamental organizational issues resolved - or accepted?
3. Who really owns the products?
   Are people aware that Product Owners champion the product - but that the product really belongs to the team? Do developers take personal ownership of their work, are they proud of their contribution to the product, or are they delivering products just because it's their job? Do the teams even have what it takes to own their product, or do they rely on external patronage to deliver anything?
4. Who defines the development process?
   Do developers follow corporate governance or are they empowered to do what is right? Do they really care to do what is right - or do they prefer to have someone tell them? Do they not only care to do their job, but to do it well? Do they improve their working process because they see the need - or because the Scrum Master pushes them?
5. Do people realize Scrum Ceremonies are actually the wrong idea? Do they realize teams should not have to have:
1. Standups, as mentioned by Jame Shore. If everyone knows what we're doing, and the PO is continuously involved - the Standup will add no value.
2. Reviews. If the team were directly engaged with the customer either with direct collaboration or techniques like A/B testing, they wouldn't need to batch up for a week or two before getting things signed off. 
3. Retrospectives. If something is going wrong, why wait until the end of the sprint before bringing the issue up for improvement? That's insane! When you see that something is wrong, go fix it!

If you hold the firm belief that by rigorously applying the practices, you will become more Agile, you have already failed. Behind Agile, there is a spirit. This spirit is not visible, but it may be manifest in agile teams. If you do not lay hold of this spirit, all your efforts are doomed. You will not be successful.
"Copy the spirit, not the form", said Yoji Akao - and that is as true for Agile as it is for Quality Function Deployment.

Without the agile spirit, you'll be weaving Agile landing strips and donning Agile coconut headsets until your organization falters, but you won't receive the precious agile cargo, no matter how devotedly you worship Agile Cargoism.