It slips in the seams. A finished asset sits eleven days waiting for engineering to pick it up. A build waits three sprints for a decision from someone who is in another building. None of that generates a record, because your tracker logs work and a wait leaves nothing to log. It costs real money and appears in no report. So when the number has to come down, the visible lever gets pulled, and the invisible cost is still there next project.
Read-only access to your tracker (Jira, Favro, or similar). One point person. About two hours of lead time across the two weeks. No engineering time, no new tooling, no process change.
You leave with the number, the three costliest seams and a 90-day plan written for your team to run without me. That is a complete engagement on its own.
If the readout names a seam your team cannot close while it is also shipping, that is what the RAFT Flow Sprint is for: four to six weeks on the worst two, scoped at the readout against the number we are both looking at.
I have trained more than a thousand practitioners in parallel flow at game studios and enterprise software companies. RAFT came out of that work. I watched a thousand teams default to sequential handoffs, and named what the good ones were doing instead: working the same deliverable at the same time.
No. The diagnostic reads what is already in your tools and reports what is true. If you never use RAFT, the number is still the number.
Some of it, yes, and I am not going to pretend otherwise. Your changelog holds every status transition, and there are marketplace apps that will compute time in status and even flow efficiency for a board. Two things are almost always true anyway. First, nobody has configured it, because ruling on which statuses count as waiting crosses every discipline boundary, and inside a studio whoever makes those rulings either lacks the authority to rule across teams or has a stake in the answer. Second, and more important, those reports are per board. They tell you how efficiently art is running. They do not tell you how long a finished asset sat before engineering picked it up. Crunch does not form inside a discipline. It forms in the seam between two of them, and that is the number this engagement produces.
No, and the difference is the whole reason this exists. A studio can have five disciplines each running at healthy flow efficiency and still ship late, because the handoffs between them are where the calendar goes. Measuring each team separately can make a studio look fine right up until the milestone slips.
Software does the measurement. The analysis and the readout are mine. I am not going to hand you a model’s opinion about your studio.
No. Everything runs from a read-only export and a video call, including the classification session and the readout. If you want the readout delivered in person, I will fly to you.
Read-only access to your tracker. Nothing else. No build access, no repo access, no telemetry, and no changes to how your teams work.
Studios of 30 to 300 running multiple disciplines against a fixed ship date. Most useful when someone senior already suspects the schedule is leaking and cannot prove where.
Usually it’s the opposite. While cuts are still happening, I’d wait. Findings get read as ammunition, and nothing gets fixed. But six to twelve months out is often the best moment to do this: the seams a reorg opened up are still visible, the team can feel them daily, and leadership has the mandate to close them. If you’re not sure where you sit, the 30-minute call is the cheapest way to find out.
