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.

8 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!

  3. Alex Graham says:

    Hi Andrew,

    Really interesting post, thanks. I’ve also been thinking on Agile and OD recently, mainly driven by a project need to do some OD within a IT Development Team for which the natural way of working was Agile Scrum.

    My reflections on this experience were that there is much that can be learned from this design mind-set. I wholeheartedly agree with your comment about design efforts being “intent” rather than “plan” driven, and the importance of effectively delegating the detail of design realisation down to teams operating in an agile way. I would also add three of my own Agile design insights that I think are worthy of reflecting on in relation to Op Model type work. Firstly, there is much to be said for the Agile manifestos disdain of overdesign which can probably be best thought of as over specification in an Op Model / Org Design sense. For example, the efforts that can be put into ‘perfecting’ job descriptions which are rarely read more than once by the eventual role holders and then rapidly becoming out of date and effectively obsolete. Secondly, the Agile bias to focus on making some (typically small but demonstrable) value adding changes quickly rather than attempting to complete a comprehensive design before enacting change can really help to build momentum (rather than sap it) during re-design efforts. However, clearly this needs to be balanced with thinking through any unintended consequences or interactions with other later changes. Finally, the Agile view that the deisgn work is never done, rather continually refined, tweaked and re-released I find a helpful perspective, it would be interesting if organisation designs were iterated and formally relaunched like smart phones…

    I further concur with your point of view on the anti-agile nature of some Op Model / Org Design changes. I interpret your examples as essentially strategic choices inherent in enacting Op Model / Org Design implementation. These by their very nature involve a strong commitment and/or investment. If a supposedly strategic decision can be easily pivoted away from and changed I question if this is truly a strategic choice. The other aspectic of the anti-agile nature of Op Model change I would highlight is the learning cycles necessary for people who have undergone Org Design type change, clearly it takes time for people to understand and absorb changes to their roles and ways of working, a crude rule of thumb my colleagues and I use use to good effect (although to my knowledge empricially untested) is a cycle of 6 learning loops before a change can be viewed as embedded, and moreover an assessment of success made. For a frontline manager or employee this could conceivably be around 6 weeks but as one moves up the hierarchy and management time horizions (should) lengthen and this moves out to several months. So, in this instance being agile and pivoting the design could be quite damaging. A concern I often find here when asking managers about the last organisational change is that “we never really emebeded the last change (and therefore didn’t realise the benefits) before we started changing it all over again”.

    • andrew campbell says:

      Alex, Very thoughtful and helpful. Thank you. I was working on an organization design for a merger in Germany this summer and I am certain that some test and learn loops would have helped us get to a better solution. The design work was done in six weeks – but I expect that the implementation will take a year or two and the final result will be some way from the original design (for the better!)

  4. The ‘Change Management’ discipline (see “Kubler-Ross curve”) almost explains why Agile Operating Model change is difficult. Even the best designed organisations are have people in them and people are often resistant to change. Any ‘operating model design’ could be changed on paper many many times before the first change has been embedded into the organisation. Should we worry about ‘agile operating model design’ or focus first on achieving ‘agile people change’ ?

    • andrew campbell says:

      I think agile people change could be an oxymoron. People are only agile about change if the change is helping them get somewhere they wanted to get anyway. If the change is taking them away from somewhere where they are comfortable, then they become anti-agile. Implication: spend more time persuading people that the change is something they wanted to do anyway.

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