When Scrum becomes a Cargo Cult
You probably started making changes to Scrum to make it “better fit” your organization or team, and at that point, it became “Scrum, but”. You know this has happened, if you are asked to explain your process, and you start by saying something like “We use Scrum, but…”. However, removing elements of Scrum without considering its effect is ill-advised. I’m not saying you shouldn’t adjust your process. I’m saying, that doing it for convenience and without thorough consideration is tantamount to starting a Cargo Cult.
I’ve worked in teams where, when I asked about the process, the answer went along those lines. It usually made me ask questions like, “why?”, “how?” and in a few cases: “Did you even read the Agile Manifesto?”. I have come to think of many of these “Scrum, but” processes as Cargo Cults, and in some cases, I have even brought up the analogy to try to explain why a specific process wasn’t working. So how do you know if you’re in a Cargo Cult, and how can you avoid your process becoming one?
A cult of believers
A cargo cult is a millenarian belief system in which adherents perform rituals which they believe will cause a more technologically advanced society to deliver goods. – Cargo Cult
I like to go back and re-read the short Wiki whenever I run into Scrum teams that either partly or completely ignore vital elements to Scrum. I often refer to the Pacific cults of World War II. During WWII, Japanese and Americans used Pacific islands as supply depots. On some islands, indigenous people had lived for centuries, largely without contact with the rest of the world. Upon seeing the large amounts of food, goods, and cargo dropping from the sky, the indigenous people must have believed these “new” people’s gods must be mighty indeed to provide such a bounty. In the aftermath of WWII, cults started appearing on the islands, worshipping entities with such names as “John Frum” or “Tom Navy”. The cults believed these spiritual entities would also provide cargo to them, if they simply followed the same “rituals” as the newcomers had. They would light signal fires, build replica airplanes and airstrips, hoping that by pleasing their new gods, cargo would drop from the sky. The cults persist even into our times, with the Prince Phillip Movement being most widely known.
Fun fact: after the death of Prince Phillip, the cult started believing he would return.
Failure of logic
When I tell the Cargo Cult Story, I usually get a few laughs, before someone tries to explain to me why their process isn’t the same. Arguments like: “We don’t need a daily stand-up, our devs just talk to each other whenever.” Or: “We don’t do planning poker with the whole team, because our lead estimates everything”. When asked what effect they think it has on their process, many struggle to find words or can only come up with positive effects. When challenged on it, answers like: “This is how it was where I worked before, and it got results!” or: “It has always been this way, and it works!” often surface.
The arguments are the result of a failure of logic. Correlation is, after all, not causation. What makes Scrum work is not the religious following of individual rituals, but the understanding of why and how those rituals interact and work. Remove one, and the interactions change and possibly stop working. Maybe your team doesn’t need a daily stand-up, but something needs to replace its function. If you have a team, where asking for help is encouraged, getting additional information about tasks is easy, and the whole team knows what everyone is working on, maybe you truly don’t. Most organizations do though, and to them, this failure of logic can lead to an ineffective and frustrating process.
Read the manifest
I highly encourage you to read the Agile Manifesto and the Principles behind the Agile Manifesto yourself. It’s a short read. They are, at once, specific and almost philosophic. Don’t be afraid to spend some time re-familiarizing yourself with the theory. Atlassian has a great resource for Scrum, and I have spent some time there myself, during my research for this post.
It’s important to note the last sentence, especially because these values are not opposites. Processes are part of Scrum, and having the right tools is important, but Scrum is not just about the rituals and the tools. It’s about taking what makes us human with us into our work and interactions and using our unique capacity for combining language, visual aids, and imagination to understand each other better. The result of that is better software, happier clients, and a much more effective team.
Be truly agile
The Agile manifesto is still a valuable source of inspiration to those who aspire to its tenets and ideas. I am one of those people. To me, agile - and Scrum in particular - are about people and creating an environment, in which we can freely discuss, iterate, and produce solid software. To be truly agile is to understand how processes interact, and how those interactions change when the process, the people, or the product changes.
Scrum is, at face value, a set of rituals and ceremonies. It’s a framework inside which you can improve your team and your product. How you use the framework is up to you, but understanding, what the rituals and ceremonies are there to do, is vital. Otherwise, you’re like the native, lighting a signal fire on the beach, expecting the cargo to drop from the sky any moment now.