AGILE NOT WORK

L’Agilité est devenu un terme galvaudé, utilisé pour décrire des situations de fuite de méthodes traditionnelles jugées comme trop lourdes. Du fait de sa simplicité apparente, elle est souvent implémentée rapidement, et des échecs voient le jour avec leur lot d’explications: “C’est parce que notre métier est trop spécifique”, “On a essayé mais tout le monde a rejeté Scrum”… La valeur de l’Agilité et ses implications sont alors mises à mal par des croyances et des préjugés. Et si nous les passions en revue?

L’Agilité? Trop compliqué à mettre en place…

La méthode Scrum par exemple est simple à mettre en place et peut se faire au fur et à mesure des Sprints. Ce qui est compliqué c’est de faire en sorte que les valeurs Agiles soient bien comprises par les équipes.

La documentation, ce n’est pas Agile, alors on n’en fait pas.

Si le manifeste Agile précise qu’il faut une application fonctionnelle plutôt qu’une documentation exhaustive, il n’est certainement pas déconseillé de produire de la documentation si celle-ci peut permettre à l’équipe de répondre aux besoins des utilisateurs.

D’ailleurs, les user stories bien rédigées sont une documentation vivante en elles-même. Leur raffinement met en lumière:

  • le résultat: qui utilisera la fonctionnalité, de quoi elle parle et pourquoi elle est nécessaire
  • sa valeur: ce qui est délivré sur le marché en termes de valeur business et d’expérience utilisateur

Elle contient également des informations concernant :

  • Les critères d’acceptation: la différence entre « cela fonctionne comme on l’a codé » et « cela fonctionne comme attendu »
  • Le contexte dans lequel la fonctionnalité est destinée à être utilisée pour atteindre son plein potentiel
  • Les hypothèses, propriétés critiques ou assomptions qui rendent la user story vérifiable, ou qui causeraient des problèmes si fausses

En d’autres termes, une bonne utilisation des user stories permet de mutualiser le travail de raffinement du produit, ce qui facilite la vie de l’équipe de développement en même temps qu’elle permet la rédaction d’une documentation exhaustive et efficace.

L’Agilité permet de changer à sa guise les priorités de développement

Chaque Sprint possède un objectif, appelé le Sprint goal. Il est là pour définir une priorité, une ligne directrice qui permettra à l’équipe de se concentrer sur l’essentiel d’abord. Il permet de focaliser les efforts fournis par l’équipe afin de garantir une opportunité de livraison d’un incrément de valeur sur le marché à la fin d’un cycle.

Changer cette priorité en cours de Sprint occasionnera un coût de « context switching » et diminue la valeur que l’équipe arrivera à produire. En revanche, les priorités pourront être revues à chaque Sprint review sur la base des enseignements des Sprints précédents ainsi que de la démo. En fin de compte, chaque Sprint est une opportunité de réaligner les priorités de développement pour le Sprint suivant.

L’Agilité permet de livrer à chaque fin de Sprint

Un des cadrans de la roue de Modern Agile stipule: livrer de la valeur en continu. Cela n’est possible que si on met en place auparavant une démarche de livraison continue. Si ce n’est pas fait, alors les mises en production viendront perturber les Sprint suivant à cause de la quantité de travail nécessaire, parasitant la capacité de l’équipe.. De plus l’objectif, qui est de délivrer régulièrement de la valeur métier, ne pourra pas être tenu.

L’Agilité est une méthode bien cadrée

L’Agilité est en fait un ensemble de valeurs autour desquelles des professionnels s’accordent à travailler ensemble. Il s’agit d’une culture de la transparence, de la communication, de la bienveillance et de la réduction du gaspillage. Certains frameworks, des cadres de travail, basent leurs règles sur ces valeurs. C’est le cas de Scrum, qui n’est qu’un des nombreux framework existants dans un paysage Agile bien plus vaste, comme l’illustre Chris Webb:

L’Agilité peut s’appliquer à tous les types de projets

Dans l’industrie, la méthode Kanban peut être un outil puissant de production « just in time », et reste Agile. Un projet de déploiement peut également être mené en ayant en tête les valeurs Agiles. Il est alors question d’expérimenter des hypothèses sur un échantillon contrôlé en se basant sur une version minimale de notre environnement, et si elles sont validées d’alors aller plus loin dans le déploiement par incréments (Blue/Green deployments par exemple).

En revanche, il y a des domaines où il est effectivement plus compliqué de fonctionner par incréments, comme par exemple la construction. Difficile d’imaginer un pont construit par morceaux utilisables, alors que c’est particulièrement adapté pour un projet de développement logiciel par exemple.

Connaître le cadre de la méthode Scrum, c’est comprendre l’Agilité

Il est important que les personnes aient lu et compris le manifeste Agile avant de se lancer dans l’implémentation d’un cadre Scrum. Chaque “cérémonie” Scrum possède une valeur intrinsèque liée aux principes Agiles. Si cette valeur n’est pas comprise alors cela conduit inévitablement à des dérives.

