Flow theory in short

 

Companies often build their software development as a series of handoffs.

Every handoff is a queue.

Queues determine how long work waits.

The busier the person receiving queued work is, the deeper the queue becomes, and the longer work waits to be served. 

A common mistake is to obsess over developer cycle time (ticket closure) and ignore the rest of the process.

For flow reasons, it is better for people to be waiting on work than for work to wait on people.

Rejection loops send work products back to earlier stages, disrupting waiting work and delaying release.

Rejection loops in the process make prediction for all work products difficult, if not impossible.

Collaboration, quality practices, small batches, trunk-based development, and early feedback all work because they improve First-Time-Through and reduce rejection loops. Ignoring those kinds of measures means you have no flow protection.

Once rejection loops become rare, the remaining delays are largely visible and manageable.

Ignore these basic facts, and delivery cannot be efficient, quick, or predictable.

Skill matters. especially if you can produce code that will pass all the quality gates on the first try. Eliminating rework and re-queuing by raising quality is a powerful tactic.