Release Train

With one team, the release date is not a problem. You ship when it's done. With eight teams it becomes one. Eight teams work at their own pace while the output has to merge into a single product, so when one of them isn't ready, the other seven wait.

Pagedeck reached that state after growing to six teams. A release set for the end of February gets a request for two more weeks from one team, and the whole thing moves to mid-March. By mid-March the same request arrives from a different team. After Mia moved the date a third time, nobody was using it to plan against. Ravi could not book advertising, and Sofia could not tell enterprise customers when anything would land.

Other costs piled up during the waiting. Five finished features sat still because one unfinished feature held the release. Something built but not delivered produces no value at all yet, and it keeps costing: the branch it sits on drifts further from the main line every week it waits. A release train inverts both problems at once: instead of fitting the date to the features, it fits the features to the date, and whatever misses the cutoff takes the next train.

Fix the dates first and then stop touching them. That is where the method begins. Five steps.

1. Nail down the interval and the dates. Pick every two weeks or every four, and publish the departure dates for the whole quarter up front. Teams can only work backwards from a date if the date is already on the calendar. A team that knows the next departure is four weeks out will size its work to fit inside four weeks.
2. Write down what it takes to board. The standard is the definition of done (DoD), the shared bar for calling work finished, plus one integration deadline on top: changes not merged by three days before departure do not board. Without that written down, the night before every departure becomes a negotiation.
3. Push what isn't ready onto the next train. Not moving the date is the entire rule. The tool that makes this workable is the feature flag, a switch that turns code on and off, so an unfinished feature can ride the train with its switch left off. Merging keeps happening on the normal cadence, and the decision about whether customers see the feature moves out of the release and into a separate, reversible step.
4. Line up what teams owe each other in advance. If the payments team needs a result from the authentication team and learns that one week before departure, this train is already missed. A forum where team representatives meet, such as scrum of scrums, is where those handoffs get written down as dates.
5. Look at the record after each departure. Count whether it left on time, how many items slid to the next train, and why. When the slipping items keep coming from the same team, it is that team's work size or dependency structure that needs attention.

It fits best with four to ten teams whose output merges into one thing. It is also valuable when dates are constrained from outside. Mobile apps wait days for review, enterprise customers need advance notice of changes, and products installed on a customer's own servers need someone's calendar. Every one of those constraints is resolved by starting from a date.

Two situations where it does not fit.

1. One team does not need it. There is nobody to coordinate with, so it is not a train, it is just a deploy.
2. If each team already ships independently several times a day, a train slows things down. Services that are not coupled have no reason to be loaded onto the same departure.

Three limits.

1. The interval is the maximum wait. On a four-week cadence, a feature finished the day after departure waits four weeks. Without a separate path for urgent work, that delay passes straight to customers.
2. Someone has to say no. On-time departure only holds if the boarding conditions hold, and if nobody has the authority to refuse a request made the night before, the conditions collapse in the first month.
3. The batch going out at once gets large. When three weeks of changes from six teams ship together and something breaks, there are dozens of candidate causes. That is why teams running a train also use per-feature switches and staged rollouts: turning one switch back off is a far cheaper answer than rolling back three weeks of work from six teams.

Scaling frameworks that add layers, like SAFe, carry this way of operating inside their rulebook, and organizations using no framework at all sometimes adopt just this piece.

"This train departs March 12 and code freeze is the 9th. Anything not merged by then goes on the next one."

Stating the date and the boarding condition together removes the room to negotiate.

"That feature missed this train. The code rides along with the switch turned off."

Merging continues while customers see nothing.

"To board the March train we need the authentication result by February 26."

Converting a dependency between teams into a date.

Pagedeck runs one train on a four-week cadence and publishes three dates at the start of each quarter. Mia wrote the boarding conditions down and also took on the job of refusing last-minute requests. Refusals happened at every departure for the first two months and had nearly stopped by the third, because teams had started sizing work against the date instead of asking for the date to move.

Theo now starts large features with a switch already attached. Ravi, with departure dates fixed, books advertising a quarter ahead.

The most common mistake is reading the train as a device that slows releases down. Watching a finished feature wait for a date makes it look that way. But what this method targets is predictability, not frequency. When the date stops moving, people outside the team can plan against it. If slowness is genuinely the problem, the answer is shortening the interval from four weeks to two, not removing the train. Left in place, the belief sends teams back to moving dates, which is where they started.

The second is assuming on-time departure lowers quality — that hitting a date means pushing half-finished work out. The rule says the opposite. Anything that misses the bar does not board, so what flexes against the fixed date is scope. That said, once teams start forcing work aboard in violation of the boarding conditions, the belief becomes accurate. What broke in that case is not the train but the willingness to hold the conditions.