Document presenté lors de la conf Agile en Seine

1. Facteurs faisant
échouer une transfo
@scale
Les anti-patterns concrets
20 au 22 septembre
2021

2. Remerciements sponsors
20 au 22 septembre
2021

3. • Mentor, Coach Agile, Scrum Master ou RTE
• Auditeur Technique / Process
• Directeur de projet
• Professeur en Ecole d’Ingénieur
• Responsable de l’Ingénierie technique
• Développement, Architecture logicielle, Team Lead
Pierre MEDINA
pmedinaj@gmail.com
linkedin.com/in/pierremedina
@pmedina
scaledagilesensei.com
meetup.com/fr-FR/Meetup-RTE-
SPC-et-SPCT-a-Paris
29/09/202 3
Qui suis-je?
Coach Orga/Agile - SPC - RTE
20 ans d’Expérience:
• Développeur +10ans (Java, JEE, Android,…)
• Architecte +10ans
• Chef de Projet de projet +15ans
• Directeur de Projet +10 ans
• SM master certifié en 2006 – 15 ans (de recul sur le déploiement de l’agilité)
• Coach agile 10 ans
• Prof d’informatique pour les élèves-ingé d’une grande écolé d’ingénieur
J’anime un Meetup consacré à SAFe depuis 2017 (fermé et consacré à des
experts SPC et RTE pour le partage)
Passionné par l’ingénierie logicielle, les grands projets faisant collaborer un
grand nombre d’humains et le leadership.

4. La nécessité du changement
d’avoir le client au centre
29/09/202 4

5. Au commencement était le Cycle en V / Waterfall
Exigences
Expression du besoin du Client
Conception
Mise à disposition du client
Exploitation et Maintenance
Analyze
Implementation
Verifications
Tests
Durée: 3, 6, 12 ou 18 mois (Effet tunnel)
 Les responsables du Produit ou les clients
sont victime de « l’effet tunnel »
 Les tensions apparaissent devant des
imprévus.
 => Le changement n’est pas le bienvenu alors
que la durée du cycle le rend nécessaire.
 Etc…
5

6. Héraclite d’Ephèse (Philosophe grec VIe siècle avant Jésus-Christ).
« Rien n’est permanent sauf le changement. »
29/09/2021 6

7. Winston Churchill (Homme politique Britannique du Xxe siecle)
« Mieux vaut prendre le changement par la main avant qu’il ne nous prenne
par la gorge. »
29/09/2021 7

8. Cycle agile : Le changement et le client au Centre
Pre-Game Staging Sprint Development Sprints Wrapper Sprints
8
29/09/202

9. Cycle en V vs Agilité
Les acteurs s’adaptent en permanence aux changement
Valeur
Business
Visibilité
Risques
Adaptabilité
En étant Agile la VALEUR arrive en continue L’effet Tunnel est fortement diminué ou presque inexistant
Les risques sont financiers et de développer
le mauvais produit sont fortement maitrisés.
9
29/09/202

10. Au delà de 5 équipes collaborant ensembles, l’agilité marche de moins en moins….
… Besoin de nouveaux outils.
L’Agilité fonctionne mal à grande echelle
10
29/09/202
Désordre « Agile »

11. Le challenge de la transformation
11
29/09/202
Waterfall Scrum
Transformation agile
Effectifs impactés: Une dizaine de personnes
Durée: quelques semaines à 3 mois
Coût: quelques dizaines de milliers d’euro
Transformation agile@scale
Effectifs impactés: Potentiellement
plusieurs centaines de personnes
Durée: 9mois, 1an, 1,5 an
Coût: de 1 à 1,5M€ (100 à 150personnes)
Coach Agile
ou Scrum Master
Coach Orga
ou SPC

12. Exemples de Framework agile@scale
Large Scale Scrum
DAD (Disciplined Agile Delivery)
Nexus
Scaling Agile at Spotify
SAFe (Scaled Agile Framework)
12
29/09/202

13. Tendances actuelles
13
29/09/202

14. Dalaï LAMA (Autorité Spirituelle et Religieuse Tibétain contemporain)
« Ouvrez vos bras au changement, mais ne laissez pas s’envoler vos valeurs. »
29/09/202 14

15. Zoom sur le Framework qui s’impose sur le
marché: SAFe 5.0
• SAFe est un Framework d’agilité à l’échelle.
• Il contient un ensemble de pratiques (Scrum,
Lean, XP, DevSecOps etc…), rôles et rituels.
• On le déploie au delà de 5 équipes/50
personnes qui doivent travailler étroitement
ensembles.
Exemple de rituels:
• PI Planning
• Scrum de Scrums
• Iteration Planning
• Daily Standup
• Etc…
Exemple de rôles:
• Scrum Master
• Product Owner
• System Architect
• RTE
• Product Manager,
• etc…
Le Framework bien déployé permet:
• Aligner les équipes sur une vision
• Planifier ensembles
• Exécuter ensembles en cadence
• Synchroniser ensembles à
intervalles régulier
• S ’améliorer ensembles
• Synchroniser la stratégie de
l’entreprise avec l’opérationnel
• Etc…
15
29/09/202

