During the digital transformation of historic companies, known as brick-and-mortar (Banks, Retail, Telecommunication, ...), a large majority of companies encounter a problem that can be summed up in one sentence:

Companies are using agility in projects instead of being agile at Scale

Two very strong notions are both the symptoms of failure and the keys to success:

• Lack of embodiment of agile transformation:

Companies that have an agile approach have retained their historic corporate culture, with a vertical division of functions, working methods, responsibilities: everyone is the master over his own kingdom. This is what you might call  "change in continuity". Each person manages his or her own budget according to the priorities of its own perimeter. The ambition to "open up the silos" is not embodied and the thought of the final product is not present.

It is important to be aware of the number of UX working within companies. The user experience is not yet perceived and integrated as a creator of value/value-creation, whereas that is exactly what today's and tomorrow's consumers are looking for: to live an experience. As a result, these companies are losing the benefits of the hastily abandoned Waterfall method, responsible for all the evils, in favor of the acclaimed "agile methods", which alone seems to solve all the problems for some people!

• Lack of/Absence of dependency/adhesion management between teams :

There is no product, which we use on a daily basis, which could be realized by one and the same team of 10 people and delivered in a time consistent with market expectations. Don't look for an example, it's impossible!

Every IT product and project puts into action a myriad of different functions and teams within our clients' organizations: End users, Business lines, Project portfolio and investment management, IT planners, Technical architects, Functional architects, Developers, Operators, ... potentially cross-functional functions, potentially present in each major functional area of the company. Creating multidisciplinary teams, from Dev to Ops, is of no use if the dependencies between these teams are not managed and monitored. And project agility (Scrum, Kanban) does not allow it. How can we move forward towards the realization of a final product without knowing whether the teams on whom we rely or who rely on our achievements are aware of our progress and in the capacity to integrate and maintain them?

What can be done about it?

Whether it is orchestrated through the implementation of SAFe®, Spotify®, LeSS® or Scrum of Scrum frameworks, it seems to be the right response to the need for cross-functional management of a digital transformation. In this systemic state of mind, the focus is no longer on the work carried out within a team, but on identifying and steering inter-team dependencies with a common goal: the final product. We therefore take a step back to increase the field of vision.

Agility at scale is therefore the return to favor of management by the critical path and therefore by risks.We only follow what is on this critical path, where any deviation completely brings down the collectively imagined plan and jeopardizes the realization of the final product. Each contributing team is then autonomous in the way it meets its commitments, depending on its skills and constraints.

In a model of agility at scale, you will therefore find teams in Scrum, teams in Kanban, teams with their home-made work method... An autonomy which also brings better acceptability of change and better adaptability to this change.

If I had to summarize agility at scale in one image, I would definitely choose this illustration of the result of a SAFe® Program Increment Planning: the Program Board is perfectly representative of the value and power of this dependency management.

Program Board explanation :

With regard to the collective objective (the final product), each contributing team (online) details the content of its achievements by Sprint (in column). By sharing and having stakeholders available in the same place at the same time during the Program Increment planning, each team identifies in red the contributions that will be useful to the other teams. A red string is then pulled between these teams (the one that produces, the one that uses): our critical path is identified according to the major milestones of the project/functionality of the final product. 

All that remains is to manage the risks on these red strings, through a frequent review of this Board. The organization therefore becomes able to manage the work of 200 people thanks to a weekly meeting of 1 hour! Doesn't it make you dream? This dream exists and many large companies have taken the plunge, including more than 70 in France.

 Thank you to Maxime Toupet, author of this article.