Process improvement

See when delivery has actually changed.

Nave separates meaningful signals from normal variation, so you know when to investigate, where to look, and whether the process stabilizes at a different level.

Nave Process Improvement dashboard for the Payments API team: Cycle Time stable at 16 days within its limits of 7 and 22 days, and Throughput stable at a daily completion rate of 0.2, each with Nave's guidance and the items to review; below them, Work in Progress Age is unstable and Work in Progress is at risk

The problem

Not every movement means something is wrong.

  1. Cycle time goes up,

    so we introduce a new practice.

  2. WIP goes up,

    so we change a policy.

  3. Throughput drops,

    so we start asking what the team needs to do differently.

Then the number moves again. And we have no idea whether our change caused it, or whether we were reacting to normal variation in the first place.

Without knowing what normal variation looks like, every movement can look like a reason to intervene.

“If I interpret the problem as low development speed, I will probably look for ways to speed up the developers and may put resources in the wrong part of my flow, making the problem even worse.”

Joelma Castro Agile Master and Squad Leader
Read the story

The method

How Nave separates signal from normal variation.

  1. Your delivery history sets the limits.

    Nave calculates natural process limits from your own delivery data, using the average and average moving range. The limits show the range of variation your process has historically produced.

  2. Fixed rules identify the signal.

    Nave applies four detection rules to identify changes outside normal variation, from a point beyond a process limit to patterns developing over several data points.

  3. The baseline updates as your process changes.

    Nave uses recent delivery data to establish the baseline. When a signal appears, the limits freeze. Once enough new data arrives, the baseline is recalculated.

Every metric and signal is calculated deterministically from your delivery data, so the same data produces the same result. AI only analyzes the results afterward.

This method comes from statistical process control, an established approach used for decades to separate signal from routine variation.

Flow metrics

Six flow metrics, one question.

Each card asks the same question of one metric: is this part of your delivery system predictable?

  • Work in Progress

    The number of items in progress each day.

  • Cycle Time

    How long each finished item took.

  • Throughput

    The number of items finished each day.

  • Work in Progress Age

    The total age of the items currently in progress.

  • Cycle Time per Process Step

    How long work spends in each stage of your workflow.

  • Flow Efficiency

    The share of cycle time spent actively working once your waiting stages are defined.

Stable
The metric is varying within its normal range.
At risk
The current value is at the edge of its upper limit.
Unstable
A signal shows the metric is higher or lower than normal.
No data
Fewer than 4 data points are available.

Improvement loop

From signal to measured change.

Detect the signal, investigate the evidence, make one targeted change, and measure what happens next.

  1. Detect

    Know when something has actually changed.

    Natural process limits separate meaningful signals from normal variation. When a metric leaves its expected range or develops a signal pattern, the card shows you where to look first.

    Nave Process Improvement card Cycle Time per Process Step for the Payments API team: unstable, Ready for SIT cycle time at 8 days, above its high limit of 7 days; Nave's guidance: your Ready for SIT cycle time is too high, focus on assessing the issue that caused the delay, with item 1110 at 8 days
  2. Investigate

    Find what is driving the signal.

    Each card tells you what to review and identifies the work items behind the signal. Nave’s AI Investigator can take it further, reading the computed metrics, identifying the stage and items behind the problem, and showing you the evidence. It tells you where to look and what to fix.

    Nave AI Investigator insight for the Payments API team, marked Urgent: 18 items are stuck in Ready for SIT, the stage is acting as a dam, not a queue. Ready for SIT holds 18 of the 23 current WIP items, with the top 5 sitting there for 19 to 21 days against a stage p95 of 7 days; the exit is controlled by SIT capacity, 0.43 a day against 0.62 a day arriving. Next steps: investigate what limits SIT throughput and address that specific constraint; until SIT capacity increases, consider throttling new work entering In Development to match the SIT rate

    The numbers are computed, not generated. The AI only reads them, so swap the model and the numbers don’t change.

  3. Intervene

    Make one targeted change.

    Use the evidence to intervene where the problem actually is, rather than changing the whole process because a metric moved.

    Before you intervene, answer three questions.

    1. What problem are we trying to solve?
    2. What are we going to change?
    3. What would we expect to see in our data if that change actually worked?
  4. Measure

    Measure what happened next.

    After the change, use the next period of delivery data to see what happened. As new data arrives, the limits rebuild and show whether the process stabilizes at a different level.

    1. Signal detectedDetect
    2. Evidence investigatedInvestigate
    3. One targeted changeIntervene
    4. New data arrivesMeasure
    5. Limits rebuild
    6. Did the system stabilize at a different level?

“You don’t need to pursue a better lead time or flow efficiency, you need to pursue better value for your customers.”

Eduardo Pinzon Delivery Manager, Syngenta Digital
Read the story

Predictability

Once the system is stable, you know what it can reliably do.

Green doesn’t mean good. Green means predictable.

A stable process gives you a reliable baseline. You can decide whether its current performance is good enough and use its delivery history to forecast what you can deliver.

A process can be predictable and slow. What your system can reliably do today may still be different from what you want it to do.

Explore Continuous Forecasting

Questions

Questions about the Process Improvement Dashboard

No. Nave uses deterministic statistical calculations and fixed detection rules so the same delivery data always produces the same signal, which can be checked against the underlying data rather than relying on a model’s interpretation. The AI Investigator only reads the computed results afterward to help investigate the stage, work items, and evidence behind a signal.

Nave needs at least 4 data points. By default, it uses the 20 most recent data points within the last three months.

No. The limits describe how your process actually behaves, while a limit you choose would describe what you want from it. Nave calculates them from your team’s recent delivery data and recalculates the baseline as the process changes, so signals are measured against the process’s own behavior.

A faster cycle time is flagged because it falls outside the variation the process has shown so far. If that behavior continues for four new data points, Nave recalculates the baseline and moves the limits to reflect it. Until then, check the quality of the work that moved through the step faster.

It is the first page of every team dashboard and the view a board opens on. Each metric card links to the chart behind it, such as the Aging Chart or Cycle Time Scatterplot.

Know when to act. Know where to look.