Working at a large organization, sometimes teams are told to do Agile as an objective. There is a perception that they must do a pre-defined framework like Scrum or SAFe, or whatever their manager was told that they should do. This is the stuff of Dilbert cartoons, but it happens frequently and consistently when the system of work is not aligned. I like to call this the mechanical application of Agile.
For example, when I get pulled into a meeting with a team that is up and running already, I am asked to help the scrum master as some things are not going smoothly. The scrum master will outline the project, the team members and their objectives. They will give the hierarchy and schedule of releases. The team is working in sprints and using some ceremonies. Everything seems okay at the surface until we get into the details of their value delivery. Who is your customer? What happens before the request comes to your team? What happens after your team is done, how long until the customer gets the value?
Enter awkward silence
Cargo Cults
In a Podcast with Agile coach Dan North, he outlined some great ideas, and the one applicable here is Cargo Cults. Cargo cults were Pacific island tribes who were impacted by the invasions during World War 2. The war brought a huge number of people who interacted and traded with the local people. As they built airfields, the army was able to requisition goods from planes and were able to setup a small society with modern goods and food delivered via air and sea.
This was an amazing change in the life of these islanders. But then, the war ended and the army went back. All of a sudden, these people left…..and so did the cargo planes and ships.
So, the islanders began to re-create the actions and symbols of this wealth (usually lead by a charismatic big-man). They tried to copy what they had seen. Dressing up as soldiers, building control towers, hollowing out coconuts to make headphones and making dances that represented the arm actions of signalling a plane.
They were trying to bring the success they had seen by imitating the actions of other people. The issue of course, is that they did not understand the system and production methodologies used by the army and navy to produce these goods.
How does this apply to Applying Agile in my organization?
Consultancies, HBR and authors have all made a living from sharing the ways to do agile. People are looking at the others in the field and trying to copy.
- Oh wow, they are using Squads and Tribes (no relation to cargo cults here), we should organize by Squads and Tribes too.
- Every agile team has a scrum master and a product owner,
Melissa, you are now scrum master. Anil, you are the product owner. Give me the Gantt chart next week, okay? - Other people are using backlog tools, Anil, make a backlog from our requirements and put it into JIRA
- Agile Release Trains do PI Planning, make sure you do a PI Planning and bring it to me for approval
- Agile teams do sprints and retrospectives, make sure you do those.
By the way, we have another request from an important client, make sure the team gets it done.
This is the entry into the mechanical mode or bumper-sticker Agile. People are using the words of Agile practices, but their behaviors are still rooted in the existing Values and Principles.
These existing values will include that people are lazy, decisions can only be made by managers because they bear all the risk, costs will not be controlled unless we put in processes to stop them. These are shown in principles of individualistic KPIs, cascading strategy through silos, cost accounting and ensuring people are busy (since I am paying for their time). This results in some major anti-patterns:
- Agile experts (we just need an expert to come in and give us a checklist to follow)
- Decision making and work are separate (development team cannot be trusted to choose what to do, as a manger, I am on the hook, so I get the final say)
- Blaming people, not the system of work (that other team does not have the same priorities and they ignore me, those people do not know what they are doing)
- Just tell me what to do boss
- Creating incentives for bad behaviors (you will be rewarded if your agile assessment keeps going up, you get a bonus if your velocity is higher than the other team, I will reward you if you have fewer defects and deliver faster)
Teams will go through the actions of organizing in Squads and planning sprints and using role names that have no link to the original intention. They were told to be agile, so just do it and get it over with. If anyone asks, our version of agile is unique.
But I want my teams to be agile and faster and more responsive
It is appealing to chase Agile to deliver results blindly as an objective, not as a way to serve the business. To be clear, Agile is not an objective in itself. As a pattern of work and focus on human interaction, it is a powerful source of inspiration when done with the right people using the values and principles. It is awful and empty when done mechanically. This is a form of waste, the waste of human potential.
Asking everyone to do agile risks creating cargo cults. The agile mindset requires you to analyze, inspect and adapt with information that you learn. Rather than telling people to be agile, there can be more value in looking at the system of work. Looking at bureaucracy, waste, large plans and communication paths between teams.
How do you do that? Ask yourself, is this doing something useful or just an imitation (or something I was told to do to imitate). How can we run the analyze, inspect and adapt cycle on this change? More importantly, does our behavior reflect the values and principles embedded in Lean-Agile thinking?
Lean-Agile with Paul 
One thought on “Agile Everywhere… have we built a Cargo Cult?”