16. Les causes d’échecs dans les
transfos
29/09/202

17. Caractéristiques d’une bonne transformation
agile @scale
Pour qu’une transformation se déroule bien, il faut:
1. Un objectif clair: Pourquoi on lance la transformation et les bénéfices
attendues?
2. Un plan de communication claire vis-à-vis de toute l’entreprise
3. Une écoute de tous les « pain points » exprimés par les collaborateurs
4. Une démarche (roadmap) arbitrée, claire et partagée avec les différents
acteurs
5. Un plan de formation et d’accompagnement
6. Un Sponsorship au plus haut niveau de la hiérarchie
7. Accepter de passer en mode « budget capacitaire »
8. Et le déploiement d’un dispositif d’accompagnement à la transformation
correctement dimensionné.

18. Les raisons qui font échouer les
transformations
1. La culture de l’entreprise rentre en conflit avec les valeurs agiles
2. Les collaborateurs ne sont pas ouverts à changer leur manière de
travailler
3. Le Top-Management n’est pas suffisamment impliqué et n’apporte pas le
support nécessaire
4. La changement est trop radical
5. Le client interne ne se sent pas concerné et ne s’implique pas
6. Le management refuse d’investir sur les formations
7. Chaque équipe cherche à garder son indépendance
8. L’amélioration continue et l’atteinte des objectifs ne sont mesurés
9. Les business voient l’agilité et la responsabilisation des équipes comme
une perte de pouvoir.

19. Cartographie des causes d’échec

20. 1er cas d’usage: manque d’engagement
et de conviction du management
Description de la situation
• Culture forte de « command and control »
• Suite à une croissance business importante, la machine informatique ne suit plus.
• Le management décrète qu’il faut s’agiliser et Scaler
• Le management souhaite transformer et passer à l’agile
Avant le lancement de la transformation
• Des injonctions contradictoires sont
données au Coach Programme/SPC:
- Il faut transformer vite
- Mais les équipes sont très occupées, il
faut les solliciter le moins possible
- en ayant aucun impact sur la production
• Le SPC n’est pas directement sous le DSI
mais sous un manager qui doit être
impacté par la transformation
• Aucune communication n’est faite.
Pendant
• Le SPC lance son analyse et ne peut rencontrer tous les
acteurs pour des raisons « politiques »
• Le manager veut avoir un contrôle fin sur la démarche
et se positionne lui-même comme un expert de la
transformation cherchant à orienter
• Il n’y a pas le temps de bien former les collaborateurs, il
faut leur présenter « rapidement » l’agilité et les
accompagner
• La culture de l’entreprise fait que tout doit être
budgété (en capacitaire bien sûr ) et planifié.
• Le management considère que le rôle de Scrum Master
n’est pas critique, on décide que ce sera un rôle
tournant (sans formation préalable)
Fin de la transformation et passage en
vitesse de croisière
• Le coach sort
• Les managers continuent à demander
du reporting au jour le jour.
• Les équipes ne s’engagent pas
• Les Product Owner se comportent
comme des chefs de projets.
• On ne comprend pas qui porte
l’engagement et qui est responsable de
quel sujet.
Conclusion:
Une transformation a un coût important en temps et en argent. Par exemple, si on ne forme pas correctement les collaborateurs, chacun aura sa
compréhension de ce qui se passe et au final la situation sera plus nébuleuse. On aura économisé quelques milliers d’euros, mais la confusion
généré coutera plus cher.
Le management doit être investi et mobiliser tous les moyens nécessaire.

21. 2e cas d’usage: peur du changement
Description de la situation
• Malgré un plan de transformation clair, financé, sponsorisé et une communication adaptée, A ou plusieurs collaborateurs sont
réfractaires par peur du changement, de perte de pouvoir, etc…
Avant le lancement de la transformation
• L’objectif de la transformation est claire
• Les moyens sont mis sur la table
• Les collaborateurs sont bien formés
• Certains collaborateurs insistent sur la
non pertinence ou non-adaptation de
l’agilité dans leur contexte.
Pendant
• La transformation se déroule bien avec
des hauts et des bas.
• A chaque crise, le ou les réfractaires
influents s’empressent de se remettre au
premier plan pour pointer ce qui ne
marche pas.
• L’action des réfractaires détourne les
équipes du chemin de l’amélioration
continue: dés que quelque chose ne
fonctionne plus, l’agilité ou les outils sont
pointés du doigt.
Fin de la transformation et passage en
vitesse de croisière
• Le coach est démobilisé
• Progressivement les anciennes pratiques
se réinstallent.
• La transformation est dégradée pour que
pour quelques individus puissent garder
la main sur les équipes, le budget et les
décisions.
Conclusion:
Il faut apporter une attention forte sur les collaborateurs qui refusent de s’inscrire dans les orientations prises par l’entreprises.
Le coach doit avoir un accompagnement fort de ces personnes qui sont réfractaires au changement. De telles personnes peuvent
« planter » une transformation.
S’ils ne peuvent s’inscrire dans les changements en cours, il faut leur proposer des alternatives (mobilité interne, etc…) en dehors du

