The Scrum Cargo Cult

It might look like a plane, but it’s not going to fly. (Photo credit: Skeptical Agile.)

During World War II, the Pacific Ocean became a theater of war between several of the world’s most technologically advanced nations. Islands scattered across the ocean became critical strategic positions. Japanese and American servicemen shared goods with the indigenous peoples of those islands. When the war ended and the militaries left, many of the islanders still wanted the “cargo” that those servicemen had once shared. They built runways and mock radio towers from bamboo and straw. They lit fires in mimicry of landing lights, and even built bamboo models of airplanes, all in the hopes that the “cargo” would return. These “cargo cults” are anthropologically fascinating, with socially rich and complex interactions between modernity and ancestral belief systems, but they’re not related in any way to avionics.

Scrum has become ubiquitous in software development over the past decade or two. It promised developers greatly increased autonomy and productivity. So why is it that so many developers hate Scrum precisely for its oppressive micro-management? Why is it that so few businesses are realizing those huge gains in productivity that they were originally promised?

The two questions are deeply intertwined. Organizations aren’t realizing the benefits of Scrum primarily because they never actually adopted Scrum. Scrum isn’t ubiquitous at all — in fact, it’s quite rare to find an organization that actually practices Scrum. What’s become ubiquitous is a cargo cult that calls itself “Scrum,” that uses words like “Scrum Master” and “Product Owner” and “backlog,” but ultimately has as much in common with Scrum as a working Boeing 737 has in common with a model made of straw and bamboo sitting in the jungles of Melanesia.

Far too often, an “agile transformation” means setting up Jira, calling requirements “user stories,” using planning poker to estimate “story points,” and changing all of the project managers’ titles to “product owner.” But here’s the rub: if your “agile transformation” only means transforming what you call things, without changing the way you actually do things, then you haven’t transformed very much.

I’ve heard some managers argue that Scrum leaves a lot of room for interpretation, but the Scrum Guide quite explicitly rejects that. Scrum doesn’t have many requirements, but those that it has are clear and non-negotiable.

While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Scrum is a skeleton. You can’t really just follow Scrum; there’s not enough to it to actually accomplish anything by itself. You need to add organs, muscle, and skin to that skeleton (notably, it was originally a wrapper for extreme programming, specifically), but no part of the skeleton is optional. You need all the bones.

When Dave Thomas (the one whose name can be found affixed to the Agile Manifesto) declared that Agile is Dead eight years ago, he lamented that a concept as important as agility had degraded into a noun—and a proper noun, at that. Capital “A” Agile is a commodity, something that can be packaged and sold—not something that you do, but something that you acquire from a properly-licensed professional. The Scrum cargo cult is the primary product of the Agile Industrial Complex.

Of course, the solution to those problems lies in actual agility. That’s something that Scrum would actually help a lot with—provided that we’re actually doing Scrum. In that same talk, Dave Thomas gives a very simple, four-step algorithm for agility:

1. Figure out where you are.
2. Take a small step towards your goal.
3. Adjust your understanding based on what you learned.
4. Go to step 1.

The Daily Scrum

You’ll note what the Scrum Guide has to say about the daily scrum:

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

Every day that we work in Scrum should be one iteration of Dave Thomas’s loop. At the daily scrum, we adjust our understanding of where we are based on what we learned yesterday, and set our plan for what small step toward our sprint goal we’re going to take over the next day.

Signs Your Daily Scrum May Be Part of a Cargo Cult

• If your manager can’t attend, you cancel the daily scrum. (This suggests that the daily scrum has devolved into a status meeting for managers to ensure that everyone is maintaining 100% personal utilization. That’s not the purpose of the daily scrum. So when is the team coordinating their work over the next day if not during the daily scrum? Are they doing that at all?)
• Inspecting progress toward the sprint goal is not a meaningful question to ask, either because there is no concrete, meaningful sprint goal to consider, or the true sprint goal is “complete all of the tasks that we’ve been assigned,” so any discussion would be duplicative of the Jira board or other report that everyone already has access to. (This points to a deeper problem with the sprint itself and what purpose it is serving.)
• You have your items to report on, and the other team members have their items. As a consequence, you might not always pay attention to what others are saying, since it doesn’t really affect you. (This often follows when items are assigned to individuals, rather than the team taking responsibility for achieving the sprint goal as a whole. This violates quite a bit of the Scrum Guide, and suggests that you’re using Scrum terms as a framework for assigning and tracking personal tasks, rather than actually doing Scrum.)

The Sprint

We’re usually working with stakeholders: a client, a business, or someone else who wants to solve a problem. In Scrum, we work in sprints toward achieving that goal. We figure out where we are and decide on the best small step that we can take toward that goal, given that understanding. We take that step, which produces something (an “increment” in the Scrum Guide). In the sprint review, we meet with our stakeholders to share what we’ve learned. We learn from creating the increment and we learn from the feedback that our stakeholders give us in the sprint review, which allows us to adjust our understanding of where we are and decide on the next best small step that we can take.

