Flow Where You Can Pull Where You Must

Flow isn't a religion. Pull isn't a cult. But the way some people talk about them, you'd think you had to pick a side, memorize the catechism, and defend it against heretics.

Here's the thing: the best systems I've seen — the ones that actually ship, scale, and survive contact with reality — don't choose. Plus, they hybridize. Worth adding: they flow where flow makes sense. They pull where pull protects the system.

And the boundary between them? That's where the real design work lives.

What Is "Flow Where You Can, Pull Where You Must"

The phrase comes from lean thinking, specifically from the Toyota Production System lineage, though you'll hear variations in Kanban, Theory of Constraints, and modern DevOps circles. The core idea is disarmingly simple:

Flow means work moves continuously, single-piece if possible, through a defined sequence of steps without waiting. No queues. No batches. No "we'll do these five together." The ideal is one piece, moving, always moving.

Pull means downstream signals upstream: "I'm ready for the next one." Upstream doesn't push. It waits for the signal. The kanban card, the empty bin, the open slot on the board — that's the trigger.

"Flow where you can, pull where you must" says: design for flow as your default. A buffer. So a signal. But wherever flow breaks — because of variability, shared resources, external dependencies, or capacity mismatches — insert a pull boundary. A place where the system breathes.

It's not a compromise. It's a recognition that pure flow is a theoretical limit, not a universal achievable state.

Where the Phrase Comes From

You'll see it attributed to various lean thinkers. Worth adding: mike Rother's Toyota Kata* touches on it. Think about it: the Kanban community (David Anderson, Klaus Leopold) talks about "flow systems with pull boundaries. " Eliyahu Goldratt's drum-buffer-rope is essentially the same insight dressed in different language: the drum (constraint) sets the pace, the buffer protects it, the rope pulls work in sync.

None of them treat it as a slogan. They treat it as a design principle.

Why It Matters

Most organizations don't ignore this principle — they invert it. They push everywhere, then wonder why lead times balloon, quality drops, and people burn out.

Push creates the illusion of utilization. Day to day, everyone looks busy. But busy isn't throughput. Busy with the wrong thing at the wrong time is just expensive inventory — whether that inventory is code waiting for review, parts waiting for assembly, or features waiting for a release train.

Flow where you can eliminates the waste of waiting. Pull where you must prevents the waste of overproduction.

The Cost of Getting It Wrong

I've watched a team try to flow a process that had a hard external dependency — a vendor API with unpredictable latency, a compliance review that took "two to six weeks," a shared environment that went down every other sprint. They just... And hoped. hoped. On the flip side, they didn't put a pull boundary there. And the whole value stream stalled behind that one uncontrollable step.

Conversely, I've seen teams put pull boundaries everywhere*. Flow died of bureaucracy. The board became a maze of columns, each with a WIP limit of one. Every role. Here's the thing — every day. Every handoff. Lead time didn't improve — it got worse, because work spent more time waiting for a signal than doing anything useful.

The art is knowing the difference.

How It Works in Practice

Let's make this concrete. Imagine a software delivery value stream — but the pattern applies to manufacturing, marketing, hardware, anything with sequential steps and variability. Easy to understand, harder to ignore.

Step 1: Map the Value Stream Honestly

Not the idealized version. On top of that, the real one. On top of that, where does work actually wait? Where does it loop back? In real terms, where do people expedite? Where does the "urgent" thing jump the queue?

You're looking for two things:

• Flow candidates: Steps that are stable, repeatable, under your control, with low variability. Coding a well-understood feature. - Pull boundaries: Steps with high variability, external dependencies, shared constrained resources, or batch-by-necessity operations. Legal sign-off. Also, hardware provisioning. Security audit. Running an automated test suite. Worth adding: code review (if reviewers are shared). Assembling a standard sub-component. The deployment window that only opens Tuesdays.

Step 2: Design Flow Segments

Inside a flow segment, you want:

• Single-piece flow (or as close as practical)
• No internal queues
• Clear definition of done for each micro-step
• Visual management so anyone can see status instantly
• Fast feedback loops — automated tests, pairing, andon-style escalation

A flow segment might be: "Developer picks up story → writes code → runs local tests → pushes → CI passes → deploys to staging.Which means " All one person, one machine, one continuous motion. Also, no handoffs. No waiting.

Step 3: Insert Pull Boundaries at the Seams

Where a flow segment meets something it can't control, you put a kanban. A real one — not a column on a board that everyone ignores.

The pull boundary has:

• A WIP limit that reflects the downstream capacity, not upstream ambition
• A clear pull signal — an empty slot, a card moving, a notification
• Explicit policies — what "ready" means, who can pull, what happens when the limit is hit

