7 idées reçues sur l'agilité !

Aujourd'hui, tout le monde parle d'agilité. Mais comprend-t-on toujours de quoi il s'agit...hum. J'ai entendu beaucoup d'idées reçues sur le sujet, et j'ai trouvé amusant d'en rassembler un certain nombre, en tentant d'y apporter une réponse.

Vu ou entendu dans la vraie vie ! Est-ce que vous en avez d'autres ?


L'agilité, c'est que pour les développeurs !

Oh que non !!!

L'agilité, c'est un écosystème qui impacte tous les acteurs concernés par la matérialisation d'un besoin. C'est une chaîne de valeur complète, dynamique, collaborative, qui part du besoin (l'utilisateur), jusqu'à son maintien en condition opérationnelle (l'exploitant). Et accessoirement, c'est vrai, cette chaine passe par les développeurs...

Et de même que pour la chaîne de production horizontale, l'agilité impacte aussi la verticalité de l'organisation : le management et ses différentes strates. Le contrôle sans confiance, l'autocratie, les décisions top-down, tout cela est incompatible avec l'agilité. Le management doit donc se positionner aussi sur ces questions, et évoluer vers plus de facilitation, d'écoute, de libération des énergies.  

Et pour ceux (comme moi) qui l'ont vécu, je peux vous garantir qu'une équipe de dev agile dans un environnement non agile, c'est le meilleur moyen de se planter !

L'agilité, c'est freestyle, y a pas de process !

Facile celle-là, car c'est tout l'inverse !

Des rôles (PO, SCM, ...), des activités (Story Mapping, Sprint planning,...), des livrables (incréments du produit), des outils de pilotage (backlogs, burndowns, ...), des check-list (DoR, DoD, ...). Tout cela ne ressemble-t-il pas à un process ?

En réalité, l'agilité est une vraie discipline, tant sur le plan de l'organisation que de l'ingénierie. Cette discipline, bien menée, permet au fil des itérations une réelle maîtrise du projet et de la qualité de ce qu'il produit. A l'inverse, baisser la garde et le niveau d'exigence sur ces pratiques, et c'est un risque d'échec.

En fait, plutôt que de "discipline", il faudrait plutôt parler de compréhension et d'appropriation. Car le projet devient vraiment agile quand chacun comprend l'objectif et s'en approprie les moyens. L'agilité est avant tout une histoire de culture. Le process, lui, est à adapter à chaque contexte.

C'est pas freestyle, c'est juste fun !

En agile, y a pas de specs !

Hum, plus dure celle-là, car certains sont vraiment réfractaire à l'idée de parler de spec en agile. Mais pour moi, clairement, ce n'est pas un gros mot !

Je dirais plutôt, en agile, y a pas de gaspillage. Ce qui est certain, c'est que passer 6 mois à pondre une spec détaillée qui sera de toute façon incomplète et surtout probablement déjà obsolète au moment de sa validation, c'est du gaspillage.

En agile, on spécifie au moment où on en a besoin (JIT - Just In time). Et pour spécifier, on privilégie le dialogue constant, productif et respectueux entre ceux qui veulent (utilisateurs, MOA, DSI) et ceux qui font (analystes, développeurs, testeurs). Spécifier en vase clos et "balancer" la spec aux développeurs, c'est assurément soumettre le besoin à interprétation. Et ça, c'est si la spec est lue!

L'essentiel, c'est donc pas la spec, c'est la compréhension de ce qu'il y a à produire par ceux qui produisent. Et ça passe par le dialogue. Le niveau de documentation associé est en réalité fonction de chaque contexte et de chaque besoin. Et surtout fonction de la valeur réelle apportée par le document. Les approches de test spécifiant (ou de spesc exécutable) sont extrêmement puissantes, et reviennent à spécifier avec des exemples concrets, vivants et surtout qui ne sont pas soumis à interprétation.

Un projet agile ? OK, on code tout de suite !

Essayez pour voir !

Démarrer la réalisation d'une application sans poser la vision fonctionnelle et technique de la cible est une aventure hasardeuse à laquelle je ne participerai pour rien au monde. (En fait, c'est possible, mais ça ne s'appelle pas une application, ça s'appelle un POC).

Pour réellement démarrer un processus de construction itératif et incrémental, l'architecture doit être stabilisée. Le contexte, les acteurs, les domaines fonctionnels, les contraintes techniques, l'ergonomie générale, les modules logiciels, l’élaboration d'un premier Product Backlog...Certains appellent cela le Sprint zéro, mais soyons clair, ce n'est pas un Sprint au sens Scrum, c'est une phase d'initialisation et d'analyse. 

En revanche, la conception détaillée doit émerger et s'améliorer au fil du développement. Mais cela doit se restreindre à la manière d'organiser le code et ses classes (refactoring, design pattern) et pas aux principes structurants de l'architecture (sinon, ça peut faire mal...).

Un forfait agile ? Faire rentrer des ronds dans des carrés !

Sujet sensible...mais clairement, ça marche (sinon je serai au chômage !).

Forfait et agilité, ce n'est pas du tout incompatible, mais (car il y a un mais), ça doit influer sur la manière de contractualiser. Dans un forfait agile, l'un des éléments du triptyque CCC (Coût/Contenu/Calendrier) est forcément variable. Généralement, c'est le Contenu. On s'engage sur une complexité globale, et on fait varier le détail. Tant qu'on est dans la même complexité globale, l'engagement est maintenu (ici le Coût et le Calendrier). 

Pour que cela fonctionne, il est fondamental que client et fournisseur partagent les métriques qui servent à établir la complexité. La vraie difficulté, c'est donc l'étalonnage de cette complexité, qui est forcément empirique. Ce qui veut dire que sans expérience préalable sur le contexte, il faut adresser le risque de s'engager avec une vision erronée de la complexité globale (mais là, ça ne change pas des forfaits classiques). L'idéal est donc de procéder à cet étalonnage avant de s'engager forfaitairement.

Le second point important du forfait agile, c'est l'abandon de la vision "donneur d'ordre/exécutant" du contrat classique, au profit d'une approche plus "gagnant/gagnant". Sur ce point, pas mail d'éléments de contractualisation agile existent et sont de plus en plus matures. Mais quand on veut contractualiser en agile, on rencontre plus souvent des problèmes de culture et d’organisation que des problèmes juridique.

De l'agilité en offshore ? OK, t'as rien compris à l'agile alors...!

"...et les interactions entre individus du Manisfeste  ?!" Ok, ok, mais pourtant, ça tourne !

Et non seulement ça tourne, mais en réalité, je me demande comment mener un projet offshore sans agilité ! Mais on va pas se le cacher, un projet avec une équipe à distance rencontre toujours la même difficulté : la distorsion de l'information échangée. C'est toujours incroyable pour moi de constater comment l'absence de discutions informelles type "machine à café" influe sur la compréhension des inputs et sur la qualités des outputs. Or l'agilité possède deux armes pour contrer les effets pervers d'une équipe distante : des cycles courts et des cérémonies collaboratives régulières.

Les cycles courts permettent tout simplement ici de limiter le risque d'un livrable inadapté. En mode offshore, je réduis au maximum la durée des Sprints (une semaine). Les cérémonies qui encadrent les Sprints et qui permettent la compréhension, la démonstration, l'ajustement et l'amélioration  (plannings, revues, rétrospectives) sont donc aussi plus rapprochées et génèrent rapidement du feedback et des actions.

Et puis il faut savoir innover. Le ScrumMaster (forcément en Back, avec l'équipe) envoie au Front un "Daily Mail" à l'issue de chaque Daily Scrum. Un "Architecture Owner" (côté Front) assure l'intégration et la validation avant la démonstration au Product Owner (côté Front également, cela va sans dire). Un Proxy PO (coté Back) peut aussi faire son petit effet (à condition qu'il puisse rencontrer régulièrement le vrai PO). Et puis les réunions de planification et de rétrospective se font en Visio Conf.

Bref, l'agilité appliquée à elle-même !

Agilité et CMMI, ç'est pas compatible !

En théorie, c'est possible ! Mais en pratique ?

En pratique...c'est vrai qu'il peut y avoir une différence d'appréciation, voir de méthodes. Ce qui est certain, c'est que l'agilité ne se substitue pas aux fondamentaux de l'industrie logicielle et de ce qui fait qu'un projet est un succès ou un échec : bon niveau d'expertise, de coordination, de collaboration et de pilotage.

Si l'on considère que l'assurance qualité, c'est se conformer à un plan, produire des documents uniquement pour alimenter les revues, mesurer la productivité individuelle ou encore présenter des indicateurs "pastèques" en comité de pilotage (vert à l'extérieur, rouge à l'intérieur), alors oui, il y a problème de compatibilité avec l'agilité. En revanche, si les procédures d'assurance qualité se focalisent sur les moyens donnés aux équipes et sur le suivi de l'apport de valeur réelle au client final, alors rien ne doit empêcher d'intégrer de l'agile dans un processus CMMI.

Pour ma part, je ne l'ai pas encore vu, mais je ne désespère pas ;-)


A lire également : 7 changements à intégrer pour un véritable projet agile