The increasing number of teams brought significant challenges in maintaining effective team structures, coordinating and communicating across teams, achieving cross-team goals, managing dependencies, and planning releases. Throughout the transition, we tried to be as honest and transparent as possible, capturing and presenting the challenges along with successes. I will describe how each of those challenges were addressed in the sections below.

Effective Team Structure
This challenge was overcome by organising the teams in a way to have cross-functional, cross-component, feature teams of 5-8 people that could create a shippable product at the end of each iteration. The majority of the teams were customer-focused feature teams, and one team was dedicated to the infrastructure. We established one Definition of Done for the whole product, and it was common for all teams. Then we agreed that each team could have their own stronger Definition of Done by expanding the common one.

Planning Releases
We introduced a high-level planning of multiple Sprints, and we called the event “Release Train Planning”, borrowing the term from SAFe framework. It was a session for the teams to estimate their capacity for the following three iterations. Each team created their draft plans and described potential risks, and dependencies. Release Train Outcomes were a summary of the business and technical goals that the teams intended to achieve in the upcoming Release Train period. Each team summarised the information into simple business terms that can be understood by everyone.

Managing Dependencies
Teams coordinated and integrated their work with other teams so that at the end of the Release Train period they would together have produced one whole product increment. Inspired by the Scaled Daily Scrum from Scrum@Scale, we set up “Scrum of Scrums” meetings to synchronise with the feature teams. The teams were discussing any impediments they had that would prevent them from accomplishing their Sprint Goal or that would impact the delivery plan. They also brought to attention any new dependencies between the teams.

Coordinating and Communicating Across Teams
Each team started and ended the Release Train and Sprints at the same time. During each iteration, in addition to the Scrum of Scrums, we were also having an event that we called Agile Delivery Update to provide stakeholders and senior management with regular visibility into the release progress. It was also the place to approve any scope, timing, people or resource adjustments necessary to assure the release, and that feature toggles were removed after production verification.

Achieving Cross-team Goals
The Sprint Review was common for all teams. During that meeting the teams demonstrated the product increment to management and stakeholders. The functionalities were reviewed and their value considered. The meeting was informal and questions and discussions were allowed.

In the hope of helping you see how existing frameworks can inspire and help build custom ones, I shared here my experience with a start up growing from one delivery team to seven in two years. Throughout the transition, we hired one more Scrum Master and together we did a good job coaching at the team level and instilling Agile principles and values, getting seven high-performing, self-organising teams. While experimenting the effectiveness of Scrum in large scale application development, we made a few mistakes as well, but we have also improved quickly based on iterative feedback. Not only we had retrospectives at team level, but also an overall retrospective. Together we reflected on successes and failures, then inspected how to improve our process, moving forward step by step. We have learned that patience is important, as is remembering that even the smallest of incremental improvements can have a massive payoff when you do them at a large scale.