Queuing Theory Simulator

Work Item Colours

Queue Bars

The horizontal bar under each stage shows queue depth. When it fills up, work is piling up faster than it can be processed. A full bar indicates a bottleneck.

Servers (Circles)

Each circle represents a “server” (developer, tester, or machine). When a server is processing work, it’s filled. When idle, it’s empty. Multiple servers process in parallel.

Metrics Dashboard

• Throughput: Items completed per time unit
• Lead Time: Total time from arrival to completion
• Wait Time: Time spent in queues (not being worked on)
• Utilisation: Percentage of time servers are busy
• Flow Efficiency: Work time ÷ Lead time (how much time is “value-add”)

Blocking as Blame Culture

High blocking percentages often correlate with poor psychological safety. When teams fear blame for integration failures, they add more review gates and approval steps, which increases blocking probability. The simulation shows why “more process” often makes things worse.

Rework as Technical Debt

Rework represents the “hidden factory”: capacity consumed by fixing defects that should have been caught earlier. High rework rates indicate poor requirements, insufficient testing, or rush-to-deploy pressure.

The Utilisation Trap

Management often optimises for utilisation (keeping people busy), but the simulation shows this destroys flow. At 90%+ utilisation, queue times explode exponentially. The counterintuitive truth: slack capacity is essential for flow.

Handoff Friction

Each stage boundary represents a handoff: context lost, waiting for availability, re-explanation. The simulation’s two-stage model is a simplification; real organisations often have 5-10+ handoffs, each multiplying delay and error probability.

M/M/c Queue Model

The simulation relies on Kendall’s notation for queuing nodes:

• M (Markovian Arrivals): Arrival times follow a Poisson process (Exponential distribution).
• M (Markovian Service): Service times follow an Exponential distribution.
• c (Servers): The number of active servers (developers/testers) processing the queue.

Exponential Distribution

• Origin: Probability theory; fundamental to Poisson point processes.
• Concept: Describes the time between events that occur continuously and independently at a constant average rate. It models real-world variance where most tasks take an average time, but some are very quick and others take much longer.

In Simulation: Used to generate randomized arrival times for new work items and the duration of service (work) for each server, ensuring the simulation reflects realistic variability rather than static averages.

// Generate random values following an Exponential distribution
// Used for arrival times (Poisson process) and service durations
const getExponential = (rate: number) => {
    return -Math.log(1 - Math.random()) / rate;
}

// Generate next arrival time
data.nextArrivalTime = getExponential(params.arrivalRate) * 1000;

Little’s Law

• Origin: John Little (1961), Operations Research.

• Concept: The long-term average number of items in a stationary system ($L$) is equal to the long-term average effective arrival rate ($\lambda$) multiplied by the average time an item spends in the system ($W$).

In Simulation: Used to validate the statistical metrics displayed in the dashboard. It proves that if you cannot change the arrival rate ($\lambda$), the only way to reduce Lead Time ($W$) is to reduce the Work in Progress ($L$).

// Verify simulator metrics against Little's Law (L = λ * W)
// avgSystemLength (L) ≈ arrivalRate (λ) * avgSystemTime (W)
const stats = {
    avgSystemTime: s1.W + s2.W,     // Total time in system (W)
    avgSystemLength: s1.L + s2.L    // Total items in system (L)
};

Erlang-C Formula

• Origin: A.K. Erlang (1917), Telecommunications traffic engineering.

• Concept: Calculates the probability that a randomly arriving item must wait in the queue rather than being served immediately, given the traffic intensity and number of servers.

In Simulation: Provides the “Theoretical” baseline for wait times. Comparison between this theoretical baseline and the “Actual” simulation results highlights the extra friction caused by factors Erlang-C doesn’t account for, such as blocking and rework.

// Calculate Erlang-C probability that an item must wait
const calcErlangC = (lambda: number, mu: number, c: number) => {
    const rho = lambda / (c * mu); // Traffic intensity
    
    // Calculate sum of geometric series for P(0)
    let p0_inv = 0;
    for (let i = 0; i < c; i++) {
        p0_inv += Math.pow(lambda / mu, i) / factorial(i);
    }
    p0_inv += (Math.pow(lambda / mu, c) / factorial(c)) * (1 / (1 - rho));
    
    // Theoretical average queue length (Lq)
    return (Math.pow(lambda / mu, c) * rho * (1 / p0_inv)) / 
           (factorial(c) * Math.pow(1 - rho, 2));
};

Flow Efficiency

• Origin: Lean Manufacturing / Toyota Production System.

• Concept: A metric measuring the percentage of time work is actually being progressed versus sitting idle. In knowledge work, this is often shockingly low (10-15%).

In Simulation: Calculated dynamically by tracking the exact milliseconds an entity spends being “serviced” (Active Work) versus “waiting” or “blocked”. It visualises how high server utilisation can coexist with terrible flow efficiency.

// Track value-added time vs total lead time for every item
if (Math.random() < 0.1) { // 10% sampling rate for UI updates
    const flowEff = data.metrics.totalSystem > 0 
        ? (data.metrics.totalValueAdded / data.metrics.totalSystem) * 100 
        : 0;
        
    setSimState(prev => ({ 
        ...prev, 
        flowEfficiency: flowEff 
    }));
}