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 excerpt from this ebook and allows us to determine where an organization should start to initiate a scaled agile approach.
The emphasis is on experience sharing and weekly synchronization
Shares his experience as an Agile Coach within the IT department of France’s Caisse des Dépôts (public sector financial institution), on the implementation of the “Banque des Territoires” platform.
When launching a new structure that was designed to establish a single banking platform irrespective of the type of customer and proposed product involved, the scoping phase and the definition of the MVP were facilitated by a team of three in-house agile coaches, with the assistance of two external coaches:
The Product Manager, the future director of this regional investment bank, was trained and coached at the same time as the teams.
A product vision was defined: originally, a slide taken from a board meeting launching the new platform (the seven promises of the platform), shared, and outlined with all teams (some created for the new platform and other pre-existing ones, comprising 80 people in total).
The backlog was defined from a blank sheet, in conjunction with “team”- based Product Owners (with the teams initially organized into Component Teams), and prioritized (by identifying the MVP right at the outset by asking: “In four months, what do you want to present to your customers?”
On this basis, we were able to establish a dynamic weekly PO meeting, under the responsibility of the Product Manager, and gradually consolidate the new backlogs and the existing backlogs.
The self-designation of Scrum Masters in the teams, complemented by new hires, enabled a community to be instituted, which very early on set up a weekly session for sharing experiences and syncing. They were the points of contact for implementing tools for managing the backlog and for agile project management.
Cross-functional roles were taken up by committed individuals, whose responsibilities included event logistics.
We focus on the customer’s needs
Shares his experience at SoCraAgile as an Enterprise Coach for the Haute Horlogerie watchmaking foundation in Switzerland.
Just like always when supporting organizational transformation, we first took the time to fully understand the customer’s requirements. This point should not be ignored, as we’ve often met leaders who want to scale up a framework, more for tool-related reasons than because they have a real need. We take a pragmatic approach and believe that frameworks can always be adjusted to the needs of the organization as long as it’s in line with the agile manifesto.
In this case, our client had contacted us to help them implement SAFe 5 in their organization. After understanding their real need, we realized that, in reality, they were only attracted to SAFe in the sense of it being “flavor of the month” in that, if it’s been successfully implemented by another company, it surely must be the best framework! We finally proposed that Scrum@Scale be adopted (also known as Scrum of Scrums), allowing them to scale up as needed without adding further complexity to an already highly complex system.
The first step involved creating product-based teams that are independent of one another. This is important as we’re introducing a radical paradigm shift. The organization is no longer driven by “projects” but by “products” that are monitored over the long term. A Product Owner will be in charge of a product (a set of applications grouped under a common product); he or she will manage the strategic requirements, development needs, technical maintenance, and any incidents.
We’ll then start by setting up agile teams and increase their level of experience. This is also important for the future of the project. Teams that don’t behave as Scrum teams will have difficulty scaling up later. If the “easy” part of the system cannot be adapted, then what’s the point of trying to scale up?
The first scaling tool in place will be the “Scrum of Scrums” (a kind of daily Scrum) and the “Scaled Retrospective.” With the aid of these two events, we are bringing greater transparency and continuous improvement between teams.
The rest will come in small steps, depending on the maturity of the teams and the system overall.
We promote team synchronization and cohesion
Shares her experience as an Agile Coach on a complex program involving aroung 250 in the field of energy.
I’ll talk about this particular situation, where the business has been trying to deploy SAFe at the Solution level (or its own misinterpretation of this), without support and without success. It should be noted that this program is very complex, in terms of both the number of components, interfaces, technologies, and different organizations involved and the geographical distribution of the teams.
The first step involved undoign the implementation that wasn’t working, simply by explaining to the people concerned that what they were doing (PI Planning for 15 people who plan specification activities and then monitor whereabouts they are each week in respect of those specifications -in other words, the Solution aspect from their point of view) was neither agile nor SAFe.
We then tackled the most obvious aspect for me at that time: the fact that multiple component teams needed to work together to dleiver a solution. However, one-to-one interviews quickly helped me understand that not only were the teams not working side by side and didn’t know one another, but also that each team was pursuing its own particular objective (to deliver its component) rather than a collective one (to deliver the solution).
We therefore set up weekly synchronizations involving representatives of those teams; this soon resulted in some interesting initial discussions aimed at trying to deliver and integrate the components on an as-and-when basis -since the teams mainly worked in Scrum but with different iteration durations. The first collaborative demos took place.
We then arrived at a consensus, following several weeks of negociation whereby the teams would apply the same cadence (iterations of three weeks).
Next, we organized a first “actual” PI Planninng session, which took place in January 2019 with 80 people but few team members, as we hadn’t been able to convince them of the benefits and importance of their presence. Despite many people’s doubts, the PI Planning went well (at least for a first session), not least because it resulted in some important issues being highlighted regarding a central team. Synchronization sessions focusing on visual management, retrospectives, and shared product demos have now become standard practice.
As a result of some decisions (or non-decisions) by management and the subsequent lockdown, a period of drift set in, in which little changed.
Anyway, over the past two months, this particular transformation has sped up and broadened with a new energy, thanks to a push from senior management, a common and shared vision, the creation and alignment of a transformation team, a leader-type manager who plays a part in that team, and some recent reinforcements in terms of coaching.
We’ve just launched—or rather, have formalized the existence of—three Agile Release Trains (at least four or five others will be launched next year, all already scheduled at the same iteration and Program Increment cadence) delivering three solutions (obviously, not on a one-to-one basis as thereare dependencies). This means organizing three actual PI Planning sessions (with the developers present!), one pre-Program Increment and one post- Program Increment, and formalizing, training, and supporting the key Train-related roles (the Release Train Engineer / Product Owner / SAFe Agilist trios) and solution-related roles (Solution Train Engineer / Scrum Master / SAFe Agilist), while supporting the teams where there are any gaps.
At the same time, a lot of work will be done for the end of this year to establish the portfolio: with a shared multilevel backlog, prioritization, rituals, tools, etc., as there’s a real shortfall at this level that’s impacting the teams.
We’re also expecting other projects next year: working on incremental deliveries, involving the customer to a much greater degree, setting up communities of practice, harmonizing and improving tooling, and so on.