Téléchargé 22 fois
Téléchargé parFrench Scrum User Group
Scrumday 2015 : Equipe agile, survivre à la disparition des managers par Kévin Maccioni et Fabien Barbaud
Le document traite de la transformation d'une entreprise vers des équipes agiles, mettant en avant la disparition du middle management et le passage à une autonomie des équipes. Il évoque les défis de la dette technique, l'organisation des réunions et l'importance de l'évaluation des performances pour améliorer les processus. Les conclusions soulignent la nécessité de fournir du sens et des outils pour renforcer l'autonomie des équipes.
Contenu connexe
Similaire à Scrumday 2015 : Equipe agile, survivre à la disparition des managers par Kévin Maccioni et Fabien Barbaud
Scrumday 2015 : Equipe agile, survivre à la disparition des managers par Kévin Maccioni et Fabien Barbaud
- 1. ➡Équipes agiles :survivre à la disparition des managers ➡ K.Maccioni – F.Barbaud
- 2. MERCI À NOSSPONSORS et partenaires
- 3. Qui sommes-nous ?3 Équipes agiles : survivre à la disparition des managers ➡Kévin Maccioni : Coach Agile ➡Fabien Barbaud : Directeur Technique ➡Notre entreprise : Public-Idées Créée en 2005 Plateforme de marketing à la performance Monétisation d’un réseau de sites éditeur Rémunération sur le ROI
- 4. Notre environnement 4 Équipesagiles : survivre à la disparition des managers ➡Notre client ? Public-Idées ➡Avril 2011 : méthode Scrum Inefficacité de l’organisation précédente Recherche de nouvelles solutions ➡En mouvement constant depuis Doublement des effectifs Nouvelles pratiques ➡Agilité = culture d’entreprise
- 5. Précédemment… 5 Équipes agiles: survivre à la disparition des managers ➡Impact de l’Agilité sur notre organisation Bouleversement des processus Apport d’autonomie à l’équipe ➡Disparition du middle management Adaptation des anciens chefs de projets Redistribution des responsabilités Équipe : entité unique de prise de décision ➡Équipe autonome et auto organisée … sur le papier
- 6. Équipe auto organisée6 Équipes agiles : survivre à la disparition des managers Équipe Product Owners Développeurs Coach Admin système Top Management
- 7. Ses responsabilités 7 Équipesagiles : survivre à la disparition des managers CTO STRATÉGIE FONCTIONNEL PO Dev TECHNIQUE Admin ENVIRONNEMENT Coach ACCOMPAGNEMENT
- 8. L’équipe sans management8 Équipes agiles : survivre à la disparition des managers
- 9. 9 Équipes agiles :survivre à la disparition des managers L’équipe sans management Court terme Long terme Flux entrants à gérer
- 10. L’équipe sans management10 Équipes agiles : survivre à la disparition des managers
- 11. Les nouveaux arrivants11 Équipes agiles : survivre à la disparition des managers ➡Accueil des arrivants par l’équipe ➡Passage du nouveau avec chaque membre de l’équipe ➡Avis des membres à la fin de la période d’essai ➡Nouveaux bien accueillis, mais mal formés…
- 12. Le support 12 Équipesagiles : survivre à la disparition des managers ➡Départ du responsable support ➡Prise en charge du support par l’équipe ➡Deux personnes minimum en charge ➡Support maintenu mais consommateur de temps
- 13. Le support 13 Équipesagiles : survivre à la disparition des managers Support Court terme Long terme Flux entrants à gérer
- 14. La dette technique14 Équipes agiles : survivre à la disparition des managers ➡Dette technique grandissante ➡Dette présente sur les nouveaux projets ➡Équipe non sensibilisée à la qualité ➡Dette consommatrice de temps
- 15. La dette technique15 Équipes agiles : survivre à la disparition des managers Dette Support Court terme Long terme Flux entrants à gérer
- 16. Organisation 16 Équipes agiles: survivre à la disparition des managers ➡Organisation constamment remise en question ➡Multiplication du nombre de réunions ➡Réunions en perte d’efficacité
- 17. Organisation 17 Équipes agiles: survivre à la disparition des managers Organisation Dette Support Court terme Long terme Flux entrants à gérer
- 18. Coach agile 18 Équipesagiles : survivre à la disparition des managers Retour sur le terrain Accompagnateur Facilitateur Prise de décision Actions chronophages Pratiques agiles Formation Sphère organisationnelle
- 19. 20 minutes pouragir 19 Équipes agiles : survivre à la disparition des managers ➡Beaucoup de temps passé en réunion ➡Trop peu de décisions prises ➡Restreindre les espaces de réflexion et les rendre efficaces ➡Déroulement Je viens si je peux apporter quelque chose Je ne viens pas si ça ne m’apporte rien Rappel de l’objectif Tour de table des idées 4 actions maximum à mettre en place immédiatement ➡http://www.20minutespouragir.com
- 20. Lead Developper 20 Équipesagiles : survivre à la disparition des managers Accompagnateur Test unitaires Technique de refactor Sphère technique Pair Programming Formation Sensibilisation code smell Dojo Post mortem
- 21. Post Mortem 21 Équipesagiles : survivre à la disparition des managers ➡Développements en échec ➡Pas de prise de recul sur les causes ➡Créer un espace d’analyse de problème ➡Déroulement Les acteurs de l’échec retracent les évènements marquants Présentation de la chronologie à l’ensemble de l’équipe Identification des points de blocage – d’échec Création du débriefe avec les pièges à éviter à l’avenir
- 22. L’équipe sans management22 Équipes agiles : survivre à la disparition des managers
- 23. WTF? 23 Équipes agiles: survivre à la disparition des managers Salaire ? Horaires ? Qualité ? Livraison ? Organisation ?
- 24. Intervention du topmanagement 24 Équipes agiles : survivre à la disparition des managers ➡Choc d’engagement : Provoquer une réaction de l’équipe Jouer la transparence ➡Fournir un objectif commun Impulser une nouvelle dynamique Partager une vision ➡Déroulement Déroulement sur deux réunions Premier point : transparence Second point : vision
- 25. Intervention du topmanagement 25 Équipes agiles : survivre à la disparition des managers « Satisfaction dans mon travail, de mon équipe et de mon client ! »
- 26. Intervention du topmanagement 26 Équipes agiles : survivre à la disparition des managers
- 27. Intervention du topmanagement 27 Équipes agiles : survivre à la disparition des managers Stabilité – Evolutivité – Livraison
- 28. Mesurer, évaluer, améliorer28 Équipes agiles : survivre à la disparition des managers ➡Mise en place d’outils de mesure Code : convention, duplication, complexité, … Livraison : temps de traitement moyen, durée de développement, … « Vous ne pouvez pas contrôler ce que vous ne pouvez pas mesurer » Tom DeMarco
- 29. Mesurer, évaluer, améliorer29 Équipes agiles : survivre à la disparition des managers ➡Point bimensuel Présentation de l’évolution des indicateurs devant l’équipe Valorisation des réussites Identification des prochaines étapes pour continuer à s’améliorer « Vous ne pouvez pas contrôler ce que vous ne pouvez pas mesurer » Tom DeMarco
- 30. Comment survivre !30 Équipes agiles : survivre à la disparition des managers ➡ Apporter du sens, ➡ Proposer des outils pour devenir autonome, ➡ Ne pas attendre l’impossible.
- 31. Suivez-nous ! 31 AgileTour – Agilité : la fin du middle management ➡@kmaccioni ➡@BarbaudFabien ➡http://coaching.publicidees.com/
- 32.
Notes de l'éditeur
- #4 KMI Pour comprendre pourquoi on vous parle de middle management Présentation perso Kévin : Je suis coach agile depuis 1 an et demi au sein de la société PI. Mon rôle est de conseiller et d’accompagner les équipes dans leur transformation agile. J’interviens aussi bien auprès du management que de l’équipe technique. Ma vision du coaching : pas de parti pris, prise de décision et autonomie ! FBD Fabien : Je suis Directeur Technique et associé de Public-Idées. Mon rôle est d’encadrer l’ensemble de l’équipe technique et de fixer, avec le comité de direction, la stratégie globale de l’entreprise sur les prochaines années. Je suis personnellement très sensible à l’aspect humain de l’entreprise et je pousse mes collaborateurs à s’épanouir dans leur travail. Présentation entreprise : Création en 2005 Plateforme de marketing à la performance Monétisation d’un réseau de sites éditeurs auprès de nos clients annonceurs Rémunération sur le ROI (vente, formulaire, …)
- #5 FBD Petit focus sur notre environnement Première question : qui est le client de l’équipe technique ? La réponse est simple : Public-Idées ! Pourquoi : notre activité est basée sur une technologie propriétaire développée en interne. Nos équipes, qu’elles soient commerciales, opérationnelles ou comptables, travaillent avec cette technologie au quotidien. En Avril 2011 : début de notre transformation vers l’Agilité : mise en place de la méthode Scrum suite à la constatation de l’inefficacité de l’organisation précédente. Ce qui m’a poussé à chercher de nouvelles solutions. Depuis cette date, l’équipe technique est en évolution constante : Tout d’abord, la croissance de l’entreprise nous a amené à doubler les effectifs ce qui a eu un fort impact sur l’organisation de l’équipe, De plus, nous mettons en place régulièrement de nouvelles pratiques agiles : par exemple, l’abandon du système itératif de Scrum pour le remplacer par un système en flux tiré. Cela nous a permis d’être au plus proche des besoins de nos utilisateurs. Notre objectif a toujours été de faire de l’Agilité notre culture d’entreprise. Et nous y travaillons au quotidien.
- #6 KMI Pour ceux qui nous on vu l’année précédente : Agilité : fort impact sur notre organisation Processus et organisation du middle management remise en cause Demande d’autonomie de la part de l’équipe Après de nombreuses modifications d’organisation, et beaucoup d’accompagnement au changement : Disparation du middle management, « reconversion » des anciens chefs de projet Retour au développement, coaching, départ Redistribution des responsabilités à l’équipe (responsabilités fonctionnelles, organisationnelles, techniques…) L’équipe technique devient une entité unique en ce qui concerne les différentes prises de décision Conclusion : l’équipe est dorénavant autonome et auto organisée…du moins sur le papier
- #7 KMI Commençons par situer le middle management dans l’entreprise : Avant notre transformation agile, nous avions une structure hiérarchique classique : pyramidale ! Le top management, au sommet, gérant les enjeux stratégiques et assurant la vision a long terme Suivi par le middle management, effectuant le relai entre les décisions du top management et les actions de la sphère opérationnelle Exécutant les missions fixées par la hiérarchie Comment les différentes strates communiquaient entre elles ? Communication descendante : le middle management filtrait l’information provenant du top, l’interprétait et la délivrait à son équipe. Communication montante : les développeurs reportaient régulièrement à leur manager l’avancée des projets qui lui-même synthétisait l’information afin de la fournir au top management Ce système pyramidale avait pour but de qualifier l’information mais la pertinence du message était très dépendant de l’interprétation qu’en faisait le middle management.
- #8 FBD Maintenant que nous avons fait le tour de l’équipe, présentons ses différentes sphères de responsabilité Important : Chaque acteur de l’équipe a des sphères de responsabilité différentes, mais mis à part le CTO (top), aucun n’a de position hiérarchique supérieur PO : responsabilité fonctionnelle
- #9 KMI Au long de la vie de l’équipe surviennent des problèmes Malgré l’envie d’autonomie, les habitudes restent L’équipe n’a pas tout le temps le reflexe de trouver l’outil adéquat Le coach intervient Il prend connaissance du problème Il créer le cadre nécessaire pour que l’équipe trouve cet outil Et il accompagne l’équipe dans la résolution Le but étant d’amener l’équipe à être autonome lorsqu’un problème survient
- #11 Tout se passe bien L’équipe est motivée Pleins de changements s’effectuent On laisse l’équipe en pleine autonomie Ca se complique Baisse de productivité perçue Équipe prenant des décisions hâtives, voire pas de décision, se masquant les problèmes
- #12 L’équipe a pris la responsabilité du recrutement Le top management fait confiance à l’équipe sur le choix de ses coéquipiers Groupe fondé pour le recrutement Ensemble de l’équipe concentrée sur la validation de la période d’essai Peu avant la fin de période : Les membres de l’équipe donne leur avis au recruté tour à tour Les avis sont rassemblés par le coach et fournis au top management Beaucoup de temps consacré à l’évaluation Evaluation prime sur la formation et la montée en compétence Les nouveaux recrutés prennent plus de temps pour appréhender l’existant
- #13 Lors de la transformation – disparition des managers : le responsable support ne trouve pas sa place : départ L’équipe récupère la responsabilité et la gestion du support Product Owners : sensibilisés sur la priorisation des traqueurs L’équipe transforme la gestion des traqueurs en flux tiré grâce à Kanban Le flux support doit constamment être géré par au minimum 2 personnes Le flux support est un flux constant et dense donc très consommateur de temps
- #14 Mise en place du support : près de la moitié de la ressource de temps consommée
- #15 La dette technique accumulée est très consommatrice de temps également Elle s’accumule d’autant plus qu’elle est aussi présente sur les nouveaux projets C’est principalement dû à la logique Scrum mise en place chez nous qui a poussé les développeurs à privilégier la livraison rapide de code plutôt que de passer du temps à refactorer
- #16 L’équipe accumule autant de temps de dette que de temps qu’elle passe à développer
- #17 Conséquence du remplacement de Scrum par Kanban Abandon des rituels scrum Remise en question constantes des pratiques 20minutespouragir -> 40minutespouragir -> 1hpouragir Organisation autour de la qualité, des pratiques XP, de l’amélioration de l’équipe, des outils Tous les sujets traités en même temps
- #18 Constat : le temps que consacre l’équipe sur leur cœur de métier représente moins de la moitié du temps L’impression de perte de productivité est avérée Équipe sur trop de sujet en parallèle Autonomie non maîtrisée
- #19 En réaction à cette situation, le coach agile retourne au sein de l’équipe Il s’attaque à toute la sphère organisationnelle : Remise en place de pratiques agiles disparues au passage de Scrum à Kanban Mise en place d’un cadre propice à la prise de décision Formation des nouveaux arrivants aux méthodes agiles et a l’utilisation de Kanban Suppression des actions chronophages inutiles (réunions trop longues sans prise de décision) Accompagnement au quotidien de l’équipe sur l’organisation et la prise de décision
- #20 Exemple d’outil du coach agile : le 20 minutes pour agir
- #21 En plus du coach agile, mise en place d’un nouveau rôle : Lead Developper != TSM : en charge des stories techniques Coaching sur la sphère technique Se base sur les pratiques XP Pair programming Refactoring Sensibilisation au code smell Accompagnement des équipes sur leurs problématiques techniques Mise en place d’une système de couverture de code par les tests unitaires
- #22 Exemple d’outil du lead developpeur : Post Mortem Issu de la serie Grey’s Anatomy Analyse des développements en echec Projet sorti buggé Développement entièrement remanié Projet ayant pris trop de retard Objectif : prendre du recul et analyser la chronologie d’un projet pour découvrir l’origine du problème Déroulement : L’équipe doit faire un travail de recomposition de l’évènement pour en retranscrire une version précise L’ensemble de l’équipe doit être présente afin que chacun analyse et en tire des leçons Les acteurs présentent la chronologie, les autres posent des questions, tentent d’identifier le problème -
- #23 Malgré la présence des coachs, l’équipe ne va pas mieux Le moral en baisse Les développeurs s’essouflent La situation devient difficile à gérer
- #24 KMI Beaucoup de sujets Chacun sur ses propres problématiques Plus simple à gérer au quotidien Rester dans sa zone de confort Le problème de mon voisin n’est pas le mien Equipe dispersée et individualiste Absence d’objectif commun !
- #25 KMI
- #26 KMI
- #27 KMI
- #28 KMI Beaucoup de sujets Chacun sur ses propres problématiques Plus simple à gérer au quotidien Rester dans sa zone de confort Le problème de mon voisin n’est pas le mien Equipe dispersée et individualiste Absence d’objectif commun !
- #29 KMI
- #30 KMI
- #31 KMI