Agile Is About Flow, Not Speed
Organizations have been trying to become agile for quite some time now. This is a good thing. Interestingly, the predominant metric which is used to measure agility is ‘velocity’ –
how fast an organization is able to push new business capability and new products or services. But we tend to forget that it is not enough for an organization to push new capabilities –
its agility is also a function of how much its current business operations is able to absorb this change. This ability to absorb change cannot be improved just by communication and training where
most of the current change management efforts are focused. What is required is a more enterprise wide institutionalization of flow and customer centricity which most organizations are missing in their ‘
We need to understand that Agility is not a 100 m dash. It’s more like the decathlon – where one should be able to rapidly switch between sprinting, jumping, throwing, pole-vaulting
and whatever ‘ing’ is required to reach the finish line. How fast you sprint or how high you jump matters but how fast you’re able to switch from one to the other matters too.
Realities of Business Operations
In any business operations, process rules. Running like a ‘well-oiled engine’ or resembling ‘clockwork’ in motion, are often used to describe a matured operations function.
Productivity and resource utilization are sacrosanct. Speed of execution is paramount. But as we all know, activity is often mistaken for progress. Let me narrate a personal experience.
As a young Engineer Trainee in one of Nippon’s cold rolling units, one day our Lean Coach took us on a tour of the plant. We started from the annealing unit, passed cold-rolling, skin-passing,
cutting, galvanizing and finally the color coating area. Every unit was brimming with activity, machines were running on full capacity, tensed and burly supervisors were barking orders and scores of
engineers, technicians and operators furiously going about their work.
Adjoining the plant, there was a massive warehouse where all the finished rolls were transported on rails in small wagons and neatly stacked for delivery. As we walked across the warehouse, we sensed
a sudden drop in activity around us. As we made our way to the dispatch side, we saw a long line of large trucks neatly parked side by side. Surprisingly though, except some security guards and orderlies
doing routine housekeeping work, there was no one else to be seen. The place was deserted. There seemed to be no connection between the activities in the plant to this place.
Our plant used to dispatch finished goods once a week. Our production capacity was around 42000 tons per week. Our average actual production per week was 43200 tons. Yet, our average cycle time
for an order was 7 weeks and the average weekly dispatch was about 25000 tons.
Understand the problem. Our rolling mills and ancillary workstations were running super efficiently and surpassing their production targets. But 30% of what we were producing were ending up as inventory
in our warehouse.
Where was the problem?
Well, our customer orders entailed different grades of steel. To process a different grade of steel, our rolling mills had to be re-configured – both physically and electronically. On an average,
it took about 6 hours to changeover to a different category. This meant that even if we did one changeover every day, our weekly productivity would go down by 25%. Just like velocity today,
productivity was a sacrosanct metric then. So we were processing one category of steel first, often in excess of confirmed order in hand to stock for any future demand before changing over to the next category.
And more importantly, nobody was complaining – in fact, production team was constantly exceeding their production targets.
The fact that our state of the art Hitachi rolling mill could process 250 tons of steel every hour mattered less than the fact that it took 6 hours to reconfigure it.
Its speed of execution was
lightning fast, but speed of change pathetically slow.
How Flow Dramatically Improves Speed of Change
To ensure that work flows with minimum wait time, a production system should be able to synchronize supply with demand – which means any change in demand should be met by an equivalent change in supply
with minimum lag. How do you do that when you have shared, multi-skilled resources? You master the art of rapid reconfiguration. Your speed of change is lightning fast. If you’ve witnessed a shop floor
moving to flow from batch production, you’ll witness an exponential rise in the amount of physical activity – machines and people getting re organized rapidly and repeatedly. It resembles a system
in chaos but the reality is that its flow and agile in action.
Reducing changeover time is usually the first challenge any organization faces when adopting flow.
Over a 10 year period, Toyota relentlessly experimented with ways to reduce the die changing time in their stamping presses. Unlike its American competitors, it did not have the volumes to justify dedicated
stamping presses for different car models. Innovations like dies being carried by rollers instead of cranes, standardizing clamps which hook and unhook the dies to the press, modifications in presses so that
there are separate mechanisms for clamping in and clamping out dies, separate platform to station the new die on the press while the running die is still attached, etc.,
helped them bring down the
changeover time from the industry prevailing average of 24 hours to an astonishing 3 minutes.
This meant they could keep their batch sizes small, re-configure rapidly to process different body parts
from different car models with massive improvement in cycle time and almost zero inventory.
Complexity of People Re-Configuration
Let’s go back to our situation in Nippon.
Inspired by the likes of Toyota, we also went about reducing the changeover times for our rolling mills. But as we focused on the mechanics of the changeover, tweaking a process here and eliminating a process
there, we quickly got frustrated by a phenomenon none of us had anticipated.
On the shop floor, the two key players for any changeover were production and engineering. For any improvement in that process these two teams had to actively contribute and collaborate. However, to our surprise,
they were simply not playing ball. They were going through the motions but clearly the motivation was missing.
What was happening?
Well, rapid machine re-configuration is good but we have to remember that machines are run by people (still, some of them atleast).
As the machines get reconfigured, people have to mentally reconfigure
themselves too to take on the next set of tasks. The more different the next set of task is, the more difficult is the transition.
And in the absences of any incentive to quickly go over this transition,
people will resist. How well this transition is managed by an organization, irrespective of whether it’s a strategic or an operational one like the one we’re talking about here, is its real test
In our Nippon case, this is what was going on.
Production team was measured on productivity – which was calculated as tons per hour only when the mill was running. Changeovers, during which the mill was idle, did not have any effect on productivity.
On the contrary, changeovers gave the production staff a welcome break from their super stressful ‘no scope for error’ jobs at the helm of these very expensive rolling mills. They were all for
longer changeover times.
Engineering team was measured on machine availability. Changeovers required mechanical and electronic re-configuration of the mills which had to be done by them. Even though they were given
advance notice, availability of key staff was always a challenge because of unplanned breakdowns which would invariably happen. More the changeovers less would be machine availability. No wonder they
were all for no changeovers at all.
So, the 2 key functions – production and engineering – which had to come together to reduce changeover time were actually dis-incentivized to drive this goal – one wanted to actually increase
the time, while the other did not want it at all. Both went against the organizational goal of reducing changeover time and increasing the frequency of changeovers.
Does this sound familiar?
While we were focused on how the machines can be reconfigured rapidly, the willingness of business operations to reconfigure themselves in tandem, was clearly missing.
Similarly, we can focus on reconfiguring an IT system extremely rapidly but unless the end users are willingly adapting to this reconfiguration as rapidly, organizations are just creating digital inventory.
Institutionalize Flow to Institutionalize Agile
This state of transition – as an organization aligns its production line with the changes in customer demand – both short and long term – is when organizational agility truly manifests itself.
The changes can be introduced because of an operational changeover described above or because of a new capability established by embarking on a strategic project – but the criticality and time sensitivity
of this transitory phase is always paramount.
So, what can be done to improve this process and thereby organizational agility?
Organizations need to move away from what Dr. Goldratt described as the ‘cost world’ to the ‘throughput world. It has to adopt ‘flow’ and while people often do not understand this
connection, you cannot achieve flow without customer centricity. Specifically, what worked in that small operational changeover situation in Nippon is what will work in any scenario, in my view.
Change the Measurements – Move away from measuring productivity and start measuring throughput, which is just a measure of ‘customer orders delivered’. When wait time starts hurting,
any changeover will automatically get its due attention. Throughput will ensure that just pushing a finished product to the warehouse will not suffice – it has to reach the end customer to qualify.
In our example, longer the changeover, lower was the throughput and cycle time.
Re-define System Ownerships – If your car breaks down and you miss your appointment, you cannot blame the car manufacturer. It’s your car and its upkeep is your responsibility. The same is
applicable for all line / business functions. They own the systems which help them achieve their objectives even if they are not the experts of those systems. In our rolling mill case, configuration of the
rolling mill was no longer an engineering responsibility – it was operations. Within a year, changeover time dropped by 80%.
Broaden Role Definitions – An operator can be responsible for operating a machine or meeting production targets. In former case, the assumption is that he’ll operate if the machine is running,
if not, he will not. When the responsibility is to meet production targets, he’ll ensure that the machine better be always in running condition, there is a ready supply of raw materials to process,
finished products are being transported to the next workstation, etc. There is also a strong incentive to develop broader skills and become more business aware which is the foundation for organizational agility.
All the above changes bring about the much needed end-customer and market awareness which sometimes gets lost in departmental silos.
And if business operations is customer focused and measured by their
agility to meet the ever changing customer needs, they’ll embrace the changes being pushed at them by the ‘Agile’ build, innovation and project side of the organization.
It’s actually simple. The challenge though is to cut through what I call the mechanics of agile (read techniques and models and ceremonies) and embrace the physics (read principles and customer centricity)
So, to conclude, organizational agility is a function of both speed of change and speed of execution. Following good agile practices we might be releasing a new product earlier or modernizing an existing system
faster, but remember that on the other side existing business operations has to re-configure itself to support the new product or work with the new system. In the prevailing agile narrative in the industry,
there is a lot of focus on the change generation side but relatively less on the change absorption side. But unless the two sides are in sync, result will be exactly what agile promised to eliminate –