Nowhere in the Scrum Guide does it say that a sprint must be (or even should be) two weeks long. It says that under no circumstances should it be more than a month long, but how long should it be? The real answer is: as short at it can be. It needs to be long enough to actually produce a working increment, and you need your stakeholders to be able to attend the sprint review, but if you can reliably produce some increment every day and your stakeholders don’t mind a short review meeting every morning, then a one-day sprint may be ideal. The standard two-week sprint is usually a compromise with stakeholders’ schedules. They can’t meet more often, so we settle for a two-week sprint.

Signs Your Sprint May Be Part of a Cargo Cult

• Your sprints only occasionally (or even never) produce a concrete increment. (How can there be a feedback loop from taking a small step and observing where that puts you if you’re not taking a small step? And if there’s no increment and no updated understanding of the situation, then what did the sprint achieve?)
• You have “sprint demos” rather than “sprint reviews,” because stakeholders can’t always attend. The goal of the meeting shifts to demonstrating the work that’s been done, since stakeholders won’t always be present to provide feedback. If stakeholders can’t attend, you record the demo so that they can watch it later. (If stakeholders can’t attend the review, they can’t offer feedback; if you’re not getting feedback, then what did the sprint accomplish? How can we complete a feedback loop without any feedback?)
• You’ve planned out the next sprint, or even several future sprints. (Each sprint goal is the next best, small step that the team can take towards a larger goal, so how can we possibly know what that next best small step will be until we see where we are at the end of the current sprint? If you can’t know where you’ll be, then you can’t know what the next step will be, so if you’re really doing Scrum, how can any plan for a future sprint be anything but waste?)

The Retrospective

The Agile Manifesto is four values and twelve principles, and of those, only one is a practice:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

You’re probably noticing that this is the same loop again. Since Scrum has already defined the sprint as an iteration over which we can take a small step with the thing we’re making and get feedback on the increment we produce, it uses that same timeframe for the team to evaluate itself.

Allen Holub has claimed that the retrospective is the only practice that a team really needs to become agile. If you commit to following that and following where it leads, your team will become incredibly agile in time (far more agile than teams that “adopt Scrum,” but only in name, and perhaps even more than the teams that really do practice Scrum).

Where the daily and sprint loops focus on the thing you’re making, the retrospective asks the team to focus on the team itself and how they work together as a team, their practices and processes, and how they can become a more effective team. But the core loop of agility stays the same. The team tries to figure out where they are, then identify the best small step they can take from there. Over the next sprint, they take that small step. In the next retrospective, they take what they’ve learned to update their understanding of where they are, and repeat the process.

Signs Your Retro May Be Part of a Cargo Cult

• Your retrospective rarely (if ever) produces solid, actionable things that the team commits to do differently over the next sprint. (If your retro has broken down into group therapy, a complaining session, or a pep rally, then where’s the feedback loop that will help you continuously improve?)
• You’ve had several retrospectives, but you can’t point to any practices or processes that your team follows that came out of a retro. (If your retro isn’t having any impact on the way your team works, then what purpose is it really serving?)
• Many of the team members consider the retrospective a waste of time, or the retro is something that you might cut or cancel if there isn’t enough time. (If the team doesn’t value the retro, is that because the retro doesn’t have much value? Why is it so easy to cancel? If the only practice actually prescribed by the Agile Manifesto is something that you can so easily do without, then in what way is your team agile?)

Escaping a Scrum Cargo Cult

You might have noticed a theme in those signs that you might be in a Scrum cargo cult above. Each one is tied to following some part of Scrum just because it’s in the Scrum guide, without understanding what purpose it serves. That’s what makes it a cargo cult. The Melanesian islanders who created the original cargo cults didn’t understand how airplanes, radio towers, or military logistics worked. They wanted the benefits of those systems, so they mimicked what they could see, hoping that if they surrounded themselves with the ephemera of industrial militaries that the cargo would come to them.

Scrum cargo cults happen when businesses “adopt Scrum” because they want the increases to productivity that Scrum promises, but they don’t really understand why or how it works. They’ll set up a Jira board and have all the project managers change their titles to product owners, but they don’t understand the ways in which a product owner is really nothing like a project manager. They’ll work in sprints and have retros and go through all the motions of Scrum in the hopes that somehow agility will come to them.

Scrum is a process for exploring a complex problem space by iterating through several connected loops of inspection and adaptation. It’s not a framework for organizing assigned work, it’s a set of iterative loops. Every Scrum ceremony is dedicated to iterating one or more of those loops. If your ceremonies aren’t doing that, then you’re missing the whole point of Scrum. Sadly, that’s far more common than a truly functional Scrum team.

We often talk about “agile transformations.” Most businesses are transformed if they truly embrace Scrum. It requires them to deeply reconsider the nature of their business and confront a lot of truths about the problems they’re trying to solve that they’ve very likely tried to avoid for a very long time. That’s why the Scrum cargo cult is so much more popular. Scrum cargo cults can feel like a transformation, but without the terrifying challenge of actually changing anything. The problem is, if you’re not actually changing anything, you can’t really expect the results to change, either. If you want different results, you have to do things differently. You can build a model from straw and bamboo, but it will never fly.