[Agile France 2014] Projets Agile : Arrêtez les dérives !

logo

Cette année encore, c’est au milieu du bois de Vincennes, plus précisément au Chalet de la Porte Jaune, que s’est tenue l’édition annuelle de l’Agile France. Histoire de commencer sur des bonnes bases, j’ai décidé d’assister à la présentation de Cyrille Deruel, qui propose d’exposer les bonnes et les mauvaises pratiques rencontrées sur une dizaine de projets Agiles. Inspiré par l’exposition Star Wars Identities, Cyrille nous invite donc à suivre son évolution sous la forme de sa propre trilogie.

“Avant, je faisais du Waterfall. Mais ça, c’était avant”, ainsi commence cette présentation. En effet, Cyrille était avant chef de projet Waterfall. Et en 2008, différencier un projet Agile d’un projet Waterfall n’est pas chose simple. L’évolution s’amorce…

Les dérives de l’adolescence

Pour mettre en avant les bonnes pratiques, Cyrille agrémente chacun de ses slides d’une anti-pratique courante. Ainsi, on reprend les bases du plus aisé au plus avancé, et tout démarre donc par cette cérémonie que nous connaissons tous : le Stand-up. Il nous rappelle donc qu’un bon stand-up se doit d’être énergique, rapide, dynamique et, à terme, auto-organisé. L’idée est de rappeler les objectifs et non de faire un rapport militaire à quelque autorité supérieure. Vient ensuite le Planning Game, où le Product Owner a déjà chiffré toutes les User Stories et personne n’ose porter un avis différent, faisant perdre tout son intérêt à l’exercice. Cyrille nous rappelle donc que le Planning Game a pour but de synchroniser l’équipe sur ce qu’il reste à faire, les points difficiles qui s’annoncent, ainsi que les enjeux du sprint.

Stormtroopers-365-What-Do-Stormtroopers-Do-On-Their-Day-Off-0Cyrille continue son exploration des cérémonies et nous parle de la Démonstration. Quel meilleur moment pour le chef de projet que celui où il peut mettre les développeurs en avant pour leur faire porter la responsabilité de tout échec ? Pourtant, le but n’est encore une fois pas du tout là, puisqu’il s’agit d’obtenir du feedback de la part des utilisateurs et du PO, de valoriser le travail réalisé et d’en profiter pour échanger et discuter pour réaliser au mieux les objectifs du produit. Cette réunion est donc vouée à être co-animée par les développeurs et le PO, pour apporter à la fois la vision technique et la vision fonctionnelle. Sans grande surprise, la Rétrospective a droit à son anti-pratique : la rétrospective forcée. Car en effet, parmi toutes les cérémonies, c’est celle qui demande le plus d’implication des participants, et une rétrospective mal organisée tourne rapidement en tribunal, où les absents se retrouvent fréquemment sur le banc des accusés. Elle doit donc être préparée et timeboxée pour éviter les dérives. On s’efforcera d’énoncer les faits et d’identifier ce que l’on veut améliorer, dont découlera un plan d’action pour l’itération à venir. Un point important souvent négligé est le fait de clôturer cette réunion en remerciant les personnes présentes et en envoyant un compte-rendu qui servira à rappeler les engagements lors de la prochaine rétrospective.

L’adolescence de notre jeune padawan se termine sur l’utilisation du management visuel, si souvent détournée pour contrôler ce que fait l’équipe. Une fois de plus, l’objectif est tout autre, puisque les burndown chartstaskboards et autres indicateurs sont là pour afficher les problèmes, partager des informations et stimuler l’amélioration continue au sein de l’équipe.

Le début de l’âge adulte

