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.

Rating: 4.8/5. From 6 votes.
Please wait...

7 comments on “In the Lap of the Agile Gods

  1. To add too the problem, I’ve really come took believe that many people don’t understand or internalize agile into their thinking until they actually see it and experienced it. You and I can give all the case studies we like but seeing is believing, unto people experience it is all just words.

    Unfortunately this is especially acute in senior people who are more removed from the work and maybe have built their careers on the traditional model.

    In such cases I can almost see a case for cargo cult agile. For many teams doing cargo cult agile is better than what came before. That provides opportunity to rethink. Unfortunately, cargo cult agile also revives the pressure (And possible the previous pain) to continue change.

    Catch-22 I guess.

    No votes yet.
    Please wait...
    • Thanks for comment Allan.
      I’d suggest that even where we’re tempted to say “just do this” we should reframe it to “I have a very strong and coherent hypothesis. Would you be willing to test it Can we design an experiment together?”. Then we can talk about why its coherent in achieving aspirations, and how we can prove/disprove it. That’s a subtle but important distinction in my opinion. However sure I am about what the right thing to do is, I try and always be willing to be wrong.
      Of course if people aren’t willing to experiment or don’t have any aspirations, then there’s not much you can do.
      Karl

      No votes yet.
      Please wait...
  2. Who is “we”? This article reminds me a bit of a driving tip a friend had. He would turn his cars lights off at night to make the oncoming cars lights easier to see or something. It works but it’s not scalable. If everyone read this article everyone would be passively waiting for someone else to decide what to do, and no one would actually do it. Is the idea to split everyone up in two groups? Those who are allowed to figure out what to do and those who are not?

    No votes yet.
    Please wait...
    • Hi Kurt – thanks for the comment.
      “We” is those of us involved in Agile Transformations. I’m not recommending anyone be passive – that would be leaving it to chance (In the Lap of the Gods). I’m suggesting that rather than simply copying others (False Gods) or relying on experts (God Complex), everyone should be involved in figuring out what action to take by running small experiments to discover emergent solutions, aligned to clear strategies and outcomes.
      Karl

      Rating: 4.0/5. From 1 vote.
      Please wait...
      • Hi Karl,
        Agreed. I see it as the art of strategic facilitation.
        As Agile coaches, we have the experience to know where we want to stear a team, but having said that, every environment is unique and you rely on the calaboration of the teams for that ideal outcome.
        It’s all down to strategic facilitation.
        Something I know you are an expert in.
        Thanks for the article.

        No votes yet.
        Please wait...
  3. My personal opinion on this is getting people onboard, I also think this takes many forms. (Open Space Agility – Daniel’s approach is one valid way of inviting people into the transformation and there are others.)

    When I see this come up, I realize I am recognizing an Agile Bramble https://agilebrambles.org/2017/02/02/invited-vs-imposed-bramble/). I then try to help people determine what options will really work. Perhaps their is a third way they can invent for themselves that will work.

    Cheers,
    Paul

    No votes yet.
    Please wait...
  4. It is my opinion that we have to do a little driving to get the teams to start working Agile, and then a little more driving to show them that the processes we have agreed to put in place should be questioned, experimented on, and changed. The bigger challenge is getting management to agree to not fire the team for failed experiments!
    Quite a good way to phrase it – Lap of the Gods

    No votes yet.
    Please wait...

Comments are closed.