Can we go from Doing Agile to Being Agile?

2017 will probably go down in history as the year where the word "agile" entered mainstream enterprise lingo. And this was long overdue and laudable.

What is sad however is to see many enterprises going down the road of embracing “agile" as a process.

What makes things worse? A lot of commonly found literature addresses agility at the level of a team or at most a department with a common goal. And organisations are attempting to take scaled versions of these ideas to apply at enterprise level - embracing LeSS, SAFe,....

But addressing the dimension of process is not enough.

In the quest to be more agile, top management teams now spend hours staring at Jira boards in their meetings, and have replaced the word "meeting" with "retrospective". That must be frustrating.

Will embracing Agile ceremonies without a structure really change the culture? Is this really what we wanted? When did we go astray from "Being Agile" to "Doing Agile"?

Structure & Culture go hand in hand - and can feel iterative. Process can only help.

Hopefully in 2018, we will start asking ourselves: "how do we structure ourselves for enterprise agility?"

Structuring for Enterprise Agility

We are building our "enterprise way of working" on projects. This is the legacy that we have inherited from Plan-Build-Run thinking. Over time, projects turn into task forces which then turn into structure.

Projects are discretionary and transitionary by nature. If we are structured around projects, this is like building out of blocks of ice that disappear over time and evaporate. Projects were never meant to be a structural component.

What is worse, is that organisations have perfected the art of delivering projects and organised themselves around it in the form of committees and gated and phased delivery processes. This has led to teams that have in turn perfected the skill of developing and testing code and working themselves into silos.

Agile was a way to break this mold of thinking - but it has been implemented in the wrong way.

The same organisation that was structured around projects and activities has now hijacked the word “agile” and translated this into processes for agile - paving the way for SCRUM, LeSS and Scaled Agile Frameworks. But this is missing the point.

The question that needs to get answered is not “how do we work” as that can come later - the question that first needs answering is “which operating model best captures and encourages and business/market aligned delivery?” And therefore what should the guiding dimension for a standing team be?

One of the largest banks in Europe has been on a transformation journey to structure its more than 20000 IT employees into a product portfolio driven organisation structure. This massive transformation took more than three years to complete - resulting in 80 product families, and over 200 products. An interesting aspect is that they did not attempt to design the entire product portfolio sitting in an ivory tower, but instead dispersed the autonomy over the entire workforce. The enterprise architecture team gave the guiding direction on the structural product portfolio definitions - but left the individual teams to answer four key questions:

• How does the usage (central, global, local, global + local) of your products affect the way you operate?
• What does the above usage mean to your product portfolio in terms of landscape and support?
• What would the modular structure below each product look like?
• What parts of your portfolio are growing? Which products are entering retirement and need a “keep the lights on” mode?

Product portfolio teams were then given the authority to discover what model works best for their individual product portfolios. We observed over time that some product teams restructured themselves two to three times over a span of 6-9 months till they got the best modular structure fit to their needs.

Not everything went smoothly and the transformation journey had to be replanned and interrupted several times to make way for the implementation of critical implementations and regulatory features. This bank had reached the right balance of centralising structural autonomy (what should our product portfolio be) vs operational autonomy (how should each product portfolio team structure itself to meets its varying needs).

Going from Doing Agile to Being Agile

But we should not fall victim to the Conway’s Law Trap: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.”. Eric Raymond, an open source proponent, famously wrote: “If you have four groups working on a compiler, you will get a 4-pass compiler”

So in 2018, can we really go from Doing Agile to Being Agile? Because this is so much more than just “ SCRUM, Agile Ways of Working and Agile Development”.

Originally posted on www.thinking-digital.org