The concept of a release train in software development is not new, although the folks behind SAFe would have you believe they coined the term. Essentially, the release train is a project management technique used for coordinating releases across multiple teams, each owning different components, that have runtime dependencies (think dependency hell). Organizations that rely on this approach often mandate that all releases happen on a fixed, reliable, and predictable schedule regardless of whether all expected features are ready. The train leaves the station regardless if you are ready. As an agile coach, I enthusiastically embrace the adage of “just ship it”. It’s imperative organizational cultures endorse discipline around the frequent releasing and demoing of working software. As my old boss, Jamie Thingelstad CTO at SPS Commerce, often says; teams that frequently ship code, win.
While I’ve built, worked with, and found some success with release trains, I do not recommend this as a common project management practice. The best use case I’ve experienced is when it’s used as a forcing function to get teams to speed up as part of a cultural transition. For example, super duper slow teams that rarely ship to prod, say once month or worse, would likely get some benefit. As I reflect on my learnings, I believe there is a metastatic danger when relying on a release train. The serious drawbacks with the release train approach as a standard practice will reinforce temporal coupling around sequencing of changes, and will degrade quality as teams push to complete features to a perceived perfection.
Instead, try focusing on the cultural, architectural, and organizational approaches necessary to foster frequent, independent releases without fear.
GitHub has a blog post that I love. >We don’t have a release manager and there are no set weekly deploys. Developers and designers are responsible for shipping new stuff themselves as soon as it’s ready.
