mercredi 12 décembre 2012

Agile Tour Paris 2012

Le mardi 20 novembre 2012 s'est déroulé l'Agile Tour Paris, dans les locaux de Microsoft à Issy-les-Moulineaux. L'Agile Tour est un vaste cycle d'évènements Agiles qui ont lieu un peu partout en France. Quel est l'état de l'art Agile ? Visite guidée des sessions auxquelles j'ai participé.


Veronique Messager - Humanisme et agilité, fin d'un paradigme managérial ?

C'est Véronique Messager qui a l'honneur d'ouvrir cette journée. Elle constate que le paradigme dominant en entreprise est profondément ancré sur la méfiance, laissant peu de place à la confiance et à la responsabilisation des collaborateurs. Les managers sont souvent de bons opérationnels qui accèdent à des postes d'encadrement sans formation adaptée à leur nouvelle responsabilité. Sans repère, certains jouent au chef et reproduisent le paradigme, parfois au risque de la santé même des employés lorsque ceux-ci sont poussés au Burn Out. Ce mode de management tend à considérer le personnel comme annexe et interchangeable. L'entreprise est globalement moins efficace si on renvoie au niveau hiérarchique supérieur les prises de décisions et les employés ne peuvent pas se sentir responsables. Véronique plaide pour une évolution des modes de management, attachée à l'homme et au bien-être. Elle remarque que la nouvelle génération refuse catégoriquement les décisions hiérarchiques qui ne sont pas motivées et portent en elle des valeurs de transparence et de partage qui font ainsi irruption en entreprise. Véronique constate que plus un homme est instruit, plus il est apte à prendre des décisions et que le potentiel de l'homme n'est révélé que lorsqu'il est effectivement responsable de ses actes. Elle note également que les employés ont besoin de sens, d'une vision partagée de leur oeuvre commune pour leur permettre de s'engager. Pour elle, le moteur de la performance est le plaisir pris au travail. Elle cite à cette fin des travaux de neurosciences qui semblent le montrer. Les individus sont naturellement agiles, encore faut il que leur environnement le leur permette. Veronique utilise par exemple le jeu des 6 chapeaux afin de permettre à une équipe d'exprimer différents points de vue sur ses problématiques, y compris la part émotionnelle. Elle définit des pistes pour refonder le rôle de manager. Un manager devrait nourrir la connexion à la tribu afin de nourrir le lien d'appartenance. Il devrait être un Servant Leader, manager au service de la performance de ses équipes. Il devrait également fournir le climat et les nutriments qu'il faut et laisser les gens pousser, grandir tous seuls. Il lui semble que la confiance coûte moins cher que le contrôle et que les entreprises feraient bien de faire leurs comptes sur toutes leurs procédures. Elle ajoute que le rôle d'un manager est également de prendre le temps de connaître les individus et de rassurer, communiquer, échanger et donner du feedback, surtout en temps de crise. Cela fait parti de ce que l'on appelle le Slow Management. Elle nous laisse avec une équation pour conclusion : Humanisme + agilité = succès.

Tuan Vo Vinh - 10 traps to avoid

Tuan Vo Vinh se propose de donner le retour d'experience qu'il aurait aimé voir il y a quelques années avant de se lancer dans les méthodes Agiles. Chef de projet à la SGCIB, il a mené deux grands projets durant ces dernières années et il constate que l'Agile n'a pas été la panacée qui a tout fait marcher comme par magie. Il liste en 10 points ses déboires et les leçons qu'il en tire :

Piège 1 "Arnaque sur la marchandise" ou "lorsqu'on achète une voiture on s'attend à ce que les portes s'ouvrent". Ses développements ont été émaillés de frustrations des Product Owners qui attendaient des fonctionnalités plus complètes qu'elles étaient et qui déploraient que de multiples détails présents dans une ancienne version n'étaient pas présents dans le nouveau logiciel alors qu'ils souhaitaient un développement à iso-fonctionnalité. Ces détails ne faisaient pas explicitement partie de leur demande mais ils auraient aimé qu'implicitement ils soient réalisés. Evidement il est très difficile pour les développeurs de savoir quoi faire si cela ne fait pas partie de la liste des exigences du PO. C'est le piège classique du développement à iso-fonctionnalité.

