Tools I build
I built Flow Observatory to investigate how work moves through a delivery system, record changes worth testing and review what happened afterwards. It brings the evidence, the decision and the follow-up into one workspace.
In development.
A working application. The examples here use simulated work, not company data.
Why I built it
A delivery review can identify a growing queue without settling what to do about it. The observation needs an explanation, a decision and someone who will return to the evidence.
Flow Observatory brings those steps together. A proposed change can carry its expected result and safeguards into the next review, alongside the observation that prompted it.
A walkthrough
01
One item is marked as blocked, and the waiting columns hold no unblocked work. The delay sits with a single item, not in a queue, so you know where to look first.
Examine that item’s history to see what stopped it and for how long. One snapshot shows where work waits today, not whether the same stage holds work up every week.
02
Later cycle-time observations cross the chart’s reference limits. Something in the system changed, and the chart shows when.
Investigate what changed around that date. The signal shows the shift, not its cause or whether it was an improvement.
03
Recent completions appear beside a blank forecast date. The tool withholds a date until the stability check is complete, so you find out the forecast is unsupported before anyone commits to it.
Complete the missing stability evaluation, then reconsider the commitment with a forecast the evidence supports.
Following a decision through
This illustrative draft proposes a daily review of blocked work. It records the observation, a proposed action, the expected result, a safeguard and a review date. The cause of the blockage is still an open question.
No trial has started and no result is claimed. When a change is tracked, its original prediction and subsequent reviews remain part of the record, including a result that does not support the expectation.
Observation → change → prediction → safeguard → review
Design choices
Saved observations preserve their dates and definitions, so a later review can establish what was known at the time.
Missing or incompatible evidence can prevent a forecast. A date is not substituted for an unresolved question.
Predictions and safeguards are recorded before evaluating the result. A later interpretation does not replace the original expectation.
The workspace is stored locally. Jira is optional; saved observations and follow-ups remain available offline. These captures use the application’s built-in simulated project.
The thinking behind the tool
Flow Observatory explores in software several questions developed in The Predictability Loop: how to trust a signal, investigate a constraint, test an intervention and make a defensible commitment. The book develops the reasoning and the leadership practice behind those questions.
The application is separate from the book’s companion toolkit of examples and methods.
Work in progress. Expected publication March 2027.
About the bookA delivery question
I work with your team to examine a delivery question using its workflow and delivery history. We identify what the evidence supports, agree a change worth testing and define how its effect will be reviewed.
Start with the delivery question and the workflow involved. Data access and responsibilities are agreed before analysis begins.
Explore a diagnostic for your organisationThe Delivery Intelligence workshop develops your team’s ability to interpret evidence and conduct delivery reviews. Facilitated labs use simulated examples. In development for a private pilot.
Explore Delivery IntelligenceRelated work and writing
Occasional emails from Roman about new writing, books, Flow Observatory and community events. Unsubscribe at any time.