Agile Enterprise Part 1 - Organising for Agile Execution

 
Agile Enterprise
 

The agile enterprise is a hot topic at the moment with almost everybody I talk to doing something in this space. The extent to which organisations are adopting agile ways of working seems to vary enormously along a spectrum. At one end of the spectrum some have small islands of agility, say in a digital team, while the rest of the organisation continues to operate in a more traditional, waterfall style project model. At the other end of the spectrum some are going all-in with an enterprise-wide transformation to agile ways of working.  

To help people on this journey, regardless of where you are on the spectrum, over the next month I’ll be doing a four-part series on the agile enterprise.  Today, in Part 1, I thought I’d start with one of the most common questions I get…”Does moving to agile mean I need to restructure?”

I can see why this question is top of mind for everybody. There is so much new language within the agile community and much of it implies organisational change. Terms like “cross-functional teams”, “autonomous, self-directed teams”, “long-running, persistent teams”, “squads”, “tribes”, “chapters”, “communities”, “scrums”, “scrum of scrums”, etc, all point to changes in the way teams operate but does it necessarily mean organisational structures need to change?

Well it might, but it might not. In my experience there are indeed massive changes required to an organisation’s operating model to be truly agile, particularly at scale. Rather than starting with just structure, I have found it important to look at all of the following seven dimensions of how change is executed within an organisation:

  1. Organisation structure

  2. People KPI’s and incentives

  3. Culture and values

  4. Governance forums and mechanisms that support decision making

  5. Property and facilities

  6. Processes and supporting tools

  7. Sourcing and partnering

For example, in the largest change I have personally experienced to agile ways of working (more than 1,000 people), every one of the above elements of the operating model needed to change bar one: 

  • we changed where people sat to co-locate people that needed to be co-located,

  • we adjusted people’s KPIs,

  • we actively worked on cultural change to encourage empowerment, experimentation and learning,

  • we changed governance over funding, prioritisation and resource allocation,

  • we implemented new tools support agile ways of working, and

  • we established new partnerships with suppliers.

We didn’t modify the organisation structure in the first instance. In this case organisation structure change would have slowed, not accelerated the journey to agility because there was nothing in the org structure which prevented or hampered all the other changes we needed to make. Conversely if we had modified the org structure it would have distracted key people from the task of implementing all the other changes listed above and likely would have slowed the path to scaled agile.  

In this example, after a year of operating in this new model, we did then do some organisation structure fine turning to simplify and align skills and resources with the various divisions that were vital to the new cross-functional, agile model.  In the scheme of things this modification of the structure was minor compared to all the other changes I listed above.

The key message here is yes, moving to agile will likely mean a lot of change to your operating model, but it may or may not mean modification to your organisation structure in the first instance.

If you need help with your operating model for agile change feel free to reach out to me on david.boyle@cap2its.com.

 


About the author: David Boyle’s IT career over 30 years spans both the buy side and sell side of technology services. He’s worked with Accenture, EY, Commonwealth Bank of Australia and until recently was the Group CIO at NAB. David is now the Managing Director of CAP2ITS, a technology advisory firm focusing on technology strategy, performance and risk.