Let me start with a definition of agile as it applies to operating models or processes: “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? First, when making changes to a process or an operating model, an agile approach is probably wise. Instead of planning it all out and then executing, an agile approach involves making some changes quickly, then reassessing, then making some more changes: the fire, aim, fire aim approach rather than the ready, aim, fire approach. Of course, in many tall hierarchies, the agile approach to change 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 and plan. 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 an operating model that are not, and never will be, agile. In fact success 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 to win a supply contract from 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 the customer. This capacity and technology can then become legacy problems if the customer changes its needs in subsequent years. Yes you can build flexible capacity and systems, but typically these are more expensive than dedicated solutions. So there is a trade-off: more agility can raise costs and reduce the chance of winning the contract.
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 leader can be changed.
If we think through the components of an operating model – processes, organisation, location, information, suppliers and management system ( as explained in the Operating Model Canvas) – we can see the tensions that agile raises. A process needs to be “leaned” to deliver a particular value proposition efficiently. But this will make the process costly or less effective for delivering slightly different value propositions: leaning the process can make it less agile
Organization structure, even if controlled by holacracy (the self organizing methodology), takes time to change: in other words any form of organization is in part anti-agile. But, at the same time, complete disorganization is even more 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 relationships, attractiveness for employees, etc. So location can be a major source of rigidity. One of the attractions of the ‘cloud’ is its lack of location.
Information systems are frequently a cause of rigidity. When managers talk about legacy systems they really mean systems that constrain their ability to change. There is frequently no way round the problem. Off-the-shelf software applications often force the organisation to operate in one way. Bespoke applications, because of their cost, can introduce even more rigidity.
Supplier relationships are frequently anti-agile: effective relationships take years to build and cannot be abandoned at a week’s notice.
Finally, management systems 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 operating models, we are often deliberately designing in aspects that will be anti-agile.
This does not mean that the agile thought is unhelpful. It causes us to think hard every time we make a design choice, whether the choice is increasing or reducing agility. 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.?” The shorter the time frame the better. But we will still often make choices that are anti-agile (take months or years to change) because of our need today to drive lower costs or improve customer benefits.
