We Are Experiencing Unusual Call Volumes
This (seemingly standard) IVR message particularly irks me. Queues arise out of mismatches between supply and demand. Sometimes these mismatches are temporary, with the queue acting as a buffer to smooth a variable demand. In other places, however, the mismatches are systemic, where the queue behaves as a regulator, limiting access to supply.
“Takt” in a Lean Production System is defined as the pace of customer demand. Specifically, if the production system is a “pull” system, the takt time is the rate at which the production line needs to be working at in order to perfectly satisfy demand. Takt is an average, though, so given natural variability there are going to be times where demand is higher than normal, and a queue will form – but these are matched by times of lower than average demand, when the queue will clear.
Takt is a particularly useful concept in production systems because it is a core statistic in ‘levelling’ (heijunka), so that all processes within the system have similar utilization rates, and the system is therefore working without bottlenecks.
Is Takt Applicable to Agile?
Many concepts from Lean and the Toyota Production System (TPS) are useful to describe Agile systems. Lead time, cycle time, throughput, waste etc etc. So what about takt – is that applicable to Agile?
From a system design perspective, it would be great if takt was pertinent to Agile systems. Bottlenecks are often observed to form within Scrum and Kanban – for example at the Design phase, Development phase, or (quite commonly) Testing. If we could determine the takt, then perhaps we could resource our software development teams to work at maximum efficiency?
So what would takt be in Agile/software terms? If the Product Manager/Owner (PM) is considered the customer, then we are in trouble …because everyone knows that a Product Manager’s demands are infinite! There is always “too much to do” in software. Agile systems clearly do not work at the PM’s takt! In fact, despite attempts to change it, software development as a Value Stream is rarely a ‘pull’ system – it is most often a ‘push’ from the PM, and not a real-time response (pull) to a customer demand at all.
So what about support & operations teams. Maybe the rate of reported bugs could be treated as the system takt? This is more compelling, and is the way good operations teams working under Service Level Agreements are resourced. However, such ‘pull’, coming as it does from failure demand, isn’t Agile in the normal sense, and anyway, operational support is normally triaged and queued. Both triaging (prioritizing) and queuing are mechanisms that buffer the system from takt.
The largest queue in Agile is the backlog, but the backlog is rarely the result of customer demand as a random process. Customer demand has been queued, and takt replaced by the (artificial) cadence of the Sprint. However, as Agile continues to evolve, and feedback loops continue to shorten with DevOps, #nocode, and AI, I am hopeful that maybe we can reclaim takt, and finally take our customers off ‘hold’.