L’Agilité permet d’améliorer la productivité

Lorsque l’on parle de productivité, on parle en fait d’une quantité produite par rapport à l’effort fourni. L’Agilité va mettre l’accent sur l’efficacité et la qualité. Plutôt que de se concentrer sur l’augmentation de la quantité produite par une équipe, l’Agilité permet d’optimiser la valeur délivrée par l’équipe pour une même quantité d’effort. L’équipe devient alors plus efficace en terme de qualité et livre des fonctionnalités utiles.

Dès que les problèmes de projet surgissent, il est facile d’incriminer les méthodes Agiles.

L’Agilité encourage la transparence et la communication. Cela signifie qu’elle permet aux problèmes de surgir et de mieux les remonter. Pour autant leur résolutions reste à la charge des équipes, car les problèmes liés à l’organisation ou à l’humain sont leurs responsabilités.

Chaque Sprint est une course où il faut tout faire pour finir chaque User Story dans les temps

Chaque sprint possède un Sprint goal, permettant de déterminer le succès ou l’échec d’un Sprint. Si le Sprint goal est atteint mais que les user stories ne sont pas toutes terminées, cela signifie que l’équipe à su se concentrer sur les priorités business, et maximiser la valeur qu’elle est capable de délivrer sur le marché, ceci sur un rythme de travail soutenable pour toute l’équipe sous peine de détériorer la qualité du travail.

Un constat tel que des user stories non complétées doit raconter une histoire. Cette histoire permet alors de comprendre ce qui a empêché l’équipe de les terminer, et donc de s’améliorer.

De ce point de vue, un Sprint n’est pas une course mais une opportunité d’amélioration.

Un des buts cachés de l’Agilité est de permettre de contrôler tous mes faits et gestes

(façon de travailler, temps de travail, daily meeting etc.)

L’Agilité est basée sur la notion de confiance, toute l’équipe se tourne vers un même objectif : produire le maximum de valeur métier pour les utilisateurs. Si la confiance n’est pas là alors les personnes ne vont plus travailler en équipe. Une mauvaise utilisation de frameworks comme Scrum peut donner cette sensation (cf. « Dark Scrum », par Ron Jeffries).

Pour être productif dans une équipe, il faut connaître la vélocité de chaque membre de l’équipe

Scrum définit la vélocité comme un indicateur relatif et non comme un indicateur de productivité, il a pour but d’aider l’équipe de développement lors des phases de planification de sprint. C’est un outil de prédictibilité. Plus l’équipe gagne en expérience, plus elle est capable de projeter une vélocité réaliste. Cela permet la planification, mais n’est en aucun cas un indicateur de productivité.

Faire de l’Agilité amène à faire plus de réunions

En Scrum toutes les réunions sont timeboxées pour éviter de faire perdre du temps aux participants. Les différentes cérémonies Scrum (Sprint Review, Rétrospective et Sprint Planning) n’ont lieu qu’à chaque fin ou début de Sprint et pendant le Sprint les seules réunions obligatoires sont les Daily Meeting de 15 minutes maximum qui ont lieu quotidiennement pour l’équipe de développement. Ils ont pour unique but d’être une opportunité pour l’équipe de développement de partager leurs bloquants, et ainsi permettre d’obtenir l’aide dont ils ont besoin.

En dehors de Scrum, les valeurs de transparence et de confiance sont là pour réduire les réunions et éliminer le gaspillage. De ce point de vue, la plupart des réunions n’existent que pour combler un manque de communication et de partage d’information. Si ce manque est comblé par un accroissement de la transparence, alors ces réunions disparaîtront organiquement.

Les parties prenantes ne font pas partie de l’équipe Agile.

Dans le cadre de Scrum, si elles ne font pas partie de l’équipe les parties prenantes jouent pourtant un rôle déterminant. Ils donnent leur feedback lors des revues de Sprint, peuvent être amenés à collaborer directement avec les membres de l’équipe, et entretiennent une relation étroite avec le Product Owner.

En Agilité il n’y pas de planning

Un des principaux avantages est d’avoir une planification plus précise qu’en cycle en V puisque réestimée continuellement. Cette planification correspond à la RoadMap du projet et permet d’avoir une estimation de la date de prise en charge des principales fonctionnalités par l’équipe. Il est important de comprendre que cette RoadMap n’est pas figée et qu’elle évolue constamment.

En fin de compte, une approche Agile permet de disposer d’un calendrier réaliste ajusté régulièrement en fonction de l’expérience, par opposition à un planning basé sur des hypothèses invérifiables.

La méthode Agile KANBAN n’est qu’une méthode Waterfall avec un tableau visuel en plus.

Dans son modèle de boucle de feedback, waterfall n’offre d’opportunité de changement qu’après la phase de développement du produit.

