Présenté par Pierre Medina, Scaled Agile Services
Vous envisagez de vous lancer dans une transformation vers SAFe ou un autre framework d'agile@scale et vous demandez quelles erreurs ne pas commettre ?
Nous vous présenterons un ensemble d'éléments, de patterns, ... qui peuvent faire échouer votre transformation et des pistes d'actions afin de contourner ces éventuels problèmes.
Pierre Medina, Coach Agile / SPC / RTE / STE, Scaled Agile Services
Pierre Medina est un coach agile qui se defini avant tout comme un professionnel de l'informatique. Avant de devenir coach agile, il a passé 15-20 ans à faire du projet dans les DSI de diverses tailles en tant que Développeur, Architecte Java/JEE, Chef de projet, Directeur de projet, CTO, Auditeur de grands projets et coach. Certifié Scrum Master en 2006, il a une longue expérience avec l'agilité qu'il a déployé dans une multitude d'environnements différents. Depuis 2017 il s'est fortement spécialisé dans l'agilité à l'échelle. Déployant souvent SAFe avec un saupoudrage de LeSS et Spotify selon les besoins des clients. A son actif 6 trains SAFe, environ 15 à 20 PI. Tous les trains qu'il a déployés étant tous encore fonctionnels.
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
08/11/2021 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
08/11/2021 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. »
08/11/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. »
08/11/2021 7
8. Cycle agile : Le changement et le client au Centre
Pre-Game Staging Sprint Development Sprints Wrapper Sprints
8
08/11/2021
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
08/11/2021
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
08/11/2021
Désordre « Agile »
11. Le challenge de la transformation
11
08/11/2021
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
08/11/2021
14. Dalaï LAMA (Autorité Spirituelle et Religieuse Tibétain contemporain)
« Ouvrez vos bras au changement, mais ne laissez pas s’envoler vos
valeurs. »
08/11/2021 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
08/11/2021
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.
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 dispositif transformé.
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 la DSI.
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.
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.
Notes de l'éditeur
Mon expérience du changement en entreprise:
Une vingtaine de DSI
5-6 refontes majeures de DSI (durée de 18 à 36 mois)
Plus de 10 ans en tant que CP ou DP d’équipes de développements
CP ou DP d’équipes de RUN
Plus de 15 ans de recul sur le waterfall
Plus de 15 ans de recul sur l’agilité
Passage par les plus grosses DSI Françaises
Hérité d’industries plus anciennes,
Appliquées à l’informatique depuis des decennies
Processus séquentiel
Expression de Besoin -> analyse -> Conception -> implémentation -> vérification -> Mise à disposition
Les inconvénients:
Effet tunnel
Tensions entre les parties prenantes
Resistance accrue au changement
Déjà il y a 2500 ans Héraclite d’Ephese disait: « Rien n’est permanent sauf le changement »
Il nous fallait donc:
Être ouvert au changement
Diminuer l’effet tunnel
Diminuer les risques
Et être plus adaptable
Il nous fallait donc:
Être ouvert au changement
Diminuer l’effet tunnel
Diminuer les risques
Et être plus adaptable
L’agilité et ses diverses implementations répondent en grande partie à ces défis.
4 valeurs, 12 principes: ouvert au changement, être bienveillant, responsabiliser les acteurs, bienveillance, courage, etc…
Le process agile en bleu ; waterfall en tiret
La valeur est delivrée en continue (haut gauche)
Le client est en confiance et le risque financier perçu décroit rapidement
L’effet tunnel de plusieurs mois est remplacé par un « micro effet tunnel » de 2-3 semaines
L’ensemble des acteurs engagés peuvent rester adaptables.
L’agilité fonctionne à merveille jusqu’à
L’agilité fonctionne à merveille jusqu’à
Piège: tomber dans un système normatif, auto définissant et auto portant. Normalisant et normant tous les comportements et process…
Il faut adapter le Framework à l’entreprise et non transformer violemment la société pour qu’elle colle aux framework.
1 seul de ces anti-patterns et vous serez en mode « best-effort » et non en agile@scale
Issue de mon experience opérationnelle.
MidMap sur l’angle:
Comment je sais que je suis dans ce cas, le management demandera aux équipes :
Une évaluation en budget capacitaire de la Feature.
Un macro planification des Features ou US dés la phase de gestion de la demande