Etape Parisienne de l’Agile Tour 2009 l’après-midi (partie 1)

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).

Creating Leaderful Teams for High Performance – Deborah Hartmann Preus

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.

Illusions et Désillusions – Patrice Petit, Agilii, Agilbee, Université Paris Ouest

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 :

  • la réécriture de l’application, qui peut donner l’illusion d’avoir résolu le problème, sans pour autant l’avoir réellement identifié et combattu
  • la mise en place d’une méthode agile, qui a pour effet entre autre de laisser place à une décharge cognitive collective et individuelle

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 :

  • le client ne viendra pas sur site
  • le manager ne nous sert plus à rien

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 :

  • self awareness, doute et curiosité
  • Advocatus Diabolu (éviter le conformisme, éviter l’endormissement des pratiques, auto-réguler les rumeurs)
  • améliorer la qualité du consensus et de la coopération entre individus

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.

A Themed Based Analysis of the Expectations and Concerns of the Developers prior to the Introduction of an Agile Development Methodology in a Large Software Development Team – Mary Giblin

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 :

  • des Business Managers et Product Managers
  • des System Engineers
  • des Developers
  • des Features Testers
  • des Integration Testers et System Testers

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 :

  • la mise en place de pratiques Scrum et XP
  • la création d’un Product Owner issu de l’équipe de conception (System Engineers)
  • l’immersion d’un testeurs (Feature Tester) dans l’équipe de développement pour améliorer le travail main dans la main entre ces deux populations

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 :

  • un existant fortement piloté par la documentation a été dénoncé
  • la relecture de code et les tests unitaires se faisaient à la marge, et leur adoption complète dans le processus est vue d’un bon oeil
  • malgré les bénéfices reconnus, des doutes ont été émis sur le Pair Programming, notamment le risque de conflits entre équipiers
  • au sujet du TDD, les sondés se posaient des questions concernant le code existant, et avouaient que leur adoption passeraient par un changement de vision assez important
  • le fait d’avoir des itérations plus courtes et fréquentes était vu comme potentielle source de pression
  • le rassemblement des équipes dans un Open Space était considéré comme un risque de distraction et une source de nuisance (bruit)

Quant aux questions quantitatives, les tendances qui se sont dégagées étaient :

  • plus de 60% d’adhésion sur la faible utilité de la documentation
  • une adhésion à 100% sur l’idée d’essayer de nouvelles méthodes et de s’améliorer continuellement, pour autant 23% des sondés auraient préféré conserver la situation existante et tenté de l’améliorer
  • 87% de convictions que les méthodes agiles allaient adresser au moins certains, si ce n’est tous, des points noirs du processus existant
  • seulement 19% de sondés trouvent qu’il risque d’y avoir trop de concepts à introduire en une seule fois

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 ».

Seconde partie de l’après-midi

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 :

Blogs

Etape Parisienne de l’Agile Tour 2009 l’après-midi (partie 2)

Retour sur l’étape Parisienne de l’Agile Tour 2009

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *