Infiltré dans une ample transformation agile

831 vues

Publié le

Un retour d'expérience concret et vécu sur plusieurs années passées au sein d'une ample transformation agile d'une très grande entreprise.

Publié dans : Business
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
831
Sur SlideShare
0
Issues des intégrations
0
Intégrations
69
Actions
Partages
0
Téléchargements
8
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Infiltré dans une ample transformation agile

  1. 1. @pierre_fauvel INFILTRÉ DANS UNE AMPLE TRANSFORMATION AGILE
  2. 2. @pierre_fauvel PITCH  Venez découvrir de l’intérieur à quoi ressemble une transformation agile de grande ampleur.  Il s’agit d’un retour d’expérience personnel et partial, contrasté.  Auditoire : n’importe qui qui est partie prenante d’une transformation agile ou qui va l’être, au delà des premiers pilotes. Une expérience d’un projet agile est préférable.
  3. 3. @pierre_fauvel Vision un peu Naïve DEPLOYER SCRUM ET XP
  4. 4. @pierre_fauvel AGILE : SCRUM ET XP NE SUFFISENT PAS Innovation Games Formation Product Owner Fearless Change Lean Startup Formation Kanban Impact Mapping Workshop Lean Agile Green Belt Value Driven Dévt Poster SAFe Agile4 Managers
  5. 5. @pierre_fauvel FIXER L’AGILITÉ AU NIVEAU MÉTHODO ?  Référentiel méthodologique : utilisé uniquement par les ingénieurs qualité mais déterminant car qualité présente  Templates documentaires : finalement très peu, valeur ajoutée importante des exemples spécialisés (ex: BI)  Wiki de la transformation : abandonné remplaçé par le RSE pour l’exterieur, un SVN en interne  Grilles : finalement trois pour des usages distincts  Evaluation des risques à y aller en agile et actions de mitigation  Revue par les ingénieurs qualité (produit et process)  Evaluation de la maturité en agile  Formations : ce qui fait foi finalement c’est les supports de formation parce que eux sont à jour.
  6. 6. @pierre_fauvel LA VARIETE DES PROJETS
  7. 7. @pierre_fauvel CAS DE FIGURE ½ :  Progiciels : étonnament, ca se fait bien si dans l’équipe on a une bonne maîtrise du progiciel  BI : assez adapté, pour peu qu’on adapte le template de User Stories pour inclure d’autres éléments comme le mapping des données  Grand système : un echec cuisant. Difficultés techniques (notamment gestion de version et branches), choc culturel  Fixed Price : difficile, discussions sans fin. Pour l’instant Time & Material, sécurisés par des partenariats très forts par entité  Développents réalisés par les éditeurs : difficile de les faire , discussion sans fin. Mieux vaut passer par des intégrateurs. Approche “Agile Black Box” : demander certaines propriétés de l’agile, sans imposer un process.
  8. 8. @pierre_fauvel CAS DE FIGURE 2/2 : PAS N’IMPORTE COMMENT  Micro-équipes : mutualiser les projets, équipes multi projet. Plus ScrumBan que Scrum.  Programmes : galère s’il s’agit d’un SI et pas d’un produit. Envisager des éléments de Agile@Scale Larman ou Leffingwell : backlog global, synchro des releases, …  Distribué : pas simple mais pas impossible. Se rencontrer en personne au début. Visio, conf call. Formaliser plus (tant pis pour le “un logiciel qui fonctionne plutôt qu’une documentation exhaustive”)  Internationaux : représenter dans la “core team” les différentes zones  Multi-domaines : représenter dans la “core team” les différents métiers.  Gros déploiements : se faire aider pour la conduite du changement, quitte à ce qu’elle soit un peu conventionnelle.
  9. 9. @pierre_fauvel “PRESCRIPTIF…  … et contextualisable”  Ce qu’il faut retenir :  Les projets “agiles” doivent avoir un certain nombre de caractéristiques “visibles” qui les rattachent avec l’agilité telle qu’on l’imagine.  Toute la stratégie projet doit être adéquate, tout échec d’un projet agile risquant d’être imputé à l’agilité. Lever tous les risques, liés ou non à l’agile.  Si tout va bien, personne ne viendra poser de questions embarassantes sur l’agilité ou non d’un projet. S’il y a le feu, la lisibilité de l’agilité permet de se couvrir.
  10. 10. @pierre_fauvel Ceci n’est pas…. ANALOGIES TOXIQUES SUR LES PROJETS
  11. 11. @pierre_fauvel UN SI N’EST PAS UN PRODUIT  L’agilité repose sur la capacité à définir un produit.  Un SI est un SI, pas un produit.  Les idées valables pour les produit (backlog au niveau programme) ne s’appliquent pas telles quelles à un SI :  Les commanditaires sont multiples, nécessité d’arbitrage entre les sources d’exigences  S’il est parfois possible de relier un projet à des réductions d’effectifs ou de stocks ou à une meilleure performance, La notion de valeur pour un SI n’est pas évidente : combien rapporte la fin d’une obsolescence ? Une obligation règlementaire ?
  12. 12. @pierre_fauvel JALONS : CECI N’EST PAS UN PRODUIT MANUFACTURÉ Faisabilité Conception Devt Production de masse Un projet informatique (build) n’est pas un produit manufacturé (make) : pas la même variabilité, pas la même stabilité des besoins, etc… Appliquer le même jalonnement aux deux est un raccourci qui engendre d’inutiles rigidités, notamment en terme de documents à fournir et d’approche systématique mal adaptée aux différents cas de figure. Néanmoins passer un jalon d’engagement budget + délai + nombre de points a des vertus. En effet c’est au moins à ce moment là que la confrontation entre désirs et réalité se met en marche, et que l’effort permanent de simplification débute s’il n’a pas débuté avant.
  13. 13. @pierre_fauvel EVANGELISTE OU REPRESENTANT DE COMMERCE ?
  14. 14. @pierre_fauvel TRANSFORMER : FORMER NE SUFFIT PAS 2010 Jeux dans les JumpStart 2011 Scrum Lego City Game x 80 2012 Green Belt Update 2012 : “Agile par défaut” 2012 Vidéo en présence du PDG à l’assemblée des PM 2013 Présentation au comité de direction du groupe Update 2013 : “Value Driven Development” 2014 Agile4Managers DSI + n-1
  15. 15. @pierre_fauvel ACCOMPAGNEMENT DES PROJETS : DOUBLE JEU  Pré-assessment : faut-il y aller en agile (lire : vendre l’agile)  Assessment : faut-il y aller en agile (lire : vendre l’agile au business et pousser des éléments d’agile dans l’organisation du projet à venir)  Formation : théorie agile et scrum (lire: jeux pour conduire le changement et souder l’équipe)  Workshop Impact Mapping : produire le backlog (lire : créer un consensus, souder l’équipe élargie, annoncer au business qu’il n’aura pas tous les jouets sur sa liste au pere noel, prioriser : I oui, II peut-être, III probablement pas)  Coaching : aider sur la théorie agile, les pratiques, les usages dans l’entreprise (lire: coacher l’équipe pour qu’elle ose prendre la parole, coacher le scrum master pour qu’il résiste, coacher le métier pour qu’il découvre la gestion de projet)  Engagement après 3 sprints : vérifier l’application de la méthode (lire: faire comprendre au scrum master / chef de projet qu’il faut annoncer au métier qu’il n’aura pas tout, et qu’il ne sert à rien de spéculer sur une augmentation de la vélocité, et que la seule solution est de revoir le périmètre).
  16. 16. @pierre_fauvel EMBARQUER LA QUALITÉ Pilotes relaxation des contraintes de garantie qualité, scepticisme Accélération friction, extrémisme des 2 côtés Généralisation A bord, Moteurs Green Belt Grilles Support Top Down
  17. 17. @pierre_fauvel ENCERCLER LE MIDDLE MANAGEMENT Top Down : Engagement for t de la DSI Fixer les objetifs personnels Lateral Réseau de pairs Notoriété de la méthode hors de l’entreprise Bottom Up Vision concrete des avantages Solutions pour les contraintes Perte de pouvoir Risque
  18. 18. @pierre_fauvel APRÈS LE CHASM ? Résistance passive et silencieuse Adhesion passive et molle Contextes projet moins adaptés à l’agile, Agilité tordue et moins lisible On adresse ces populations
  19. 19. @pierre_fauvel INDICATIONS THÉRAPEUTIQUES
  20. 20. @pierre_fauvel 8 QUESTIONS, 2^8 POSSIBILITIES  Prescriptive versus Contextualized  Therapist versus Lean senseï  Serious versus Playfull  Proven versus Innovative  Persuading versus Leading  Intensive vs Lasting  Planned vs Reactive  Visible vs Invisible
  21. 21. @pierre_fauvel COURBE D’AGILISATION D’UN PROJET Assessment Formation Lancement Premiers sprints Engagement … Projets longs : De moins en moins agiles Idéalement 15jh/projet, en moyenne 8jh en 2013 … Conditions de sortie du coaching : 3 à 6 sprints engagement passé maturité suffisante et en hausse Passage de relai du contrôle à la qualité
  22. 22. @pierre_fauvel TAUX D’AGILISATION DE L’ENTREPRISE 2009 2010 2011 2012 2013 2014 2015 30% 40% 80% 100% 55% … (1) Annoncé en copil 80% en deux ans, (3) Annoncé en copil 55% en 2015 sans aucune base factuelle (4) Quand on gratte un peu, la cible finale est 100% (5) A mon avis, 40% serait une meilleure cible, à consolider et optimiser (2) Une évaluation réaliste donne 40% au bout d’un an
  23. 23. @pierre_fauvel RÉPARTITION DE L’ACTIVITÉ DES COACH Coaching projet Autres activités de transform ation Equipe de coach Activité idéale des coach Activité réelle des coach Faut-il coacher tous les projets ?
  24. 24. @pierre_fauvel KPI ENVISAGÉS  Indicateurs de moyen :  Taux d’agilisation  Maturité moyenne des projets (cf grille)  Variance du taux d’agilisation entre entités  Effort de coaching / budget total  Synchronisation au sein des programmes  Indicateurs de résultat  Temps de mise à disposition des solutions (intègre le % de valeur des MVPs)  Throughput : valeur par unité de temps  Taux d’usage des solutions par les utilisateurs (par sondage)
  25. 25. @pierre_fauvel Ceci n’est pas…. ANALOGIES TOXIQUES SUR LA TRANSFORMATION
  26. 26. @pierre_fauvel UN COACH AGILE N’EST PAS UN COACH  Un coach agile n’est pas (qu’) un coach. C’est un  Formateur  Mentor  Consultant  Change agent, politicien, showman  Contrôleur de conformité à un idéal agile  Parfois Project Officer  Coach : 10% du temps grand maximum
  27. 27. @pierre_fauvel UNE TRANSFORMATION AGILE N’EST PAS UN PRODUIT  Les actions reposent beaucoup sur les opportunités (notamment d’évènements à hacker pour faire passer des messages)  L’expérience montre un fossé énorme entre ce qu’on avait imaginé au début de l’année, ou même il y a six mois et ce que l’on a fait. Et c’est bien.  Définit un critère d’acceptance est parfois ardu. Quand-est ce qu’une grille est finie ? Quand elle est validée ? Comment savoir qu’elle est partagée, généralisée ? Par interview ?
  28. 28. @pierre_fauvel UN PRODUCT OWNER D’UNE TRANSFORMATION AGILE N’EST PAS UN PRODUCT OWNER  Le “product owner”  N’a pas d’expérience du sujet principal (l’agilité)  Attend du conseil sur le sujet de la part des membres de l’équipe  Ne peut pas prioriser  Est incapable de définir une vision à long terme (si ce n’est un impact sur des indicateurs subjectifs)  Est capable de réagir à une proposition, à une idée, mais a besoin d’une base de proposition.
  29. 29. @pierre_fauvel UN SCRUM MASTER D’UNE TRANSFORMATION AGILE N’EST PAS UN SCRUM MASTER  Le “scrum master”  Est bien en peine d’avoir un périmètre pour des sprints puisque tout change beaucoup, notamment du à la charge consacrée par les coach aux projets par rapport aux chantiers  Essaie de discipliner un groupe d’experts agiles habitués à monter sur scène et férus de débats d’experts, ce qui est un réel challenge.  Peut toutefois utiliser des bonnes pratiques de facilitation d’équipes, ex: sociocratie ou process com  Considérer qu’il s’agit d’une équipe Kanban serait moins impropre.
  30. 30. @pierre_fauvel UNE EQUIPE DE TRANSFORMATION AGILE N’EST PAS UNE EQUIPE  L’équipe  Passent 80% de sont temps à  travailler seuls  sans interaction  à coacher des projets qu’eux seuls connaissent  et sur place.
  31. 31. @pierre_fauvel A TITRE PERSO
  32. 32. @pierre_fauvel ÊTRE COACH DANS UNE GRANDE TRANSFORMATION + -  Environnement riche et dense  Top Down qui dynamise  Emulation des autres coach  Temps plein  Top Down subi  Dilution de la responsabilité du coach  Besoin de sortir prendre de l’air frais  Pas de vision d’ensemble  Spécialisation
  33. 33. @pierre_fauvel ULTIME MANTRA
  34. 34. @pierre_fauvel  “IT’S NOT ABOUT ME”

×