The Scaled Agile Framework (SAFe) is based on the Agile Release Train and uses the metaphor of a train, better a suburban train with regular intervals. Whenever the departure time of the next S-Bahn comes, it leaves - whether I got in or not. I'll just have to take the next S-Bahn. Originally this metaphor was used for a delivery cycle, now it is a planning cycle - ideally it is delivered continuously, i.e. as often as possible.
Applied to a larger software project, this means that each team must pursue two plans:
- Integrate its functionality as early as possible, i.e. take the next S-Bahn - plan A.
- In the event that the functionality is not ready, it must under no circumstances prevent punctual departure, i.e. that it must provide the necessary infrastructure and enter any API changes in order not to break the existing functionality - plan B.
This means that an extension of agile practices and special measures are necessary because:
- The communication effort increases with the number of people involved
- For human-to-human communication there is a proven size of a team of less than 10 people
- A division into several teams raises completely new questions of coordination between teams
By dividing the team into several teams, you can reduce the human-to-human part of the communication problems, you have a closer coupling in the teams and a loose coupling between the teams.
This ignores another, implicit coupling that has just as many effects: the common product in software is the common code base. With a bad, tightly coupled code base, you can't integrate continuously or even deliver it often: every change carries the risk that you break functionality for one of the other teams and you constantly "step out of each other's foothold".
SAFe has a clear procedure for this:
- Timing of planning, e.g. every 10 weeks
- An all-hands planning meeting at the beginning of each planning cycle and coordination of the development goals of the individual teams for the planning cycle
- Afterwards the teams work in a synchronized sprint cycle of e.g. 2 weeks and integrate the results continuously.
- No new functionality is developed in the last sprint of a release, it is used for planning preparation and innovation.
However, SAFe only defines a valid solution for the first step. In order to find a more optimal solution, further ideas and measures are needed to ensure that you are always available for delivery. Leading organizations manage to deliver several deployments daily, in some cases in parallel in different variants, to make them visible to some users. This makes it possible to dramatically shorten time-to-market and reduce risks.