A mesure que les projets avancent, on a tendance à oublier l’aspect technique de ceux-ci, laissant ainsi s’enclencher cette bombe à retardement que l’on connaît tous : la dette technique. Ainsi, Cyrille nous présente un concept qu’il a rencontré et expérimenté par le passé : la TechTro, une rétrospective technique, qui permet de se focaliser sur des problématiques telles que la gestion de cette dette, de générer un plan d’action quant à sa maîtrise, ainsi que de mettre en avant les points rencontrés au cours des revues de code. Il ajoute qu’un projet sans sensibilisation technique est toujours risqué et que chaque acteur doit comprendre à minima ce que représente la dette technique.

dark-vador-wallpaper

Cyrille nous parle ensuite d’un rôle qui est souvent bien trop exploité : le Product Owner. En effet, on a tendance à croire en sa toute-puissance, et donc à penser qu’il est capable de tout faire tout seul et que chaque problème peut lui être confié. On attend de lui qu’il porte la vision produit, qu’il puisse arrêter un sprint en cours, qu’il connaisse le client ou encore qu’il soit responsable du budget. Pourtant, loin d’avoir ces attributions, le PO est souvent surchargé, ce que Cyrille nous conseille d’éviter à tout prix. A l’inverse, il nous encourage à l’aider et le faire seconder par une équipe PO pour assurer toutes ses responsabilités. Le Product Owner est la personne-clé du projet agile.

Dans la suite logique de cette exploration des concepts de l’Agilité, on parle ensuite de User Story. Fort de ses deux ans de coaching, Cyrille fait un constat éloquent : aujourd’hui, tout est considéré comme une User Story. On voit donc apparaître des US Techniques, des US Bugs, et on en oublie le véritable objectif : apporter de la valeur à l’utilisateur. Ainsi, si l’utilisateur veut traverser la rivière, la User Story associée sera “Je veux traverser la rivière” et non pas “Je veux un pont” ou “Je veux une barque”. Il ne faut donc pas oublier que les US doivent être en adéquation avec le principe INVEST.

En Agilité, on parle souvent d’équipe auto-organisée, et on en vient à négliger le fait qu’au démarrage, l’équipe a besoin d’être guidée. En effet, avant qu’elle soit auto-organisée, il faut lui avoir montré comment faire et l’avoir accompagnée, avant de lui faire confiance et de la laisser se débrouiller. Un point très important de cette étape est la responsabilisation de l’équipe. En effet, une équipe peut s’auto-gérer sans pour autant se sentir responsable des résultats de son projet, entraînant une potentielle désinvolture quant à la qualité des livrables.

Cyrille en vient à un point important dans l’utilisation des flux : il faut toujours finir ce qui a été commencé. En effet, l’objectif étant de donner de la visibilité aux objectifs et de mesurer en continu, il faut mettre en évidence les points douloureux, tester au fil de l’eau et découper les transitions en étapes. Il agrémente cette explication d’une analogie bien choisie : imaginez un parachutiste qui se prépare à sauter, saute, fait ses acrobaties dans les airs, se stabilise… et décide de s’arrêter à l’étape précédant l’ouverture du parachute. Explicite, n’est-ce pas ?

lightsaber-hula-oops-randy-turnbow

Souvent, on a tendance à penser que, parce que ça marche sur notre environnement de développement ou d’intégration, ça marchera forcément en production. Pourtant, mettre en production est une étape indispensable dans un projet. En effet, cela permet de changer la façon dont est pensé le produit, puisqu’il est à présent confronté à l’utilisateur réel et que ce sur quoi nous avons travaillé va enfin être éprouvé en conditions réelles, quitte à remettre en cause les décisions prises.

Cyrille revient ensuite sur la rétrospective, qu’il avait déjà évoquée lors de sa période adolescente. Cette fois-ci, les bonnes pratiques sont précises et constituent un plan d’action en elles-mêmes, avec un mot d’ordre : ne jamais oublier les actions sur lesquelles on s’est engagé à la rétrospective précédente. Les actions doivent être suivies et mesurées, au même titre que les objectifs. Cyrille nous conseille donc de nous limiter à 3 actions ouvertes simultanément et de supprimer les actions obsolètes : une action qui n’a pas été traitée après une période de temps conséquente ne découle pas d’un véritable problème ou n’est pas solvable dans l’immédiat, elle ne fait donc que polluer plan d’action.

