The Paradox of Agile Leadership: Doing Versus Being Agile

15 May 18

The Paradox of Agile Leadership: Doing Versus Being Agile

I’ve lately been doing many leadership session with leadership teams in Indonesia. Usually such session is a ‘first step’ in creating awareness of what Agile means to an organization. Without leadership support (and a little push), enterprises cannot become agile.

In doing such sessions I encounter a fundamental paradox: while Agile is to a high extent ‘abstract’ and about ‘changing culture and mindset’, people want to know ‘how to do it’. I think this is one of the strengths of Indonesia: once it’s clear how to do something, people execute fast. But if things are not clear, people long for a ‘formula on how to do it’.

#Agile #paradox: if things are clear, they execute it faster and if they are not clear they look for a formula on how to do it! Click To Tweet

Let’s look at the most recent version one ‘state of agile report‘. Below are the main challenges ‘derailing’ agile adoption:

This chart shows that the #1st problem is a cultural mismatch. The #2nd is resistance to change and the #3rd is about management support. All three relate to the soft side of organizing work; it’s about culture, mindset, the way people behave.

I am always biased towards action. If I get an idea, I want to start working on it right away. Agile is, however, a very large change, which can take many years. And for a large change, there are no formulas. It’s also not only about ‘doing agile’ (which is where scrum comes in). Running scrum on the team level may be a good starting point. But the big change will only happen if leaders see the big picture. And they won’t see it by learning how scrum works.

Here’s a slide from Michael Sahota, showing the difference between doing agile and being agile:


Image result for doing vs being agile

Steve Denning, one of the big thinkers in the agile community, adds some more depth to the agile adoption journey:

An Agile journey is a large-scale long-term undertaking. Here are a few pointers for a leader to keep in mind when getting started:

  • Develop an in-depth understanding of what Agile is
  • Assess your current context, its strengths and weaknesses
  • Maintain an external focus, giving primacy to the customer
  • Don’t get hung up on labels or what to call your transformation journey
  • Recognize that an Agile transformation in a large organization takes years
  • Make organizational change last.
  • Use leadership storytelling to inspire passion for Agile management
  • Recognize that an Agile transformation journey never ends: the firm never “arrives.”

I think number 4 is an interesting point. Many organizations today think about ‘digital transformation’ and ‘agile transformation’. While thinking of these two, they may appear as distinct ‘things’. The difference might be in digital transformation being about ‘what to build’ and agile transformation about ‘how to build it’. But as Steve Denning describes in his books, the distinction isn’t as black and white as this. While reading about enterprise lean startup, you even get a third view or ‘label’. What it all comes down to is changing the ‘operating system’ of the enterprise. Shaping the enterprise for the future; digitalization is part of this journey.

So how to solve this paradox between vague, long term ‘stuff’ and the bias towards action? I believe any starting point is good. If a leadership team wants to know ‘how to do it’, we’ll start there. I’d explain to them how to create transparency using boards; how to reshape roles into cross functional teams; how to build a rhythm of meetings/communication. And apply this to their own work. Any starting point towards agility is good. But I do believe leadership teams and executives need to realize they step on a long term journey. A journey that will change the enterprise, the way people see work, the way people collaborate, the hierarchy and … the culture.

Click To Tweet

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>