Operating models and agile

I recently gave a talk at the European Organization Design Forum on the topic of agile organizations.  This forced me to think deeply about what agile is and how it relates to organization design.  So let me share some of these thoughts here and expand the topic to include operating model design.

First a definition of agile: “being able to turn on a dime for a dime” and “being able to change faster and more cheaply than your competitors”.   These phrases are taken from Craig Larman, who was part of the team who coined the term agile as being relevant to the lean and six sigma community.  In this community, agile is associated with short-period (often six-week), test-and-learn projects, at the end of which priorities and direction can be reset based on what has been learned.  It is also associated with “minimum viable product”: the way of testing a new idea.

So what has it got to do with operating models or organization?  First, when making change, an agile approach to the change is probably wise. Don’t try to plan it all out and then execute. Instead, make some change quickly and then reassess.  Of course, in many tall hierarchies, the quick-cycle, test-and-learn approach is hard to make happen because, to get approval for change, top layers in the structure often want a fully-worked and costed business case.  Changing the plan and the business case every few weeks is hard both administratively and politically.  So one of the implications of agile is that we need to have decision processes in organizations that focus more on “intent” rather than “plan”, and decentralize achievement of intent down to teams that can operate in an agile way.

Second, there are lots of components of organization and operating models that are not, and never will be, agile.  In fact your ability to succeed in period A is often a function of your willingness to make commitments now that may cause you to be inflexible in period B.   Think for example of a company competing for a contract with Tesco or Walmart.  To win the contract, the company often has to demonstrate that it has built the capacity and developed the systems needed to serve this customer.  This capacity and technology can then become legacy problems if the customer changes its needs.  Yes you can build flexible capacity and systems, but typically these are more expensive than dedicated solutions: so there is a trade off.

The choice of the head of the organization is another example of a decision that is typically anti-agile.  Every leader has strengths and weaknesses.  If circumstances change so that the weaknesses become a significant disadvantage, it typically takes a year or two before the head can be changed.

If we think through the components of an operating model – POLISM – we can see the tensions that agile raises.   A process needs to be “leaned” to deliver a particular value proposition.  But this will make the process costly or less effective for delivering slightly different value propositions: the process becomes anti-agile.

Organization structure, even if controlled by holacracy (the self organizing method), takes time to change: it becomes anti-agile.

Location is expensive to change not just because of leases and the moving of people and equipment, but also because of other elements of the operating model that are influenced by location – supplier relationships, customer relationship, attractiveness for employees, etc.  So location can be anti-agile.

Legacy information systems are frequently a cause of lack of agility.  But, there is often no way round the problem, especially with bespoke software.

Supplier relationships can be anti-agile: effective relationships often take years to build.

Finally, management processes and scorecards can be anti-agile.  An organization that has been driven for ten years on a metric of sales margins, will take some years to convert to a return on capital metric or a sales volume metric.

So, when we design organizations or operating models we are often deliberately designing in aspects that will be anti-agile. Nevertheless, there is still benefit to the agile thought.  We need to think quite hard every time we make a design choice that is anti-agile, whether we are doing the right thing.  The simple question to ask is “once the new design is up and running, if circumstances change, how long will it take to change to another design both from a political and executional perspective.?”  For those of you who have used the tool “The nine tests of good organization design”, you will recognize the ninth test – “the flexibility test”.

Advertisements

About andrew campbell

Ashridge Strategic Management Centre Focus on strategy and organisation Currently working on group-level functions and group-level strategy
This entry was posted in Agile and operating models and tagged , , , , , , . Bookmark the permalink.

4 Responses to Operating models and agile

  1. Peter Murchland says:

    One of the questions that this prompts for me is:

    What are the principles that underpin good operating model design that reduce anti-agility in the resultant operating model?

    Are you suggesting that the nine principles aid in achieving this, Andrew?

    • andrew campbell says:

      No Peter. The nine principles/tests help you get to a good design. Only one of the principles/tests is about flexibility/agility. What is important is that you retain agility in areas where you anticipate change will be needed. Also, in general, where it makes no difference in other areas like cost or effectiveness, then a more agile choice is likely to be better than a less agile one. The things that reduce anti-agility are many and varied depending on the topic. So the cloud can help in IT systems. Cross functional career paths may help in capability building. Renting rather than buying may help with assets, etc.

      • Peter Murchland says:

        Andrew – I am surprised by your response.

        My own experience is that poorly designed enterprises are more difficult to change and improve ie. they are less adaptable and agile than others. I have just been looking through the nine principles again, and for each, I can see an aspect to how they would contribute to a more agile enterprise.

        There are some other principles that I think might be worth exploring. For example, there are situations where a person is able to be much more responsive to variant conditions than a machine, so achieving the appropriate “balance” of human vs machine capabilities would seem to be a principle underpinning more successful avoidance of anti-agility.

        I wonder if there are others?

  2. andrew campbell says:

    Peter, Interesting views. Of course people can be more anti-agile than machines: at least more actively resistant and politically difficult!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s