Agility at scale is one of the crucial issues for large organizations. We interviewed four experts in order to put together an ebook, allowing to understand the contributions of agility at scale and SAFe. The following article is an extract of this ebook and allows us to understand if we can do agility at scale with teams working on their own project.
The interactions are essential because they create a dynamic
Yes and no. If the teams are truly independent in what they’re working on different products, the development and delivery cycles can carry on separately from one another. It will therefore not be necessary to set up synchronization meetings.
Nevertheless, we shouldn’t forget that an agile approach also involves integration between people. We can therefore encourage exchanges between project teams and set up communities of practice in which different developers and product owners can share ideas, as can be done in the Spotify culture, with its “chapters” or communities focused on specific topics with “guilds.” This sharing of ideas is essential as it creates a dynamic within the enterprise, helping all teams to progress.
With some of our clients, we also see that team members are encouraged to move from one project to another. This ensures that individuals have a richer and more diversified experience, as they collaborate with more people.
Each project is an increment of a product
Among other things, in the agile world, we consider a project to be the start or an increment of a product. Even before embarking on a scaled agile approach, we recommend that our clients move on to having stable teams on a product or solution, in which those teams are initially given Epics (the business need to be delivered in the project) that will be broken down into smaller needs.
Teams must feel committed to the same strategic vision
For me, no—scaling up implies that all teams feel committed to the same strategic vision. And the concept of the project takes a back seat to that of the product, or even customers.
The contribution of each will form part of the features, the customer journeys (depending on the framework adopted), either within specialist teams for particular components (such as back-office, data, and customer interface) or, for more well-established setups, cross-functional teams organized around the customer journeys involved (feature teams).
As part of a development program, we can still speak of a project, in financial and management terms, for integration into the enterprise’s overall vision, especially if it’s not yet ready for an agile organization at the overall corporate level.
It will be agility on a “horizontal” scale
Yes, scaled agile in a “horizontal” sense if we assume that a project equals a product.
That said, I also agree with Enalean’s point of view: some rituals don’t make sense if each team is working on a different product that has no interaction with the one next door. Nevertheless, it can be interesting to consider a scaled agile approach in these cases at the department or enterprise level, bringing it to all business areas (agile for HR, sales, marketing, etc.), but also cross-functionally to teams so as to promote continuous improvement on a collective basis, constructive exchanges, learning through communities of practice, internal events, hackathons, “live my life”-type internships (working for a few days in another team, another business area), and so on. A long time ago, an organization I was working for succeeded in accepting the following challenge: to move all its servers in just one month from two data centers that had just been sold and were no longer available. Working in multiple separate teams, the 70 people in this enterprise built a backlog, held a stand-up involving 70 people every morning for one month and everyone was able to contribute to achieving the goal. Although it had looked like an impossible task to achieve in such a short time, they succeeded. That’s the most inspiring story of a scaled agile approach that I know, and back then the term didn’t even exist.