Example: The team flows code to "Ready for Security Review." Security has a WIP limit of 3. When they finish one, they pull the next. Devs stop* pushing when the limit is hit. They swarm, they refactor, they pick up tech debt — but they don't create a fourth item waiting in a virtual queue.

Step 4: Manage the Buffers

Pull boundaries create buffers. Buffers are inventory. Inventory hides problems — but zero buffer kills flow when variability hits.

The right buffer size is the smallest one that protects flow most of the time*. Not all the time. Most.

If your security review takes 1–3 days and you release every two weeks, a buffer of 2–3 items might be right. If it takes 2–6 weeks, you need a different strategy — maybe a dedicated reviewer, maybe a pre-review checklist that catches 80% of issues before the formal step.

Buffer sizing is an experiment. And measure flow metrics (lead time, throughput, WIP age). Start small. Adjust.

Step 5: Close the Loop with Metrics That Matter

Don't track utilization. Track:

• Lead time (request to delivery)
• Cycle time (start to finish of the flow segment)
• Throughput (done items per time period)
• WIP age (how long has the oldest item been in progress?)
• Flow efficiency (value-add time / total lead time)

Flow efficiency is the killer metric. Plus, pure flow approaches 100%. That's not failure — that's physics. So naturally, real systems with pull boundaries run 15–40%. The goal is to improve it where you can*, not to pretend it's 100% everywhere.

Common Mistakes

Mistake 1: Treating "Pull" as "We Have a Kanban Board"

A board with columns is not a pull system. A pull system requires:

• WIP limits that are enforced*, not aspirational
• A pull signal that stops upstream work* when downstream is full
• Policies that everyone follows, even (especially) when it's inconvenient

If devs keep pushing cards into "In Review" past the WIP limit because "it's almost done," you don't have pull. You have a board with decorations.

Mistake 2: Flow-Washing Batch Processes

"We do continuous flow!The security audit is quarterly. " — but the deploy happens once a month. The hardware order takes six weeks.

You can't flow through a batch constraint. Even so, you can only flow up to* it. That's why the batch step is the pull boundary. Pretending otherwise just hides the queue.

Mistake 3

Mistake 3: Ignoring the Human Element

Implementing pull without addressing team dynamics is like installing a traffic light in a town with no rules. The system fails when:

Continue exploring with our guides on what is a dry cell battery and how does platinum make nitric acid.

• People game the metrics instead of improving flow
• Local optimizations override system-wide goals
• Fear of stopping work leads to hidden work-in-progress
• Lack of psychological safety prevents honest discussion of bottlenecks

The technical mechanics are straightforward. The human element is where most implementations stumble.

Making It Stick

Pull systems require cultural change, not just process change. Start by making work visible, then make the policies explicit, then enforce the boundaries, and finally measure what matters.

The goal isn't perfection—it's progress. Here's the thing — every sprint where the team stops adding work to a full queue is a win. Every deployment that doesn't require heroic effort is a victory. Every conversation about flow metrics instead of utilization rates is forward movement.

Remember: pull systems expose problems rather than hide them. This feels worse before it gets better, but it's the only way to sustainable improvement.

Pull is not about control. It's about creating the conditions where the team naturally pulls work through the system, stopping when they should, starting when they can, and continuously improving how they work together.

Scaling Pull Across Multiple Teams

When a single squad begins to experience the benefits of pull, the natural next step is to extend the cadence to other groups that depend on the same delivery pipeline. Scaling isn’t a matter of copying the same board layout; it’s about synchronizing the pull signals that define each downstream boundary.

1. Nested Pull Loops – Treat each team’s workflow as a sub‑system with its own WIP limits, but expose a pull trigger* to the upstream team. As an example, a feature team may only begin development once the upstream integration team signals that a set of stubbed APIs is ready and has capacity. The trigger can be a simple “ready” column on a shared board or an automated API health check that flips a flag.

2. Shared Capacity Pools – Instead of assigning fixed headcount to each stage, create a pool of “flow‑capacity” that any downstream team can draw from, subject to the pool’s overall WIP ceiling. This prevents one team from monopolizing a bottleneck (e.g., QA) while others sit idle.

3. Lead‑Time Forecasting – When multiple teams share a common upstream service, the service owner can publish a rolling forecast of available capacity based on historical flow efficiency. Downstream teams use this forecast to plan their own pull windows, ensuring they never request more work than the upstream can actually deliver.

4. Cross‑Team Retrospectives – Schedule regular, joint retrospectives that focus exclusively on hand‑offs. The goal is to surface hidden hand‑off delays, negotiate realistic pull thresholds, and agree on shared definitions of “done.” Because the data (cycle time, flow efficiency) is already transparent, the conversation stays fact‑based rather than devolving into blame.