22. 3e cas d’usage: mauvais casting pour
le coach
Description de la situation
• Le management souhaite lancer la transformation agile@scale
• L’accompagnement se fait par un coach agile n’ayant pas un vécu significatif du monde de l’IT.
Avant le lancement de la transformation
• Le coach va lancer des assessment
auprès des équipes afin de connaitre leur
expérience de l’Agile.
Pendant
• Le coach met en place de l’agilité avec un
aspect @scaled
• Mise en place des fondamentaux des
rôles,
• Les équipes se plaignent que cet
accompagnement est théorique
• Les managers qui ont peur d’être écartés,
font le nécessaire pour mettre en lumière
des dysfonctionnements dû à la transfo.
Fin de la transformation et passage en
vitesse de croisière
• Le coach est démobilisé
• L’agilité est installée au niveau des
équipes
• Mais du point de vue systémique, ça ne
marche pas.
Conclusion:
Une transfo agile@scaled c’est de l’agilité, aussi mais beaucoup d’autres aspects.
Il faut un coach avec une solide expérience de l’IT pour interconnecter toutes les problématiques et donner une vision globale.
Dans ce cas de figure:
• Le coach agile aura tendance a renvoyer la faute d’un échec sur le Framework (SAFe est trop complexe, trop complet, trop
hiérarchique, pas assez « agile », etc…)
• (ce que j’ai observé) les équipes ne rejettent pas l’agilité, mais « les coachs » trop théoriques. Elles se lancent dans des
expérimentations déstructurées avec leur Scrum Master.
• On n’atteint pas le but d’optimiser le « TOUT » (vision systémique), mais des expériences d’agilité naissent dans différents endroits de

23. 4e cas d’usage: le collectif ne se créé pas
(One Team)
Description de la situation
• Les équipes sont structurées autour de composants (Front, API, Métier, etc…)
• Il existe un mélange d’équipes internes et prestataires
• Dans le « monde d’avant » ces équipes s’entendent relativement bien, elles résolvent leur problèmes en se basant sur les « héros » de
chaque équipe.
Avant le lancement de la transformation
• Les équipes sont formées à l’agilité
Pendant
• Les rituels équipes sont mises en place et
fonctionnent
• Les rôles sont pris en main par les
différents acteurs
• Les équipes sont chacune sur leur
Stream, tiennent leur engagement
• Collectivement les engagements globaux
ne sont jamais atteints.
Fin de la transformation et passage en
vitesse de croisière
• Le coach est démobilisé
• Les équipes ont une pratique de l’agilité
• Le dispositif agile@scale ne fonctionne
pas
• Les « héros » ont été désactivés mais
globalement ça ne fonctionne pas
• Des tensions apparaissent entre les
équipes qui sont inter dépendantes.
Conclusion:
• Si on échoue à créer un collectif fort, l’après transformation peut être pire que « l’avant » car initialement les choses marchaient en
mode best-effort. On a déconstruit ce qui marchottait et ce qui est mis en place n’est pas à la hauteur.
• Avec ce type d’anti pattern: tout le monde est responsable, mais personne ne l’est réellement.
• Un collectif fort avec des valeurs de bienveillance et d’entraide est un des socles pour une bonne transformation.

24. Erreurs avant lancement…

25. … pendant…

26. … et finalisation de la transfo

27. Quelques conseils
29/09/202

28. 1. Ne pas prendre à la légère une transformation agile@scale, la quasi-
totalité de la DSI et d’autres services seront embarqués.
2. Faites vous accompagner par un Coach Orga - qui maîtrise tous les
processus autour de la DSI et pas seulement l’agilité.
3. Ne pas négliger le budget global de la mise en place d’un tel dispositif. Par
exemple un train de 100 personnes dont la montée en compétence
nécessite environ 1 an, 1 an et demi aura un coût global (dispositif
d’accompagnement, formations, baisse de productivité pendant une phase
transitoire, etc…) de 1 à 1,5 Millions d’€uros (le ROI étant largement positif).
4. S’assurer que le management est bien embarqué et sera promoteur de la
transformation.