Agility at scale is one of the crucial issues for large organizations, so we interviewed four experts in order to put together an ebook, allowing us to understand the contributions of agility at scale and SAFe. The following article is an extract from this ebook and allows us to understand what does scaled agile mean.
Ensuring synchronization through a single framework
You’ll need to very quickly consider migrating all of the workflows to a single tool.
The difficulty here will depend on the degree of discrepancy between teams, whether in terms of the tools used or, in particular, in terms of workflow sophistication and the detail of the data involved—as some
people will use data for different purposes such as the test automation repository.
It’s important that synchronization can be carried out within a single framework, with continuity between the modules used by teams and those used for coordination; along with syncing of the USs, consolidation of the
USs into Epics, as the customer journeys and dependencies between backlogs will require this.
The option of extracting an Excel file from an old tool so as to re-include it in a new tool after reformatting is relatively straightforward, with a dedicated role (an expert in the new tool) given responsibility for this, and with support (training or mentoring). However, teams are reluctant to waste time on the transfer (especially if data (re)entry is involved), adopt new standards, modify their workflow, unify their metrics, and sometimes lose information (such as their initial numbering system or their archives).
The need for psychological preparation by the coaches should not be
ignored and must be part of the support package.
The consolidation rules and the results expected for coordination purposes
must be established with the management team and the product manager, but must also involve the teams themselves, since it’s their working tool that’s at stake. All this will enable the PMOs to play a part again.
Unifying workflows and practices
This is the case with the program I’m supporting at the moment. We’ve overcome this issue by defining the “master” tool that contains all of those items—Business Epics, Enablers, Capabilities, Features, and User Stories—that describe and break down the requirements from the portfolio into Trains / teams, with hyperlinks in the User Stories to the element(s) of the teams that aren’t using the same tool (and that cannot migrate).
And I agree with Jean-Claude that, beyond the tool issue, the greatest difficulty lies in unifying the workflows and therefore, by implication, the practices followed by the different teams and people, even in terms of their understanding of agile.