[obflink-image link=”https://content.tuleap.org/ebook-scaled-agile-how-to-implement-transformation” id=”229039″ alt”ALT” class=”my-image” target=”_blank” size=”large”]
More than a single work team
We talk about a product being at scale as soon as more than one team is working on the same product. But that doesn’t mean we have to immediately embark on a framework like SAFe that’s recommended for 50 or more people. Two teams are two entities that coordinate their work with the help of a Scrum of Scrums, for instance.
When the number of employees approaches 10
It’s important to monitor the headcount within agile teams, since as soon as a team has close to ten people, it’s easier to have two small teams working than one large one; even then this can be described as a scaled agile approach. However, as soon as a product in development is integrated into a wider environment, it’s important to identify all the stakeholders and all the IT systems involved, so as to set up, as quickly as possible, the structure that will enable work to be synchronized most effectively.
When a team needs to synchronize and pace itself with other teams or businesses
As soon as I join my co-authors, with two or more teams, we’re at scale. Even a single Scrum team developing an application and working with other teams such as hardware, marketing, mechanics, physical products—for example, a mobile app for remotely controlling the radiators in your home—will, in my view, already be taking a scaled agile approach. In this example, I’m talking about scale in a “horizontal” sense, as I described in response to the first question.
You could say that you’re working at scale from the moment when a team needs to synchronize and schedule their activities with those of other teams or functions.