Piège 2 "Prime d'assurance".  L'Agile prend du temps. Tuan et ses équipes ont eu l'habitude de sprints de 3 semaines et ils comptent que 12hj sont dépensés à chaque sprint pour les différentes reunions, soit 200hj sur l'année, la charge complète d'une personne. Il note également un coût de "Over Quality" du fait de la volonté de ses équipes à bien faire. Au final tout semblait plus cher et obligeait à sans cesse retirer des fonctionnalités, érodant la confiance du client. Tuan recommande de bien anticiper le coût de l'Agile et de tenir compte des cérémonies dans le pricing.

Piège 3 "L'oubli de la vision". Tuan a mené un projet qui avait deux destinations mais où la seconde n'a réellement été mise en oeuvre que durant la seconde année de développement. Tout le monde l'avait un peu oublié en 1 an et son équipe a mis beaucoup de temps pour adapter le logiciel au second périmètre. "C'est bien beau d'aller à l'essentiel mais vos développements sont irréversibles" fait partie des réflexions auxquelles il a dut faire face. Il recommande de maintenir la vision dans le temps, notamment au travers de jeux tels que "Remember the future".

Piège 4 "in God we trust". Tuan constate que l'équipe accorde trop de confiance au Product Owner sur ses choix, oubliant parfois qu'il est faillible et qu'il peut se tromper. L'équipe pourrait challenger et proposer plus au Product Owner. Il avance qu'un bon sprint est lorsque le PO ressort frustré des kickoffs mais véritablement heureux des démos.

Piège 5 "L'engagement mou". Tuan a vécu beaucoup de sprints qui n'ont pas atteint leurs objectifs. Il rapporte que la première réponse qui ait été offerte était le bâton, si vous n'avez pas fini vous resterez plus longtemps... Sans gain constaté ils ont changé de stratégie pour passer à la carotte, si vous avez fini vous resterez moins longtemps... Jusqu'à ce qu'un développeur lui dise : "C'est bien beau mais je préfère ta considération à un bonbon". Tuan plaide pour un engagement partagé par toute l'équipe.

Piège 6 "Ne pas déranger". Avec une équipe agile vous pouvez changer d'avis et tout leur demander mais seulement entre les sprints. Que faire des imprévus en cours de sprint ? Une de ses équipes a eu tendance à ne pas prendre le risque d'être hors délai si ça n'était pas écrit dans les specs, au risque de faire des demos catastrophiques par ce que des cas limites venaient tout planter... Tuan pense que changer un sprint n'est pas échouer.

Piège 7 "Faire plaisir au client et oublier le reste". Il est toujours hasardeux de se reposer sur un seul indicateur de performance. Dans son experience le KPI qui faisait foi était la satisfaction client ou voice of the customer. Un client heureux ne fait il pas tout ? Tuan parle d'un effet de conspiration, le client était très heureux de l'équipe et l'équipe acceptait tout pour cela... jusqu'à indirectement provoquer un incident de prod à cause d'une connivence. Tuan insiste pour que les développements de briques techniques telles que le monitoring par exemple soient sanctuarisés.

Piège 8 "What You See Is NOT What You Get". Une demo ne prouve pas que l'application fonctionnera en production, à moins que les contraintes de la production ne soient appliquées à la démonstration. Cela est dévastateur pour la confiance en l'équipe. Pourquoi y a t il autant de bugs ? L'équipe est elle compétente ? Tuan constate qu'il a manqué de tests utilisateurs en permanence pendant chaque sprint.

