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”.