A Better Analogy for Agile Organizations


No, this isn’t another docker blog post that surprisingly uses a container ship to explain stuff. This is about looking for a better analogy for agile organizations.

I usually have a problem with those cliché examples given to describe agility. We have already moved from thinking about the agility in the relatively narrow context of software teams and extended that to the whole organization to cover the whole chain. (This also follows the lean principle of optimizing the whole) So examples should resonate more with larger, more heterogeneous environments. Resilience, adaptation and survival should be possible to observe through the organization.

Numerous examples from real life is given to show difference and advantages of agile organizations. Introducing new concepts using examples that can be familiarized helps the story.

What examples do we often see trying to symbolize agility and rigidness ?

Cliché examples

Let’s begin with the easy, typical ones for more rigid organizations that suffer from inflexibility, slow reaction speed, inability deal with uncertainty. They have hard time surviving through drastic events, shifting markets and customer expactations. For this situation often trucks, tanks, ships, elephant etc are used. They are strong and big, consume a lot of energy to keep up. They look very stable. It’s relatively more difficult to change. Damages can be crippling with no chance of self healing.

For the sake of this post, lets take a large container ship. Just like a company, that ship has one top leader: captain. The captain, just like CEO, has a team and delegates responsibilities to seniors in crew. Those seniors have clear accountabilities and responsibilities. Ultimately, captain decides where to go, but sailing is team work.

A lot can happen in the open sea. Storms, sickness, pirates, malfunctions, icebergs, riots (if we want to dramatize). Some can become a consequential threat for the whole ship.

Changing direction takes time and being late can be dangerous. All moving parts must keep working fine thanks to the teamwork. Do we have spare parts ? Yes . Do we have capability to fix anything or modify the vessel while sailing towards destination ? No.

Let’s put this in our stack for now.

Search for a good agile example

We have seen so many examples of “agile things” since 2001. Agile like a formula race car, like a speed boat, or a bicycle, or agile like Lionel Messi, a cheetah. So many of them have been used in presentations. They are indeed physically more agile than carefully selected opposites.

But they are flawed examples in multiple ways.

  1. They can be individually agile but we don’t want that. We want whole organization to move better. A speed boat is one person vehicle compared to ship. An elephant is still single entity like a cheetah, no team work, no delegation.

  2. They are not resilient. While a race car is agile, it’s often out of race if it slightly bumps in to something. Cheetah can’t maintain its super speed and agility for long.

  3. They give only one advantage while bringing many disadvantages. This makes it difficult to put in a meaningful comparison story.

  4. Most examples don’t have internal capability to evolve. The best that a ship facing a storm can achieve is enduring. Examples that can evolve when facing stress, examples that can give a light light of antifragility are more valuable.

We need an example that still maintains the concept of the leader, team work, a common goal.

Meet bee swarms!

Bees are amazing creatures and they inspire humanity many different ways.

A bee swarm is a way of reproduction for bee colonies. A single colony splits to create more colonies. Young queen leaves the hive with her own bees to start a new colony.

Just like our container ship, swarm has a purpose, a top leader. Swarm has teams with different responsibilities. Following the queen, swarm moves towards its destination, a new possible nest. Just like in real life, the location of the destination isn’t really known. There is no map to that destination. However bees understand when they find a place suitable for a new home. The purpose is clear, succcess condition is clear but where that can be found is an experimental work.

While swarm follows and protects the queen, it has tons of teams and individuals making micro decisions. Some scare away or fight off dangers, while others scout. Some bring food for others. There is no hard guidelines to instruct what every single bee will be doing. All bees make their own decisions in their area and keep communicating. But at the end, they all share a common purpose. The swarm’s success depends on fulfilling that purpose.

Some bees are lost in the journey. But that doesn’t prevent swarm from moving forward. They can fly around obstacles, collect food, search for a proper nest location. They can survive some weather conditions, hostiles. They don’t have control on events happening on them, but put their resilience in action to survice. Once they settle, they make and grow their nest, waiting for a princess to be born and leave the hive to her own.

Importing foreign real life situations to explain happenings in a completely different area is always difficult and open to many errors because such example will always have shortcomings. The closest example of a tennis ball, is a tennis ball. No matter how similar golf ball is, it won’t be a perfect fit.

Considering that limitation of all examples, if we are going to make comparisons for agile and non-agile organizations, my choice of an agile group would be definitely bees.