Piège 9 "Army of clones". Comment récompenser la sur-performance des développeurs d'une équipe Agile ? Que faire lorsque l'un d'entre eux tire l'équipe vers le bas ? Tuan pense que au-delà du caractère collectif de l'équipe il faut avoir un dialogue un à un avec les développeurs.

Piège 10 "C'est pas pour les newbies". Scrum c'est simple à lire et à mettre en place, et pourtant la vraie vie est dure. Tuan recherche dans le soutien de prestataires et de la communauté des réponses à ses questionnements. Il montre l'exemple avec ce retour qui est loin de la traditionnel success story.

Sylvain François - Les tests et l'agilité : la vraie vie

Autre retour d'expérience, cette fois sur les aspects techniques du développement logiciel. Sylvain François travaille pour Kalistick, un éditeur français d'une solution de qualimétrie, SaaS innovation for agile QA. Kalistick sait associer à chaque test auto ou manuel le code source qui est invoqué par celui-ci, ce qu'il appelle l'empreinte du test dans le code. Cela leur permet, lorsque le code est modifié, de donner une priorité à l'exécution des tests. Lorsque ceux-ci sont longs ou coûteux à exécuter le gain est évident. Le propos de Sylvain est de démystifier quelques croyances en se basant sur le retour d'expérience des clients de Kalistick. Le premier mythe est celui selon lequel la phase de test est incontournable. Non sans avoir fait remarquer qu'un testeur est souvent dépeint comme un développeur raté, Sylvain raconte que la culture du test est très éloignée de la culture des équipes de développement, poussant l'analogie à dire que les testeurs viennent de Venus et les développeurs de Mars... Les clients de Kalistick trouvent l'automatisation des tests coûteuse et a tendance à ne la faire qu'à postériori. Ils sont ainsi bien loin du Test Driven Development. Sylvain note que les équipes QA ignorent parfois les tests développés par les équipes de développement, par manque de confiance ou de communication. On assiste au syndrome du fromage suisse, avec d'énormes trous de tests entre unitaire intégration et fonctionnel, ou un bug passe inaperçu. Le Graal de l'automatisation peut être vu comme la panacée mais l'automatisation des tests est difficile à créer et à pérenniser. L'équipe de développement doit la maitriser, or beaucoup ne s'y mettent pas vraiment et abandonne après avoir choisi et acheté l'outillage... Sylvain cite la mésaventure d'un très gros éditeur français qui à la nouvelle version majeure de son logiciel n'a implémenté aucun nouveau test sur 1 an le temps de migrer les anciens tests. A ce niveau les tests représentent pour eux du code à maintenir et donc une dette... Lorsque les tests automatiques sont faiblement validant les équipes peuvent perdre du temps parce que les testeurs sont monopolisés par l'analyse des résultats de tests auto ou être tenté de créer du logiciel qui automatise l'interprétation des tests... Certaines équipes zélées ont développés 70000 tests, qui évidement ne tournent pas durant les 2 semaines du Sprint. Consternante, la présentation de Sylvain montre bien l'écart entre objectifs et réalité, que tout tester est rarement un objectif valide et que pour une équipe faible techniquement automatiser ne solutionne rien.

