J’ai eu la chance d’être initié à l’agilité au sein d’une équipe de développeurs aguerris. Plus tard, j’ai eu l’opportunité d’aider à démarrer cinq équipes de développement agiles. A partir de ces expériences, permettez-moi de vous dire en quoi la confiance est à la fois la condition de possibilité et le principal fruit de l’agilité.
Obtenir la confiance pour passer en agile
Si votre entreprise n’a jamais fait l’expérience du développement agile de logiciel, il est probable que vous ayez besoin de faire vos preuves pour ne serait-ce qu’avoir la possibilité de vous y essayer.
Peut-être le management n’a-t-il aucune confiance dans la capacité de la DSI à délivrer quoi que ce soit and ne veut pas risquer de vous donner les clés ? Peut-être les achats croient-ils pouvoir contrôler les coûts en sous-traitant des projets avec un engagement au forfait ? Il est probable que quelques-uns aient eu une mauvaise expérience avec quelqu’un qui prétendait faire de l’agile (la fameuse méthode à Gilles), ou qu’ils soient fatigués d’un buzzword creux pour eux. Certainement la plupart n’ont qu’une notion lointaine de ce que c’est (et des préjugés type “l’agilité est bien pour les projets simples, mais rien ne vaut un bon cycle en V pour délivrer un produit complexe”).
Bien que casser quelques illusions soit parfois une étape nécessaire (“Mais comment se fait-il que le projet X, au forfait, ait vu son budget gonflé de 40% à la fin de la phase de cadrage, soit avant qu’une seule ligne de code ait été écrite ? Pourquoi persister à croire que le projet Y va respecter sa deadline finale, alors que le Lot 1 a déjà un an de retard ?”), ça peut être inutilement cruel. Car après tout, le management s’est tellement commité *qu’ils se *doivent de prétendre croire que la deadline peut être respectée (et leur expérience est probablement que seul un volontarisme forcené et un management dur permet d’atteindre un quelconque résultat).
C’est également vain voire contre-productif si vous ne pouvez pas les amener à avoir confiance en votre capacité à proposer mieux. Cela nécessitera que (i) vous puissiez expliquer comment l’agilité peut produire de meilleurs résultats et (ii) vous prépariez vos équipes en leur faisant acquérir les compétences techniques (par exemple, la capacité à mettre en oeuvre une CI/CD) et non-techniques nécessaire à livrer de la valeur de façon incrémentale dans un logiciel toujours fonctionnel et évolutif.
L’agilité et la confiance, un cercle vertueux
Une fois ces premiers obstacles derrière vous, l’agilité (si elle est bien mise en place) fait sa magie et contribue à construire la confiance entre l’équipe et les autres parties prenantes.
Plus d’une fois, j’ai vu des interlocuteurs métiers, d’abord désarçonnés par notre refus de s’engager sur des deadline avant d’avoir démarré, être positivement surpris en voyant dès la fin du premier sprint un produit utilisable (certes, fonctionnellement limité) puis heureux de constater qu’un logiciel pouvait être amélioré sans régression, même avec une base de code importante, et que garder une exigence de qualité importante produisait à terme une forte vélocité.
De plus, j’ai réalisé dans une expérience suivante à quel point une revue de sprint devait être plus qu’une démo d’un incrément de produit, et comment le partage que l’équipe pouvait faire, en profondeur, des difficultés rencontrées faisait naître une véritable “intimité” entre IT et métier, dont jaillit la confiance. Une fois cette relation établie, le métier peut (et doit) rester exigeant, mais ne peut plus bêtement manier le fouet.
Une communication fréquente est un facteur de confiance. Dans bien des cas, j’ai vu comment mes subordonnés pouvaient bien mieux que moi construire avec telle ou telle partie prenante une relation de confiance, du simple fait qu’ils étaient en mesure de passer du temps avec la personne.
Dans un contexte où les relations entre métier et IT sont souvent (hélas) déséquilibrées, il n’est jamais facile de trouver l’équilibre entre ce besoin de lien direct entre l’équipe et les métiers (le manifeste agile ne dit-il pas que “Les personnes en charge du métier ou des affaires et les personnes en charge de la réalisation doivent travailler ensemble chaque jour, tout au long du projet. / La conversation en face à face est la méthode la plus efficace et la plus économique pour donner des informations à une équipe de réalisation” ) et la nécessité que l’équipe de développement soit auto-organisée. Lorsque les équipes sont en distanciel, le tableau agile est souvent dématérialisé sur Jira, et même si Dieu sait que j’aime Jira, je n’ai jamais vu de pause café passer à philosopher sur un tableau scrum virtuel.
Qu’est-ce qui, dans l’agilité, produit la confiance ?
J’ai déjà évoqué plus haut la transparence comme inducteur de confiance. Mais ce n’est qu’un ingrédient de la recette. Voici quelques éléments qui me semblent clé.
(a.) Le principe d’auto-organisation de l’équipe mène à une meilleure allocation du pouvoir de décision. Par meilleure, j’entends que les décisions sont prises par les bonnes personnes, c’est à dire ceux qui ont le contexte et l’expertise pour les prendre. Le métier maîtrise la roadmap produit et les tech prennent les décisions techniques.
Notez que la frontière peut être floue, et cela peut nécessiter que l’équipe sache s’affirmer dans son expertise (par exemple, j’ai vu trois équipes amenées par leurs interlocuteurs métiers respectifs à développer trois workflows distincts de création de compte et d’authentification, sans qu’aucun d’eux ne respecte les standards de la profession en termes d’UX.. quelle perte de temps et d’énergie !).
Des équipes auto-organisées (ça n’exclut pas d’avoir des plus leaders, sans quoi c’est l’anarchie) mènent à des équipiers motivées et qui s’investissent plus fortement dans leur produit.
(b.) La qualité. Pour produire du logiciel fonctionnel et évolutif dans un rythme indéfiniment soutenable, les équipes agiles doivent maintenir une exigence de qualité importante. Elles ont tendance à pousser la non-qualité vers la gauche *dans le cycle de développement. Un développeur ne verra pas une story qui ne respecte pas la *Definition of Ready, un reviewer ne relira pas du code si les tests automatisés ne passent pas, un testeur ne testera pas du code non-relu par un pair, etc.
La vélocité, rappelons-le, est un sous-produit de la qualité. On ne fera pas de compromis entre elle et la qualité. J’ai su que certains de nos partenaires avaient franchi un seuil dans la compréhension de l’agilité quand, pendant une revue de sprint, ils ont tiqué en voyant l’équipe sur-délivrer (en termes de points de complexité) au prix de la qualité.
(c.) la maîtrise des risques. Les équipes agiles s’attachent à livrer un logiciel fonctionnel. Cela signifie qu’elles préféreront livrer un *squelette qui marche *(un logiciel pleinement intégré, même s’il ne fait pas grand chose) plutôt qu’un front-end terminé sans back-end.
Les défis techniques ainsi sont résolus (ou contournés) plus tôt dans le cycle de développement ; de plus, la nature itérative et collaborative du processus de développement permet la correction d’erreur, l’ajustement au besoin, empêche un dev de s’enfermer des jours sur un obstacle technique, etc. Les métiers savent qu’ils peuvent décider tous les quinze jours de la trajectoire, minimisant ainsi au maximum les “portes à sens unique”.
Personne n’est assez intelligent pour produire à l’avance une spécification détaillée (et juste, et complète) d’un système complexe. Le processus itératif permet que toutes les parties prenantes focalisent et rassemblent leur énergie sur des incréments de petite taille. C’est pourquoi l’agilité est, selon moi, particulièrement adaptée pour les projets complexes.
Comme l’amour, la confiance est avant tout une question de décision
Un manager humble réalise tôt ou tard que, s’il prétend garder tout sous son contrôle, il n’obtient qu’un groupe de personnes démotivées livrant du logiciel jetable.
Or, contrairement sans doute à il y a une vingtaine d’années, il est aujourd’hui possible de produire des logiciels durables et cependant évolutifs, qui soient vraiment un capital de l’entreprise. Possibilité dont l’agilité est un facteur-clé de succès.
Tout démarre donc avec une décision, celle de faire confiance. Lancez-vous :)
Top comments (0)