The Opposite of Agility: Rituals, Ceremonies, and the Cargo Cult-EN

Recently, I remembered that until a few years ago, the Scrum Guide referred to events as “the ceremonies.” I never really liked the use of the word ceremony in Scrum, because it attributed a seriousness and formality to something that doesn’t really have it. Meetings in Scrum are living events that have a very specific purpose: to inspect and adapt. This is exactly the opposite of the connotations that “ceremonies” brings to mind, ideas of quiet and boredom and serious things.

But without further confusing the meaning of words, a few days ago I stumbled again on the idea of “ceremonies” in Scrum as I reviewed a few notes on the Phenomenon of Cargo Cult in agile teams.

So, it occurred to me to refresh the concept of Cargo Cult and the danger that always haunts agile teams: that everything becomes a sequence of mechanical rituals that are formal and lifeless.

What is a Cargo Cult?

For those of you unfamiliar with the Cargo Cult concept… During World War II, American troops arrived by planes and ships to some Pacific islands and, during their stay, gave goods to the inhabitants. When the war ended, the troops stopped going to the islands and the natives stopped receiving the precious goods and gifts. And then there was an eye-catching phenomenon: the natives began to build monuments shaped like airplanes. They believed that by repeating exactly what they had seen those gods from heaven do, more planes would magically come with goods and gifts.

This phenomenon is what we call Cargo Cult. The concept is used as a metaphor to describe a very valid problem: the effort to try to replicate certain results by mimicking behaviors – rituals – without understanding the true causes that lead to those results.

The Opposite of Agility

The Toyota Case

In the 1980s American companies wanted to replicate the success of Toyota’s famous manufacturing model (Toyota Production System) by implementing only the most visible and mechanical part of Lean: Toyota’s activities, events, and processes. It was a big failure. It took them some time to understand that Lean’s essence requires understanding their philosophy and applying their principles to improve their own processes.

The Nokia Case

Nokia is another example. They invested millions in their agile transformation process. Dozens of teams applying “Scrum by the book”. The metrics used by Nokia indicated that the organization’s transformation was successful, but this was not the case. Lack of visibility into the impact and contribution of team work on business outcomes led to failure and highlighted the inability to transition to a new era. The team was not aligned with the new needs and trends of the market: touch screens, focus on software development, and app stores. Basically, the positive metrics used to measure team productivity were disconnected from the weak measurements of organizational and business agility. The apparent agility Nokia believed it had was not real, even if it had teams that applied Scrum scrupulously.

We also see many manifestations of Cargo Cult in agile teams. Many believe they are doing Scrum only because they have been certified and apply roles, attend events, and use artifacts. But they don’t feel that Scrum is really helping them in their work. Rather, they perceive it as an extra burden that robs them of time and flexibility.

Could this be true?

The Disconnect is Real

In the cases above, we see that there is a disconnection and lack of alignment between the “output” – the activitiesthat occur – and the “outcome” – the actual impact they have.

Some teams that follow Scrum’s Cargo Cult have these symptoms:

1. The team has no self-organization or autonomy. Members resign themselves to continuing as they are. They feel powerless. They don’t own what they do and have no power to implement improvements in their own way of working.
2. There’s no innovation. The famous “tyranny of the urgent” prevents them from investing time and energy into the really important things.
3. The team is disconnected from the stakeholders. They don’t know the real needs of users. There is too much distance between the people who use the product and those who develop it. It is common to find intermediaries that aren’t part of the team in between, such as business analysts, department heads, managers, and sponsors who collect the requirements and send them to the team. This will lead to a lot of bureaucracy and little agility.
4. The team also has poor visibility into the context and dependencies of what they do. They don’t know how the product they produce helps fulfill the organization’s mission.
5. Little commitment and motivation. Team members feel they are cogs in a machine that they don’t understand.
6. Lack of delivery cadence. At the end of the sprints, there isn’t a complete increment that can be tested.
7. Scrum is applied through inertia, without knowing if it is the best option. Maybe they should adopt Kanban? Considerations such as this aren’t given the chance since they are “outside” the Scrum guide.

Sometimes the cause of the problem is that a misguided paradigm continues to be applied. The traditional way to manage an organization and product development is designed to achieve the opposite of agility. This is called the “efficiency mindset”, and its goal is to increase efficiency by trying to reduce uncertainty as much as possible, to increase the predictability of the team/teams.

When this happens, we see that Scrum is used for the wrong reasons: to be more efficient, to improve output, to be faster. It’s like trying to be agile without understanding the principles and fundamentals of agility.

The framework proposed by Scrum has more to do with being effective than being efficient.

In a way it is understandable that this happens to them: with the rush to “do” – and the pressure of having to prove that they’re doing something – these teams only concentrate on the mechanical part of Scrum, which masks the reality that they don’t really work as an agile team. They do not focus on delivering value incrementally and continuously. Not even to improve. Not even in learning. Not even innovating.

Back to the Basics

What alternatives do we have when we first start to see the beginnings of a Cargo Cult?

A good starting point is to return to the fundamentals and principles of agility, understand them, and apply them to your context. This itself is a learning process— an iterative and incremental one.

And of course, let’s remember that Scrum’s proposed framework encourages teams to discover their own solutions and find new ways to get things done.

Gracias,

Gabriel

Does your team look like a cargo cult?

Check out our Agile Fundamentals course to understand why you are going what you are doing, and start to make Scrum work for you!

Course Outline