RAFT is a technique that lets your deliverables flow through multiple disciplines in parallel. Each team keeps its own board and process, and starts as soon as the work in front of it is settled enough to build on. Less of your schedule goes to waiting, and wrong directions surface while they’re still cheap to fix.
RAFT stands for Relative Autonomous Flow Technique, which is a long name for a short idea. One piece of work is represented once, every team contributing to it can see the same item, and each team can see where that item sits for the teams around them. Relative, because what matters is where your work sits compared to everyone else’s. Autonomous, because no team gives up control of how it runs.
It is a technique rather than a framework. It does not tell you how to organize, what roles to hire, what ceremonies to run, or what your board columns should be called. It sits on top of what you already do. If your studio runs Scrum, keep running Scrum. If it runs nothing in particular, that is fine too.
It is also not a tool. You don’t have to buy anything or migrate anything. RAFT connects work you are already tracking in the tool you are already using.
Take one character. Concept explores it, gets feedback, revises, reviews, and calls it done. Modeling takes the approved concept and builds a proxy, gets it in the game, revises to low poly and then high poly. Animation takes the model and works through proxy animations, alpha passes, and finals. Audio, VFX, and engineering all attach somewhere along that line.
Run that sequentially and every discipline can be fully occupied, every board can look healthy, and the character can still take four months to arrive. Nobody is idle. The time is not in the work. It is in the spaces around it, where something is finished for one person or one team and not yet picked up by the next. Your tools were never built to record those spaces. Most of it sits between disciplines, which is where it is largest and hardest to see. Some of it sits inside a single team, between a review and the revision that answers it. The part between disciplines is what I call seam time.
The expensive version of the same problem is direction. If the concept was wrong, sequential work means you find out when the animation is on it, which is the most expensive possible moment. The interval between committing to a direction and discovering it was wrong has a length, and on most projects nobody measures it. Shortening it is worth more than any efficiency gain inside a discipline.
It scales by repetition rather than by adding layers. One team working with several supporting disciplines uses the same technique as ten teams working against a shared milestone. There is no coordination tier to install and no restructuring to do.
Each team decides, once, the point on its own board at which the next discipline can safely begin. When a deliverable reaches that point, the downstream team can see it and start. No meeting produces that signal, and nobody has to carry it by hand.
That is the whole technique. No new ceremonies, no coordination layer, no restructuring. Learning it takes an afternoon. Getting a studio to actually work that way takes longer. Like any good game, RAFT is easy to learn and hard to master, which is the reason consulting exists.
Most studios now have agents and assistants producing work. Code, concept variants, test coverage, first passes at things that used to take a person a day. The generating side of production got faster. The reviewing side did not, because a human still has to look at the output and decide whether it is right, and that takes exactly as long as it always did.
That is the same shape as everything above this line. Work arrives at a discipline faster than that discipline can send it onward. Arrivals exceed departures, a queue forms, and because a queue between two teams is not logged anywhere, it forms quietly. The only thing that has changed is the rate. A seam that used to open by days now opens by hours.
RAFT does not care whether the thing producing the work is a person or a model. One deliverable, connected across everyone who touches it, and an explicit point at which the next team can begin. What changes is that the waiting is now worth watching continuously rather than at milestone reviews, because it accumulates faster than a milestone cycle can catch it.
Everything above assumes seam time is where your schedule is going. That is true in virtually all studios I have seen, but I would not ask you to believe it about yours on my say-so, and I would not ask a team to change how it works on an assumption either.
So, the first thing I do with a studio is measure it. The RAFT Flow Diagnostic reads the tracker history you already have and puts a number on the time your deliverables spend waiting, priced against your own burn rate, at every seam it finds. If the number is small, you do not need me, and you should not adopt anything. If it is not small. If you want help opening the worst two, that is the RAFT Flow Sprint.
RAFT is tool-agnostic. You do not need to buy anything or migrate anywhere. It works with the trackers studios already run.
This is written for studios of roughly thirty to three hundred people running concept, modeling, animation, audio, engineering, QA, etc. against a fixed ship date. That is the environment I came from, and it is the only one I take clients in.
The arithmetic underneath it is not specific to games. Anything that must cross several specialist teams before it is finished loses time in the same place for the same reason. But knowing that a technique generalizes is not the same as knowing an industry, so I am not going to claim the second one on the strength of the first.
A short course in multi-team flow-based delivery for teams whose work crosses more than one discipline. Opening soon.
No. A framework tells you how to organize. RAFT tells you nothing about your structure, your roles, or your process. It is a way of connecting one piece of work across the teams building it, and it overlays whatever you already run.
No, and I would not recommend changing two things at once. Disciplines keep their own cadence. RAFT is about what happens between them, which is the part Scrum and Kanban were never designed to address.
I am not going to give you a number I would then have to defend. What I can tell you is what changes first, which is that work starts appearing in the game earlier, and wrong directions surface while they are still cheap. Whether that shows up in your milestone dates depends on things I cannot see from here.
The diagnostic measures. RAFT is what you do about what it found. You can buy the measurement without adopting anything, and plenty of studios should start there, because it tells you whether there is a problem worth solving before you ask anyone to work differently.
