
L'après-midi de l'étape Parisienne de l'Agile Tour 2009 a été bien plus dense que la matinée. Au programme, jusqu'à 6 sessions d'une durée de 45' (sachant que certaines sessions s'étendaient sur 2 créneaux).
Deborah Hartmann Preus a tenu une présentation sur le thème de l'équipe et de la performance, à commencer par une définition du terme "team" : individuals who committed to work together in a common goal.
Définition sur laquelle elle a rebondi pour expliquer que la répartition des membres d'une équipe dans plusieurs bureaux est une faiblesse pour ce qui est de la collaboration. Quant à la position dominante du chef, elle en a illustré les conséquences par la façon dont certaines équipes appréhendent le Chair Game (figure imposée à réaliser avec les chaises des participants et en n'ayant recours qu'à de la communication non verbale), attendant que le leader hiérarchique donne l'impulsion, perdant ainsi beaucoup en efficacité.
L'intervenante a mentionné de nombreuses références d'ouvrages pour chacun des thèmes abordés, comme par exemple Wave Rider: Leadership for High Performance in a Self-Organizing World pour illustrer le comportement du surfeur qui ajuste son mouvement en fonction des évènements (auparavant, elle avait rappelé que si la météo ne pouvait être prévue avec un degré de certitude décent pour plusieurs jours dans le futur, il n'est pas choquant que les tentatives de planification dans le temps d'un projet informatique puissent rencontrer cette même incertitude).
Il a également été question de Double Loop Learning en opposition à Single Loop Learning, soit une remise en question du statut quo plutôt qu'une simple boucle d'ajustement qui se contente de réagir de manière itérative aux conséquences plutôt que d'analyser les causes d'un état donné. En termes anglais, ce qu'il faut retenir de cette opposition est : "do the right thing" not only "do the thing right".
On a également droit à la citation d'une définition de coaching : "partnering with clients in a thought-provoking and creative process that inspires them to maximize their personal and professional potential"
Autre livre mentionné, Teamwork Is an Individual Skill: Getting Your Work Done When Sharing Responsibility au sujet du processus de responsabilité/responsabilisation.
Pour ceux qui ne veulent pas attendre que les slides soient mis à disposition par les organisateurs de l'Agile Tour, vous les trouverez déjà en ligne sur le site de l'intervenante.
Patrice Petit vient alimenter une réflexion joliment illustrée (slides) sur les illusions (problèmes) et désillusions (solutions) qu'on peut rencontrer dans un cadre agile. Il a entamé cette réflexion à la suite de l'échec rencontré par une équipe sur un projet agile, équipe qui avait pourtant été très performante avant de s'effondrer.
Tout commence par une petite définition : groupe = individus + interactions = système complexe. L'intelligence du groupe serait notamment optimale lorsque celui-ci est constitué de 5 ou 7 personnes.
Concernant le scénario classique de problème de qualité rencontré sur un projet, Patrice a présenté et commenté les 2 alternatives qui se présentent aux équipes :
Pourquoi parler de décharge cognitive ? L'intervenant a illustré cela par différents exemples, dont celui des rétrospectives : réunions d'équipes permettant de partager les observations faites pour ne pas trainer individuellement les défauts observés. La constitution de tests a non seulement l'effet positif de libérer le cerveau des développeurs/testeurs (qui peuvent s'appuyer sur ces tests plutôt que de devoir conserver dans un coin de leur tête les règles qu'ils illustrent), mais elle soulage également le travail d'architecture puisque celui se fait assez naturellement grâce aux tests.
On en arrive aux illusions liées à l'introduction de méthodes agiles, on peut par exemple citer :
Premier élément de réponse à la réflexion initiale de Patrice (comment une équipe performante peut-elle soudainement s'effondrer), l'illusion d'invulnérabilité qu'une équipe performante peut avoir, rendant difficile l'ajout ou le remplacement d'une personne étant donné que l'équipe est exigeante quant aux compétences des nouveaux. Tout cela peut donc aboutir à une équipe capable de se détruire à la moindre perte bousculant son biorythme. La remise en question perpétuelle, amélioration continue, est donc de mise, ce qui se traduit par différentes désillusions :
Que faudrait-il retenir de cette session ? Sans doute que le coach agile n'est pas juste un gestionnaire de projet, mais qu'il est encore davantage et gestionnaire RH et un psychologue, casquettes pour lesquelles il a également besoin de compétences fortes.
Sous cet intitulé très long se cache tout simplement une étude de cas réel sur les craintes et convictions d'informaticiens (développeurs, testeurs, concepteurs) suite à l'annonce par leur hiérarchie de l'adoption de pratiques agiles dans leur entreprise. L'intervenante étant là pour nous présenter le contexte, la méthode employée, et les résultats.
Après une courte présentation du contexte, à savoir un société de taille importante découpée en plusieurs unités, dont celle étudiée lors du changement d'organisation. Cette unité est constituée de 250 personnes avec principalement des rôles de développeurs, testeurs, concepteurs. De plus, elle possède des adhérences avec d'autres unités de la société. A noter que le terme large software development team n'a pas été explicité plus en détail (en particulier au niveau de la taille d'équipes logiques, facteur important dans la façon dont une organisation agile se décline).
L'intervenante a rappelé que la conséquence naturelle d'une organisation (au sens société) de taille importante était la rigidification du/des processus, justifiant le fait qu'un changement dans l'organisation passait quasi systématiquement par une décision de la direction imposée à ses salariés.
L'organisation historique de l'unité étudiée est une organisation en silos, dans laquelle on retrouve :
sans oublier les utilisateurs en entrée et sortie de cette organisation.
L'objet de l'étude a été de sonder le personnel après l'annonce par la direction de la volonté d'adopter des méthodologies agiles, avec un début de transition consistant en :
Les interviews se sont faites en 2 étapes suite à cette annonce : une première série de questions ouvertes, puis, partant de ces premiers retours, la soumission d'affirmations auxquelles les sondés devaient répondre en fournissant un degré d'adhésion (adhésion totale, forte, mitigé, faible, aucune adhésion).
Les résultats de l'enquête qualitative ont permis les constats suivants :
Quant aux questions quantitatives, les tendances qui se sont dégagées étaient :
Au final, assez peu de scepticisme, si ce n'est ceux qui auraient préféré améliorer le processus existant, ainsi que des avis assez mitigés sur le fait que les méthodes agiles étaient une mode ("buzzword").
Aspect important à préciser dans l'interprétation des résultats, la plupart du personnel avait déjà plusieurs années d'expériences, ce qui signifie qu'il faudrait sans doute rajouter le qualificatif experienced à la description "Large Software Development Team".
Rendez-vous dans le prochain (et dernier) billet pour ce qui concerne des retours d'expérience et une réflexion sur la contractualisation de forfaits agiles.
Voir aussi :
Blog
"Etape Parisienne de l'Agile Tour 2009 l'après-midi (partie 2)", par Eric Siber - 21/10/2009
"Retour sur l'étape Parisienne de l'Agile Tour 2009", par Eric Siber - 18/10/2009
Tags: methodes agiles