Pierre Pezziardi - Fier d'être informaticien ?
Présenté dans la track développement, c'est de philosophie qu'est venu nous parler Pierre Pezziardi au travers d'un retour d'expérience sur son année passée à la tête de la  direction informatique de la Bred. Pierre s'interroge afin de savoir s'il faut être fier d'être informaticien. Dans les dîners en ville ce n'est pas forcément un moyen de briller en société que d'annoncer que l'on est informaticien. L'informatique c'est l'innovation à la Apple et Google mais c'est surtout dans le quotidien des gens devenu l'outil omniscient et incontournable de leur travail et, de ce côté là, l'informatique complique souvent la vie et promet beaucoup sans retour. Pierre constate que plus encore que l'essoufflement de la productivité c'est à un essoufflement de l'utilité que l'on assiste. L'informatisation des entreprises devait tout permettre, elle les a au contraire rigidifié. Derrière la scène tout est très stable, des systèmes informatiques perdurent des décennies, empêchant  toute transformation des processus. La norme est aux processus phasés et à la séparation penseur/faiseur, pas à l'intégration et au feedback. Pierre explique qu'une DSI typiquement organisée a toujours un conflit interne entre le service des études et le service de la production. En effet, les études veulent créer des nouveautés le plus rapidement possible alors que la production veut assurer la qualité et la stabilité du service. De plus, au bout d'une production il y a un service client qui n'est pas valorisé et qui peine a faire entendre ses besoins au service étude. À la Bred le service client traitait 120000 appels par an, dont 80% d'incidents, sans que ce service ne puisse faire plus que de constater les dysfonctionnements. Il eut fallu qu'un processus existe de manière à améliorer le logiciel sur la base des feedbacks. Pierre a ainsi baissé de 8% le nombre d'appels. Il a vécu beaucoup de résistance, beaucoup de personnes contre une réorganisation et surtout beaucoup trop de partisans du statuquo. Le rayon d'influence typique de l'agilité est dans l'étude alors qu'on doit choyer l'utilisateur... L'organisation pyramidale va a l'encontre des processus courts, la direction devrait être organisée par produits et pas par fonctions, en introduisant de l'Agile et du DevOps, mais ce type de changement lourd n'est pas possible si il ne vient pas des protagonistes eux mêmes. Pierre utilise une belle expression, il dit avoir "infligé une aide" à ses équipes, qui n'étaient simplement pas assez indignées pour accepter cette aide. Plus généralement, Pierre constate que l'informatique peut couler dans le marbre des règles qui détruisent de la valeur et ainsi rigidifier les organisations. Elle devient alors une sorte de bras armé de la bureaucratie. L'outil simple pauvre transparent est un homme serviteur, l'outil élaboré complexe secret est un maître arrogant. Des ERP renforcent par exemple le culte du contrôle des entreprises. Alors que faire en tant qu'informaticien ? Pierre affirme qu'il est très simple de s'améliorer sur ses points faibles et que nous serons fiers d'être informaticiens le jour ou nous ne serons plus uniquement informaticiens. L'informaticien de 2030 devrait par exemple être un peu banquier, un peu analyste, un peu exploitant. Pierre prévient dès à présent que ceux qui ne font pas cela seront en Inde ou en Chine... Au leitmotiv "Supprimer votre job, vous êtes promu" il incite les entreprises à valoriser celles et ceux qui ne respectent pas le statuquo et qui ne se barricadent pas sur leur expertise ou leur poste. Il plaide pour une entreprise où un pacte social permette aux employés et aux services de sortir des minima locaux pour créer bien plus de valeur.

Équipes de production ITIL et équipes de développement agiles comment bien travailler ensemble ?

Cette présentation devait être un retour d'expérience. Ainsi on a appris que deux équipes très différentes devaient collaborer et mieux communiquer pour être efficaces ensemble. On a également appris que ITIL est basé sur un système d'amélioration continu, orienté client, prône la collaboration mais que le change management est complexe et très orienté vers l'anticipation et l'analyse des problèmes. Une vision stratosphérique qui manquait cruellement de concret et m'a laissé sur ma faim.

