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:
Two very strong notions are both the symptoms of failure and the keys to success:
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!
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?
An interesting solution that some customers do not go far enough on is Agility at Scale.
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.
(crédit photo : blog.myagilepartner.fr)
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.
To conclude, Agility at Scale is a relevant and effective meeting point between the rigidity of the Waterfall method and the anarchy of non-embodied Agility method:
Visibility and a plan to follow: The work to be provided is planned in concert with all the teams participating in the realization of the same product, a project plan is shared, the critical path is identified and can be controlled (advantages of the Waterfall method),
Ability to test a hypothesis (business, technical) and to adapt: This plan is limited in time (for SAFe, it is an increment delivered every 3 months), which reduces the risk of investing in a product that does not meet its target audience, does not meet profitability expectations, does not rely on the right technological architectures, ... in short, it allows for the unexpected and, in the end, provides the opportunity to correct the situation or fail quickly (advantages of Agility),
Support for change through inclusion in a collective project: By involving teams in sharing the vision and target to be achieved, in collectively defining the plan, and by giving them the organizational autonomy to achieve this objective, the company enables individuals to understand, embody and disseminate the absolute necessity for adaptation and responsiveness to the economic challenges and expectations of our society.
Thank you to Maxime Toupet, author of this article.