4-tourist-stormtrooper

Les débuts de l’âge adulte se terminent sur la mise en lumière de deux profils rencontrés fréquemment face à un problème : les plaignants et les touristes. Les plaignants sont ces personnes qui vont trouver toutes les excuses possibles pour justifier un problème, tant que ce n’est pas de leur faute. Les touristes à l’inverse sont ces personnes qui vous répondront qu’il n’y a pas de problème, qu’il y en ait un ou non. Cyrille nous propose de transformer ces deux profils en clients du problème, en trouvant un problème qui les concerne et en les impliquant. La résolution du problème en question devra donc se faire avec eux, pour les motiver à se pencher sur les prochains problèmes qui apparaîtront.

Les premiers pas vers la sagesse

Fort de son expérience, Cyrille nous a préparé trois patterns composés de bonnes pratiques à utiliser sur nos projets.

Le Produit

  • Livraison en production : confronter le projet aux conditions et aux utilisateurs réels
  • Itérations parlantes : adapter la taille des itérations au contexte du produit
  • Tests automatisés : automatiser les tests permet de s’assurer de la qualité des livrables tout au long de la vie du produit
  • Feedbacks : obtenir des feedbacks permet de développer un produit conforme aux attentes des utilisateurs
  • Rencontrer les utilisateurs : aller voir les utilisateurs du produit permet d’avoir des retours directs de leur part et de comprendre leurs problématiques

Le Processus

  • Essayer : faire des essais permet de découvrir de nouvelles façons de faire les choses, potentiellement plus rentables
  • Mesurer : les indicateurs permettent de savoir où en est le projet à tout instant et de lever des alertes au bon moment
  • Système apprenant : le fonctionnement de l’équipe produit n’est pas gravé dans le marbre et doit évoluer au fur et à mesure de la vie du produit
  • “Qu’avons-nous appris ?” : revenir sur ce qui a été appris et en tirer les leçons qui  permettront de s’améliorer
  • Feedbacks à tous les niveaux : obtenir des feedbacks à toutes les étapes du processus permet de s’améliorer à tout point de vue

Les Personnes

  • Communiquer : la communication a un rôle capital dans le fonctionnement d’une équipe produit. Bien s’exprimer est tout aussi important qu’être capable d’écouter, de comprendre et de se faire comprendre des autres acteurs du projet.
  • Accepter de ne pas savoir : il est plus avisé d’accepter de ne pas savoir plutôt que de persévérer à l’aveugle
  • Accepter d’apprendre : les acteurs de l’équipe produit ont tous à apprendre les uns des autres
  • Accepter les erreurs : comme pour les essais, les erreurs peuvent mener à des découvertes, il ne faut donc pas avoir peur d’échouer, dans la mesure du raisonnable

Voici donc trois patterns issus de sa propre expérience. Et comme Cyrille est sympa, il nous donne quelques lignes directrices pour que l’on sache par quoi commencer dès demain !

  • Travailler et apprendre des utilisateurs finaux
  • Apprendre en essayant, en testant et en ajustant notre fonctionnement à ce que l’on a appris
  • Communiquer au mieux dans l’équipe produit

Ainsi donc se termine cette première session très intéressante de l’Agile France, qui m’a apporté beaucoup de conseils et d’idées sur ce qui peut être mis en place sur ma mission actuelle. En soi, rien de nouveau sous le soleil, et pourtant ce sont tous les petits détails que Cyrille nous a exposés qui m’ont fait ressortir de cette présentation avec une certaine impatience de pouvoir mettre en pratique.

Vous pouvez retrouver les slides de la présentation, sur le slideshare de Cyrille.

Nombre de vue : 72

COMMENTAIRES 1 commentaire

  1. Fred dit :

    Excellent

AJOUTER UN COMMENTAIRE