Release trains are a good first step, not the last one.

In software development, the release train concept tries to bring about some cadence in releasing software. Once it is agreed that the software will be released "every X weeks", product development teams focus on ensuring that a release happens at every X week interval. For most teams it could be anywhere between 2 weeks to 6 months. However the main idea being that while the interval and schedule is fixed, the scope or content of the release is variable.

This concept is a boon to enterprises who struggle to release software for years, especially those who are running teams that are in a dependency hell. Aligning every team towards a shorter release cycle with negotiable scope and actually releasing more often is a great first step.

The problem occurs when the concept starts breaking down into a bureaucratic process of release management instead of focusing on the core engineering problems behind releasing frequently.

Here is what happens in large enterprises

• Organisations start creating new release committees (with roles like release managers, deployment coordinators etc...) to manage releases every X weeks across teams that deliver a common software platform.  Since the release committee works across teams without enough bandwidth to understand details, delivery teams are requested to create a whole bunch of documentation to aid the committee's decision making, mainly around a Go/No Go decision for every release.
• Conservative strategies such as early branching, code freeze, etc... are applied to meet the release timeline of the train. QA teams start demanding more time for testing as they are constantly worried about every release.
• Teams start planning more conservatively during their release planning exercises. No one wants to pack in more scope and be caught as a dependent team holding up a release. 

The core issue in larger organisations is that even with release trains, it ends up being a process problem that needs to be managed rather than an engineering problem. As an example, even with release trains, a lot of teams incur a bigger overhead in managing dependencies instead of investing the same time in decoupling systems to release independently.

Organisations embracing release trains as a first step lose their way towards continuous delivery. They get caught in the false sense of satisfaction that a release train gives them and hate to see the amount of overhead still incurred with every release. 

The real goal should be to engineer software in such a way that you can reliably release it on demand, whether it is daily or even hourly. So, please do take the next steps.