Pièges de l'Agile - n°1: l'Agile à Distance
Tranches de vie
Voici un extrait d'une conversation sur un projet Agile A, en fin d'itération, entre les Développeurs et le Product Owner:
Développeur: … et donc on revient à la liste des annotations.. Product Owner: Ah oui, j'ai une remarque: c'est un peu gênant cette boite de dialogue, "voulez-vous sauver vos annotations ?", à chaque fois qu'on change de fenêtre. - Oui, mais si l'utilisateur ne revient pas sur la fenêtre des annotations avant longtemps, et qu'un problème réseau survient.. - C'est plutôt l'exception, ça. Vous ne pouvez pas sauver automatiquement son travail ? - Ça n'est pas demandé dans la story. On a fait au mieux, et ça nous a pris du temps.. - Il aurait fallu me poser la question ! - Tu n'étais pas disponible au téléphone.. - Bon. Qu'est-ce qu'on peut faire ? - Tu écris une autre story..
Voici un extrait d'une autre conversation sur un autre projet Agile B, pendant l'itération, entre les Développeurs et le Product Owner.
Développeur: Tu peux venir voir l'écran des annotations cinq minutes? Product Owner: J'arrive. - Donc, on a saisi des annotations, ici, et puis là.. - Ok. - Et on change de fenêtre pour aller sur la partie activité. - Cool! - Mais qu'est-ce qui doit se passer avec les annotations saisies? - Qu'est-ce que tu veux dire? - Elles vont être perdues si l'utilisateur ne revient pas dans la fenêtre des annotations et qu'un problème réseau survient.. - Elles se sont pas enregistrées au fur et à mesure? - Pour l'instant non, mais on peut faire ça en effet. - Excellent!
L'effet distance
Il y a une différence majeure entre le projet A et B. Vous devinez laquelle? Gagné: Dans le projet A, les Développeurs et le Product Owner travaillent sur des sites distants, dans le projet B, ils travaillent dans le même espace. Lorsque le Product Owner d'un projet Agile ne passe pas le plus clair de son temps à portée de voix des développeurs, cela induit plusieurs effets néfastes :
- Les Développeurs travaillent plus longtemps sans retour d'information du Product Owner, et réciproquement;
- Les Développeurs interrompent des tâches parce qu'ils attendent des informations de la part du Product Owner;
- Les Développeurs reçoivent quantitativement et qualitativement moins de retours d'information sur ce qu'ils construisent;
- Product Owner et Développeurs ont plus d'échanges en différé et moins de conversations devant le tableau blanc ou devant un écran du logiciel en cours de construction;
- Les corrections et les expérimentations coûtent plus cher;
- Les demandes de changement sont plus tardives, plus difficiles à recevoir et à négocier;
- Les Développeurs et le Product Owner passent plus facilement de la confiance à la défiance;
- Les demandes de changement sont plus tardives, plus difficiles à recevoir et à négocier;
- Les Développeurs et le Product Owner ont moins d'occasion d'exprimer ce dont ils ont besoin;
- Les Développeurs et le Product Owner développent des stratégies distinctes, voire concurrentes pour répondre à leur besoin.
En résumé, l'Agile à distance, c'est la recette parfaite pour réduire la qualité et la fréquence des retours d'information.
Pourquoi se séparer ?
Sur le papier — dans les livres — c'est évident: le Product Owner et les développeurs doivent être colocalisés. Dans la plupart des entreprises, pourtant, ce n'est pas le cas. L'entreprise tend à regrouper son personnel par catégorie de métier d'abord, et par projet ensuite. C'est ainsi qu'on se retrouve avec les _Product Owner_s à Paris, les Développeurs à Lille, les Testeurs à Nantes, et la Production dans une autre ville encore. Cette séparation par type d'activité existait déjà avant la "magie" des télécommunications. Comment le travail de développement est il possible alors? Dans l'approche classique dite en Cascade ou en Cycle en V, la séparation des différentes compétences n'est pas considérée comme un problème, parce que le développement logiciel est vu avant tout comme un processus séquentiel, dans lequel chaque acteur produit en sortie de son activité, un artefact qui sera utilisé comme matériau d'entrée par l'acteur suivant. Dans cet approche, on cherche donc à produire des documents de conception aussi complets que possible à une phase donnée du projet. En Agile, en revanche, le développement logiciel est vu avant tout comme un travail de conception collective durant lequel on exploite des retours d'information plus efficaces fondés sur l'objectif de produire rapidement une version exploitable du système.
En cycle en V, le document est l'aliment du projet, et la conversation sert à résoudre les ambiguïtés. En Agile, la conversation est l'aliment du projet, et le document sert de support. Les conversations doivent impérativement avoir lieu pour que la magie de l'agile se produise!
L'approche Agile et l'espace
Un des principes de l'Agile^<a id="ref1" href="#fn1">1</a>^ est de rassembler autant que possible toutes les "compétences" requises pour un projet dans un même espace de travail. On privilégie une vision du développement comme travail collaboratif (c'est à dire, autant que possible, simultané et non séquentiel). Cela a des conséquences importantes:
Product Owner et Développeurs devraient se trouver à portée de voix la plupart du temps. L'environnement de travail (itérations, espace de travail, mode de communication) devrait favoriser la conversation en face du tableau ou devant l'écran de l'application.
Lorsque ce n'est pas le cas, les Développeurs et le Product Owner reviennent à une stratégie de production séquentielle, orientée document, et définie par contrat.
Or un Scénario Utilisateur n'est pas un document de spécification. C'est une description succincte^<a id="ref2" href="#fn2">2</a>^, un simple item dans le tableau d'avancement du projet, qui passe à Done lorsque le travail auquel cet item a servi de déclencheur est validé. Parce que cette Story se trouvait sur le tableau, des conversations ont eu lieu, des tests ont été élaborés, du code a été développé.
Lorsqu'une équipe à distance prend les Scénarios Utilisateurs pour des documents de spécifications, elle "prend la carte pour le territoire". Elle applique une stratégie lightweight dans un contexte qui nécessite au contraire un renforcement des communications (écrites ou orales).
Le résultat de cette stratégie est le plus souvent mitigé, voire médiocre: un Product Owner et des Développeurs qui contastent en fin d'itération: "on ne s'est pas bien compris".
En résumé, un projet Agile dans lequel les conversations sur le produit sont rares est un projet Agile en route pour les difficultés, voire le fiasco. C'est une cascade de petites tragédies que l'on déguise en comédie agile.
Alors que faire ?
Si Product Owner et Développeurs ne peuvent absolument pas travailler sur le même espace de travail, alors il faut aménager la démarche Agile afin de diminuer les risques. Plusieurs pistes sont possibles:
Ecrire des spécifications fonctionnelles détaillées pour l'itération, et les passer en revue. Ecrire des spécifications que vous ne passez pas en revue, revient à dire qu'elles seront revues à la fin de l'itération, c'est à dire lorsque les développements seront faits et non avant. La revue (en équipe avec le Product Owner, bien sûr) permet de rétablir un peu de simultanéité — c'est à dire de conversation — dans ce processus séquentiel.
Multiplier les sessions en binômes distants, en utilisant les outils de partage d'écran. Le binômage Product Owner + Développeur doit être possible sur chaque poste de travail.
Découper le projet en Scénarios Utilisateurs les plus simples possibles, et convenir d'une validation au fil de l'eau, afin de diminuer le risque d'incompréhension.
Anticiper un surcoût lié aux erreurs et aux explorations, plus élevé que si l'équipe était colocalisée, ainsi qu'un rythme de développement plus lent.
Provisionner des déplacements fréquents du Product Owner sur le site de développement, afin de maintenir au mieux la coordination, la réactivité et surtout la relation de confiance.
Améliorer délibérément la qualité des communications, en formant les acteurs du projet (par exemple: à écrire des cas d'utilisation efficaces, à l'art d'émettre et de recevoir des feedbacks), ceci afin de limiter les dérives de communication que la distance crée naturellement entre les personnes.
Et voici des mesures souvent prises et qui ne marchent pas:
Renforcer l'aspect contractuel de l'itération, notamment en exigeant du Product Owner qu'il soit plus sûr de ses idées (et d'ou viendrait cette assurance ?) et des développeurs qu'ils soient plus fiables dans leur estimations détaillées (et comment estimer de manière fiable et détaillée ce qui est si peu sûr ?). Vous n'avez sûrement pas décidé de passer à l'Agile pour mettre en place des forfaits en cascade, même petits.
"Coller à la spécification" plutôt que de contacter le Product Owner et attendre la fin de l'itération pour résoudre le problème. Lorsque le Product Owner "n'est pas disponible" ou que l'on préfère risquer de développer le mauvais produit plutôt que que de communiquer avec ce dernier, alors le projet est en péril, Agile ou pas.
Nommer un "Proxy P.O" qui sera présent dans l'équipe. Le rôle du Product Owner est de représenter les clients et les utilisateurs auprès des développeurs. Un Product Owner qui se tient "à distance", sans contact avec l'équipe, est un contresens en Agile. Cela revient à dire que le P.O garde la responsabilité du contenu fonctionnel du produit sans pour autant participer à son élaboration. C'est un étage bureaucratique qui se met en place au dessus de l'Agile, et qui va favoriser la construction d'un mauvais produit.
TL;DR
Si dans votre projet Agile, la distance géographique est inévitable, cherchez à réduire les effets de cette distance: écrivez plus — car une User Story n'est pas une spécification — et organisez des revues de vos documents. Améliorez la qualité de la communication durant l'itération, au lieu de renforcer les aspects contractuels en début et fin d'itération. Ne désignez pas de rôles intermédiaires, cela ne fait qu'ajouter de la distance organisationnelle à la distance géographique.
Notes
http://agilemanifesto.org/principles.html
Business people and developers must work together daily throughout the project. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
http://c2.com/cgi/wiki?InvestModelForUserStories
A user story is negotiable. The "Card" of the story is just a short description of the story which do not include details. The details are worked out during the "Conversation" phase. A "Card" with too much detail on it actually limits conversation with the customer.