No Process Changes During a Release Train

Engineers are creative folk. It's tempting to see a problem in front and not find and implement the solution right away. But when it comes to changing an aspect of the release trains, don't change the process while a Release Train is going.

Release Engineers should be substitutable—an engineer working on the train may take vacation or a sick leave. So it's important to always keep the next person taking the helm in mind. Improvising on the processes as the trains are in progress makes it hard for the process to seep through the personnel in the team.

More importantly, Release Engineering a complex product means that you have to control the number of modifiable variables. Release Trains introduce changes to the product and if a testing script is also modified as the product is flowing through the pipelines, it becomes hard to identify where the problem lies leading to cognitive burden.

So each release train upon departure must conceptually freeze the platform it will run on and no changes should be allowed while it's running.

You should note the problems in the release train system. Make note of what part of it is inefficient in the journal or logbook, allowing you to pitch the problem in your Release Train postmortem. Another approach could be to hack on a branch but not push anything to the production platform until it's reviewed and tested.

This also includes the meta layer of the process, so consider sticking to the tools the team already uses. If the team doesn't typically use spreadsheets, don't do so. And if spreadsheets are the answer to manage the workflow better, propose and demo a use case and experiment in the upcoming train. Spontaneity in the process that releases a critical product out to customers is a red flag and increases the difficulty in jumping on to help out for your fellow teammates.