One of the techniques that you see in bigger organizations that struggle to move to an Agile mindset, is the introduction of Release trains:
A release train tries to align the vision, planning, and interdependencies of many teams by providing cross-team synchronization based on a common cadence. A release train focuses on fast, flexible flow at the level of a larger product.
It is especially used in SAFe(Scaled Agile Framework) organizations. Their definition of a release train is:
Agile Release Trains align teams to a shared business and technology mission. Each is a virtual organization (typically 50 – 125 people) that plans, commits, develops, and deploys together. ARTs are organized around the Enterprise’s significant Value Streams and exist solely to realize the promise of that value by building Solutions that deliver benefit to the end-user.
Based on the definitions above you would think that a release train is something you should aim for, an end goal you should achieve to become ‘Agile’. I don’t agree with that. Although release train can help you get in the right direction, they are a temporary workaround for an organization moving to continuous delivery. THAT is what you should aim for. Release trains are a remedial technique to get out of the mess that the release process in most organizations is today.
The biggest risk is that release trains bring you on the path of distributed monoliths. As you get used to the fact that all your services are deployed together, your architecture will start to depend on it. Now you have all the complexity of a distributed system, but also the downsides of a single unit of deployment as well.
Every part of your architecture should be independently deployable.
Intrigued? Read following article: https://rollout.io/blog/release-train-crashed/
I’ll leave you with one quote:
“If you have a release engineer/manager chances are you have a distributed monolith”