A release train helps to coordinate several dependent projects. In a release train, all projects develop coordinated versions that go through phases such as beta testing, release, or updates together. The idea has proven itself in many large projects like Eclipse, Ubuntu, the Spring Framework, or LibreOffice.
The Scaled Agile Framework (SAFe) proposes an Agile Release Train to coordinate the work of several agile teams. They have a fixed time of delivery and provide a new system increment every two weeks with a system demo. The Agile Release Train coordinates the development of the software and the release of it. Afterwards users can use the new features. So the train is about coordinating the development of one or more major features across multiple teams. The goal is to ensure that not only the individual teams but also the entire system regularly rolls out new features. This should reveal potential problems with the larger features. Of course there are several roles for central coordination in an Agile Release Train.
Coordination is always necessary for collaboration, but it also creates an overhead. Central coordination is at odds with delegating as much responsibility as possible. Modern organizations should have as flat a hierarchy as possible and teams should work in a self-organized way instead of relying on central coordination and command & control. Without central control, the organization also scales better.
Architecture Instead of Coordination!
Excessive coordination is an organizational problem. But the cause can be an architectural problem: If changes that represent business value require the coordination of several teams and components, a better domain architecture can reduce the number of components involved and thus the number of teams involved. Domain-driven Design suggests some measures for this. If the coordination in an Agile Release Train is very complicated, it is definitely worth taking a look at the architecture to see if there is potential for optimization.
But even if the software architecture is perfect, a feature may still require changes that affect several teams. After all, the teams work together on one system, and features of that system can therefore always be distributed among several teams. Domain-driven Design suggests various patterns to coordinate the teams in that case. With the pattern “Customer/Supplier”, the customer team can request the implementation of features from the supplier team. The alternative is “Conformist”: In this case, the team must take what it gets and cannot request the implementation of features.
So a DDD team can implement a feature even if it needs support from other teams. Just the type of collaboration between the teams such as Customer/Supplier must be defined. Of course, it may be necessary to define an escalation procedure, but under normal circumstances, the teams can work without central coordination and coordinate with each other in a decentralized manner.
Partnership: Too Close a Relationship?
Collaborative feature development similar to an Agile Release Train is also a DDD pattern. DDD describes it as “Partnership”. A partnership appears to be a positive thing. The DDD reference (DE) uses a three-legged race to illustrate partnership, i.e. a race in which the participants are tied together on one leg. Such a partnership and the close coordination that comes with it are quite likely to lead to a problem, as is also to be expected with an Agile Release Train.
Conclusion
Close central coordination, as implemented by Agile Release Trains, should not be necessary in a good software architecture and can be circumvented by other means. Perhaps perceived safety and control is one reason why approaches like SAFe are successful. However, coordination makes it possible and necessary to monitor progress at the level of the overall project. This can provide a feel of greater safety. By contrast, truly delegating responsibilities to teams requires a high degree of trust.
tl;dr
Release Trains coordinate the cooperation of teams. Domain-driven design approaches, on the other hand, delegate more responsibility to the teams and therefore require less coordination
Many thanks to my colleagues Anja Kammer, Martin Kühl, Torsten Mandry, Sebastian Schwaiger, and Benjamin Wolf for their comments on an earlier version of the article.