Measuring What Really Matters

Most organizations fall back on traditional utilization metrics when they try to “prove” the value of a pull system. Those numbers are misleading because they ignore the quality* of the flow. Instead, track the following leading indicators:

When these metrics are visualized on a public dashboard, the team can see the cause* of any slowdown instantly—whether it’s a new bottleneck emerging or a policy being ignored. The data becomes a conversation starter, not a performance weapon.

Continuous Improvement Loops

Pull is not a static configuration; it is a living system that evolves as the organization learns. The improvement loop can be broken down into four repeatable steps:

1. Observe – Collect flow data and listen for anecdotal friction points during daily stand‑ups or informal chats.
2. Hypothesize – Form a testable theory about the root cause (e.g., “The QA queue spikes every Thursday because the test environment is only available on weekdays”).
3. Experiment – Design a small, time‑boxed change (e.g., allocate a dedicated “test‑environment hour” on Thursdays) and measure its impact on cycle time.
4. Adapt – If the experiment yields a measurable gain, make the change permanent; if not, revert and iterate.

Because each experiment is bounded, it never jeopardizes the overall flow. The team can run dozens of such cycles per quarter, gradually tightening the system until the overall lead time shrinks to a level that meets business expectations.

Real‑World Example: From Monthly Release to Continuous Delivery

A mid‑size SaaS company previously shipped a major feature set once a month. Their “pull” board looked impressive, but the deploy step was still gated by a quarterly security audit and a manual release checklist that took two weeks to complete.

By applying the pull‑principles outlined above:

• Pull Boundary Redefinition – The security audit was treated as a downstream service with its own WIP limit. The audit team agreed to run a continuous* static analysis scan on every commit, turning the quarterly gate into a continuous* gate with an automated pass/fail flag.
• Capacity Pooling – The release engineering group formed a shared “release‑capacity” pool of two engineers, each with a strict limit of three concurrent release pipelines.
• Lead‑Time Forecasting – The product owners began publishing a weekly forecast of release‑ready items, allowing feature teams to plan their pull windows accordingly.

Within three months, the organization moved from a monthly, high‑risk release to a continuous delivery pipeline where every change that passed the automated gates could be deployed to

The moment the automated security scan began to run on every commit, the “deploy” column on the pull board shifted from a bottleneck to a trigger. As soon as a change received a green pass, it entered the “ready for production” lane, where the release‑capacity pool pulled the item into a staging environment that mirrored production. Because of that, automated smoke tests validated the deployment in seconds, and a single‑click approval from the on‑call engineer moved the change to live. Because the WIP limit for the release lane was capped at three concurrent pipelines, the team could safely manage multiple releases without the chaos of overlapping manual hand‑offs.

Within the first month of this new flow, the lead time from code commit to production dropped from an average of 22 days to 4 days, and the proportion of changes that required a manual “release freeze” fell from 78 % to 4 %. Consider this: cycle time for the QA queue, which had previously spiked every Thursday, flattened after the dedicated “test‑environment hour” was introduced, reducing the average wait from 18 hours to under 30 minutes. The cumulative flow diagram on the public dashboard showed a steady downward slope, and the team’s burndown chart revealed a consistent velocity increase without any overtime spikes.

Beyond the numbers, the cultural shift was evident. Think about it: the product owners, empowered by the weekly lead‑time forecast, began prioritizing items that could move through the system quickly, rather than hoarding large batches for the next monthly release. Daily stand‑ups now included a brief “pull health” check, where anyone could point out a new constraint or a policy that was no longer serving the flow. This alignment of business goals with the technical cadence created a virtuous cycle: faster feedback led to higher quality, which in turn reduced rework and further accelerated flow.

Scaling the model to other divisions was straightforward. Think about it: the same pull‑boundary definition, capacity‑pooling, and experiment‑loop structure were replicated in the mobile‑app team, which previously suffered from a “feature freeze” that delayed every third sprint. By introducing a continuous integration gate for automated UI tests and limiting the number of active feature branches, they achieved a 60 % reduction in cycle time and were able to ship small increments twice a week.

Simply put, the pull‑system’s strength lies in its ability to surface constraints, enable data‑driven experimentation, and keep the organization focused on delivering value continuously. Also, when policies, metrics, and team structures are aligned around the flow of work rather than on periodic, gated milestones, bottlenecks become visible, experiments stay contained, and the entire enterprise moves faster with lower risk. The transformation from a monthly, high‑stakes release to a continuous delivery pipeline demonstrates that a well‑designed pull mechanism is not just a tool for a single team—it is a catalyst for organizational agility and sustained competitive advantage.