Push, pull, or flow

The optimum depends on your context, but flow-based systems generally perform best for knowledge work and software delivery. Here’s why:

Push Systems: Predictable but Fragile

Push systems work when demand is predictable and processes are stable. Manufacturing assembly lines are classic examples. However, in software delivery, push creates several problems:

– Work queues build up at bottlenecks

– Resources get over-allocated based on plans rather than capacity

– Teams lose autonomy as work is assigned rather than pulled

– Waste accumulates as partially completed work sits waiting

Pull Systems: Responsive but Can Starve

Pull systems like Kanban improve on push by having downstream processes request work when they have capacity. This reduces waste and improves flow, but pure pull can create issues:

– Upstream processes might starve waiting for pull signals

– Overall throughput can be limited by the most conservative puller

– Coordination complexity increases across multiple teams

Flow Systems: The Sweet Spot

Flow-based delivery optimizes for continuous movement of value through the system. Instead of pushing work or waiting for explicit pulls, flow systems focus on:

– Limiting work in progress to prevent overload

– Identifying and resolving bottlenecks systematically

– Maintaining steady cadence without overwhelming any part of the system

– Optimizing for end-to-end delivery time rather than local efficiency

The Practical Optimum

Most successful delivery organizations use flow principles with pull mechanisms:

– Teams pull work when they have capacity (pull)

– But work is sized and sequenced to maintain steady flow

– Bottlenecks are actively managed rather than allowed to create starvation

– Metrics focus on flow efficiency (cycle time, throughput) rather than utilization

This hybrid approach gives you the responsiveness of pull with the predictability of managed flow, while avoiding the rigidity of pure push systems.

The key insight: optimize for the speed of value delivery, not the efficiency of individual resources.

Unknown's avatar

Author: Mario Aiello

Hi, I’m Mario – retired agility warrior from a major Swiss bank, beyond agile explorer, lean thinker, former rugby player, and wishful golfer. I’ve been in the agile space since 2008. I began consulting in 2012 with a Scrum adoption in a digital identity unit — and that path eventually led me to design an Agile Operating System at organisational scale. What pushed me further was frustration: poor adoption, illusionary scaling, and “agile” that looks busy but doesn’t improve business outcomes. That’s why I developed the Adaptive Fitness System (AFS) — an approach that treats agility as fitness for change: fit for purpose, fit for context, fit for execution, and fit for continuous improvement. Today, I use AFS to help organisations sense what’s real, learn fast, and adapt with intent.