In the Lap of the Agile Gods

Luck

I’ve noticed a lot of conversation recently (mostly on Twitter) debating how prescriptive, or not, we should be when helping teams through an Agile Transformation (i.e. helping them use Agile approaches to be more Agile)? Do we tell teams exactly what to do initially, or allow them complete freedom to figure it out for themselves? Or something else?

Worshipping False Gods

During World War 2, inhabitants of Melanesian islands in the Southwestern Pacific Ocean witnessed the Japanese & Allied forces using their homelands as military bases for troops, equipment and supplies. The troops would often share supplies with the native islander in return for support or assistance. After the war ended and the troops left, it was observed that the islanders would make copies of some items and mimic certain behaviours they had witnessed. For example recreating mock airfields and airplanes. Not understanding the technologies which had brought the cargo, these rituals were an attempt to attract more from the spiritual gods they thought had originally granted them.

This practice became knowns as a Cargo Cult, and has taken on a metaphorical use to describe the copying of conditions which are irrelevant or insufficient, in order to reproduce results without understanding the actual context. Thus we get Cargo Cult Agile, where the methods, practices and tools of successful teams and organisations are copied, irregardless of the original context. What has become known as the Spotify Method is a prime example, as are other attempts to reproduce the approaches used successful organisations such as Amazon, Apple or Netflix.

Trying to be Gods

In the 11th Century, legend has it that then King of England Canute the Great went to the sea shoreline to sit on his throne and command the tide not to come in. Unsurprisingly his orders had no effect and the tide continued to advance. His intent with the piece of theatre was to show that even Kings do not have the power of Gods. He was not, as is often thought, delusional enough to think that he did have such power.

This delusion is known as the God Complex, where people believe that they have the knowledge, skills, experience and power to design and predict solutions to the challenges we face. Further, they refuse to accept the fact that they might be wrong. Thus we get the Agile God Complex, where Agile is imposed on teams and organisations by managers and consultants in the belief that it will solve all problems. If people would just do it right!

Daniel Mezick has also been referring to something similar as the Agile Industrial Complex. And for the Cynefin crowd, this is of course treating a complex problem as if it were complicated. And while the use of expertise is valid for complicated problems, it still shouldn’t be confused with having god-like power!

Leaving it in the Lap of the Gods

This leaves a potential quandary. If we shouldn’t worship false gods, and we shouldn’t try to be gods, what should we do? Leave it in the lap of the gods? In other words, should we just leave it to chance and hope people will figure things our for themselves?

This is where Strategy Deployment comes in to play; allowing solutions to emerge from the people closest to the problem. We don’t need to leave it in the lap of the gods because we can provide clarity of intent and strategic guidance which informs the co-creation of experiments. Thus we can deliberately discover what action we can take to TASTE success.

Put another way, we enable Outcome-Oriented Change. Mike Burrows has recently used this term to described his Agendashift approach, and the following definition nicely sums up for me how we should be help teams through an Agile Transformation.

By building agreement on outcomes we facilitate rapid, experiment-based evolution of process, practice, and organisation. Agendashift avoids the self-defeating prescription of Lean and Agile techniques in isolation; instead we help you keep your vision and strategy aligned with a culture of co-creation and continuous transformation.