Vous vous souvenez des 4 valeurs agiles?

Même si on va prendre SCRUM en example, les autres méthodes agiles partagent les mêmes principes fondateurs. Ces principes changent les façons classiques de travailler et l’organisation de ce travail. Ils sont très forts si on cherche à les suivre, même s’ils peuvent paraitre triviaux. Passons-les en revue et identifions les impacts qu’ils génèrent.

Principe n°1: Individus et échanges plus que processus et outils

Avant d’entrer dans les détails, juste un retour sur les 3 rôles principaux formant la Scrum Team:

• le Product Owner, responsable d’orienter le développement en fonction des besoins des utilisateurs ou clients
• la Development Team, responsable de tout le cycle de production pour aboutir à un produit fonctionnel (livré par itérations) y compris l’architecture, les développeurs, les testeurs, etc
• le Scrum Master, chargé de l’adoption de la méthodologie dans l’équipe et dans l’entreprise

Ce principe a de nombreuses conséquences. Tout le monde s’accorde à dire que les personnes travaillent mieux ensemble quand elles sont en immersion et en présence les unes avec autres. De fait, Agile déconseille le travail à distance et les équipes délocalisées. Bien sur, il y a la vraie vie; mais c’est une raison majeure de dysfonctionnement dans les équipes de développement.

Ceci amène à une structuration différente des équipes travaillant en agile: elles doivent travailler ensemble, physiquement, et pour obtenir le maximum d’efficience, elles doivent être autosuffisantes. On entend par là être en mesure :

• de résoudre elle-même les problèmes liés au développement (techniques, architecturaux, de performance, etc)
• de s’auto-organiser pour atteindre ses objectifs (en gérant elle-même sa composition et son planning par exemple)
• de négocier les objectifs des Sprints avec le Product Owner
• d’organiser ses Sprints de façon autonome
• d’améliorer sans cesse ses compétences et sa performance

Autre conséquence liée à l’autonomie de la Development Team: elle n’a pas besoin de manager. C’est aussi pourquoi le Scrum Master n’est pas un manager mais un leader; SCRUM entends par là qu’il mène une mission d’accompagnement et de facilitation; pas hiérarchique.

Principe n°2: Produit fonctionnel plus que documentation pléthorique

Cela ne veut pas dire: pas de documentation bien entendu. Mais cette documentation se déplace et change de forme. Le code doit être auto-portant pour permettre aux équipes de développer efficacement et de partager son code en cas de turn over. Les modes opératoires se transforment en vidéos d’utilisation mettant en situation l’utilisateur du développement. Comme l’agilité repose sur l’implication des utilisateurs (dans le grooming ou progressive refinement et dans les Sprint Reviews), les utilisateurs voient avancer le développement et se l’approprient mieux.

L’idée de « produit fonctionnel » amène aussi la question de la qualité des développements. En effet, le produit livré, même itérativement à la fin de chaque Sprint, doit être terminé et utilisable. Ceci pose la question de ce qui est « terminé » (en production? Sans bugs? Avec un nombre de bugs acceptable? Après le support de formation?). Ceci amène aussi le besoin de livrer un produit de qualité: il n’y a pas pire qu’un produit buggué passé en homologation aux utilisateurs.

Principe n°3: Collaboration du client plus que négociation du contrat

Bien sûr c’est une des dimensions fortes des méthodes agiles: on cherche à éviter les effets tunnel. Tout le monde a vécu les problèmes d’interprétation de diverses équipes qui se transmettent des informations par documents interposés. Le meilleur moyen de se comprendre c’est de se parler, pas de s’écrire (cf la littérature pléthorique sur la communication verbale/non verbale/gestuelle etc).

Il est aussi très difficile de préciser le périmètre d’un développement applicatif ex nihilo: qui est capable de spécifier sur 100 pages les besoins détaillés en début de projet, alors que les idées ne sont pas toujours très claires au moment du lancement? Personne. Il est bien plus efficace de co-construire les livrables et de faire des boucles de rétro-action courtes. Seeul le client/utilisateur peut dire ce dont il a envie, et le lui montrer est le meilleur moyen de lui faire exprimer. Montrer souvent, c’est avoir des retours fréquents.

Ce point pose la question de la durée des Sprints: un mois tel que préconisé par SCRUM. C’est à régler selon les projets mais la durée des Sprints ne peut pas être modifiée (perte d’efficience et déstabilisation). La bonne durée est à fixer en fonction de la capacité à produire de la Development Team et de son besoin d’obtenir des retours.

Principe n°4: Réactivité au changement plus que suivi d’un plan

Enfin, un dernier principe très fort: droit à l’erreur, mais une erreur rapide. Fail but fail fast. Avec le développement classique le tunnel peut durer plusieurs mois; en agile c’est au maximum un Sprint. En agile, le changement c’est le moteur de la méthodologie; les Sprints sont des outils pour rebondir sur les changements.

Le fonctionnement par Sprint pose quand même la question de la planification car agile ne veut pas dire aucune planification. Deux aspects: en début de Sprint on a bien un évènement qui s’appelle « Sprint Planning », mais dont la portée n’excède pas le Sprint qui vient. La planification plus long terme s’articule autour de la gestion des releases mais elle ne répond pas au besoin de planification d’un projet de développement long. Vous trouverez dans un article précédent une discution sur la problématique de la planification et de la visibilité pour les instances dirigeantes d’un projet de développement agile.

Ces différents principes, si on cherche à les implanter effectivement, bouleversent les habitudes de pilotage classique des projets de développement: les respecter est important pour la réussite d’un projet de développement agile.