Patrick Sarfati - Agilité, Cmmi et ISO, Compatible ou irréconciliable ?
Patrick Sarfati intervient auprès de grandes entreprises pour les aider à certifier leur développement logiciel. Agiliste convaincu, il cherche à marier la maturité et la rigueur des méthodologies traditionnelles aux valeurs et méthodes de l'Agile. Patrick revient sur l'histoire parallèle de CMMI et des méthodes agiles, l'une centrée sur le processus et l'autre sur l'équipe, tous deux présentant des buts communs. Alors que les entreprises embrassent depuis longtemps les standards tels que PMI ou CMMI, l'organisation Agile ressemble à une révolution. Patrick tente un sondage live et constate que dans la salle 80% utilisent un standard et Agile sans les coordonner. Il note que ce qui les rapproche le plus est le partage de la roue de Deming, le processus itératif Plan Do Check Act, comme Iso 9000 d'ailleurs. Il est tentant de se servir de Scrum ou des pratiques XP comme un panier ou faire ses courses en prenant ceci mais pas cela. Patrick avertit que ce type de démarche partielle ne mène à rien d'autre qu'une roue crevée incapable d'avancer. Il propose d'employer Scrum pour répondre aux exigences de CMMI 2 et XP pour répondre à celles de CMMI 3, sans dénaturer ces méthodes.  Il indique qu'il faut porter une attention particulière aux artefacts, garder les traces (snapshot du backlog, du code, des artefacts, estimation to complete) pour satisfaire certaines exigences de CMMI. Le mariage entre Agile et CMMI est en ce moment un souhait de l'organisation qui maintient CMMI, la version 1.3 de CMMI-DEV fait par exemple référence à l'Agile. Patrick pense que CMMI 5 peut être implémenté pour autant que l'on sache évaluer la maturité d'une organisation concernant Scrum. Partick interroge enfin l'avenir de l'Agile. Il parie que les processus empiriques ont de beaux jours devant eux tant la complexité des problèmes traités est croissante. Il pense que Scrum peut être vu comme une évolution, ajouter l'Humain aux méthodologies classiques. Patrick suggère aux agilistes d'ajoutez des outils de qualités et traçabilité à leurs pratiques. Il les prie surtout d'apporter les valeurs et principes Agile sans renoncer à rien. Il ne s'agit pas juste d'un exercice de mapping, de renommage des processus classiques ! 

Oana Juncu - Pratiques Agiles comme métaphore des techniques Lean
Oana Juncu nous plonge dans un atelier expérimental autour de la constitution d'un petit dictionnaire de pratiques Lean en traduction Agile. Au delà des intérêts que suscitent ces deux méthodologies elle interroge leur complémentarité. Ont elles des cibles différentes ? Agile est il réservé à l'équipe et Lean à l'organisation ? Sur le terrain quoi complète quoi ? Inspirée par les approches Clean Language qui ont cours en neurosciences, Oana explique que nous utilisons tous des métaphores inconscientes pour décrire des concepts inconnus ou complexes avec des concepts connus et simples, par analogie. Elle fait ainsi un premier parallèle entre la notion Agile de Definition of Done et la notion Lean de Value Stream Mapping. À première vue ces deux notions peuvent paraître ne rien avoir en commun. Oana explique pourtant que la Definition of Done devrait être élaborée à partir des contraintes aperçues en parcourant la chaîne de valeur. Oana poursuit en avançant que la démarche Agile de Story Mapping est comme un voyage dans le comportement de l'outil, similaire à un Gemba Walk, une démarche Lean aussi appelée Go and See qui consiste à aller sur le terrain, à être au bon endroit pour observer. Elle nous propose un  exercice de groupe à ce sujet. Prenant pour exemple la creation d'une application à destination des visiteurs de l'Agile Tour, elle invite la salle à former des groupes et à lui proposer des User Stories et des contraintes en faisant l'exercice de visiter mentalement l'application à construire. D'abord un peu médusée, la salle a joué le jeu, se posant la question "Un utilisateur face à cette app, il fait quoi ? ça veux dire qu'il faut que je prévois quoi pour faire l'appli ?" et surtout en construisant les stories pas à pas. Une session riche mais pas forcément facile à appréhender.

J'ai ensuite séché la dernière session pour rester discuter dans les halls alors que la nuit avait déjà dévoré les exterieurs du centre de conférence.
crédit photo : Stéphane Bagnier

Aucun commentaire:

Enregistrer un commentaire