We now know how many people or teams to consider moving to agile at scale. In the continuation of our Q&A series on agile at scale and SAFe, we interviewed four experts who share their opinions.
The interactions are essential because they create a dynamic
Yes and no. If the teams are truly independent in that 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 of the 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.
How to implement transformation?
Whether you are heading up this new business approach or at the very heart of operational teams, this e-book will help you better understand the challenges and benefits of agility at scale for everyone.
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.