La méthode Kanban quant à elle découpe le développement de ce produit en unités de valeurs minimales, les cartes. Au travers de ses artefacts spécifiques (tableau visuel, mais également: WIP Limit, Releases, définition des états, etc.) Kanban vise à réduire au maximum la boucle de feedback en optimisant le flux de valeur. Le time to market de chaque carte est ainsi réduit, offrant les enseignements nécessaires pour ajuster le développement des futures cartes.

Dans les méthodes Agiles, on continue de faire les estimations en jours/hommes.

Les estimations en jour/homme permettent de connaître le coût d’une fonctionnalité, rien de plus. Non seulement elles sont absolues mais ne donnent aucune notion de valeur ou de complexité.

Une story, lorsqu’elle est estimée ou planifiée, n’appartient à personne en particulier mais à toute l’équipe. Tous les membres de l’équipe ne prendront pas le même temps à réaliser la story, mais la valeur livrée restera pourtant la même peu importe qui l’a réalisée.

Les estimations en points sont relatives entre elles. Elles sont donc basées sur l’expérience, et sont issues d’un consensus au sein de l’équipe de développement. Une estimation en jour/homme ne prend pas en compte l’apprentissage de l’équipe, ses challenges ni la complexité relative du travail à réaliser.

Le Product Owner décide seul du périmètre de chaque Sprint

Même si le Product Owner planifie les User Stories qu’il identifie comme prioritaires pour les prochains Sprints, il doit discuter avec l’équipe du contenu final. Un Sprint backlog appartient à l’équipe de réalisation, c’est elle qui s’engage à terminer le travail planifié il lui appartient donc d’en accepter un contenu en lien avec les priorités business expliquées par le Product Owner.

Les Scrum Masters sont des chefs de projets Agiles

Le Scrum Masters ne doit pas avoir un rôle de leader comme l’a un chef de projet. Il est là pour lever les obstacles qui peuvent barrer la route de l’équipe de développement, faciliter le travail et permettre au Product Owner de piloter l’équipe de réalisation par le métier et la valeur business.

Le Scrum Master n’est pas une secrétaire ou un baby-sitter.

Le Scrum Master est là pour l’équipe (servant-leader), pour lever les obstacles. Mais les membres de l’équipe doivent comprendre et apprendre à devenir autonomes et polyvalents, et le reste du management doit quant à lui faire confiance et ne pas demander rapports sur rapports.

En méthodes Agiles, se tromper n’est ni permis, ni excusable dans un projet.

Le droit d’erreur est permis, cela permet aux individus de s’améliorer progressivement. Justement le fait de fonctionner de manière itérative permet qu’une erreur sur un Sprint de 3 semaines ait des conséquences minimes. Par ailleurs, un des quatre cadrans de la roue de Modern Agile propose d’expérimenter et d’apprendre rapidement. Cela passe par l’acceptation du risque d’erreur, pour autant que ces erreurs permettent de retirer des enseignements.

En Agilité on néglige la qualité au profit de la vitesse de réalisation

La qualité est une variable qui doit être négociée entre l’équipe de développement et le Product Owner. Si le Product Owner demande à ce que l’équipe développe plus vite, il faut qu’il soit conscient que cela va faire automatiquement baisser la qualité du code et donc potentiellement produire des anomalies.

Une méthode Agile doit être encadrée et suivie scrupuleusement.

L’Agilité est une culture et un ensemble de valeurs plus qu’une méthode préceptive. Si nous parlons de méthode, alors elle doit être souple et emprunter des pratiques de d’autres méthodes Agiles. Scrum et Kanban sont des cadres de travail, il appartient à chacun d’appliquer ses préceptes selon le contexte de travail.

L’Agilité coûte plus cher que les projets en cycle en V

Effectivement les méthodes Agile peuvent coûter plus cher mais elles permettent de produire plus de valeur métier pour une même quantité d’effort. Elle peut également être plus rentable, dans le sens où ce qui est livré sur le marché à un plus fort potentiel de retour sur investissement.

Par ailleurs, il arrive que l’Agilité permette au contraire de réduire certains coûts puisque ne sont développées que les fonctionnalités que l’expérience a démontré comme utiles et/ou attendues.

Les méthodes Agiles ne permettent pas d’avoir un budget maîtrisé

Les méthodes ne permettent pas de savoir quelle sera le budget alloué pour produire une liste définie de fonctionnalités pour une date donnée. Le but est de produire le maximum de valeur métier pour un budget donné au fur et à mesure des Sprints.

Seule la Scrum Team doit être formée à l’Agilité.

Si il est effectivement nécessaire de former l’équipe à l’Agilité, il l’est tout autant de former les parties prenantes et les experts métier pour qu’ils comprennent bien leur rôle et ce que l’équipe attend d’eux. Le but étant de gérer les attentes de chacuns, il est également important de convaincre les couches managériale de laisser à l’équipe Scrum ou toute autre équipe Agile l’autonomie nécessaire au succès de l’implantation de l’Agilité.