Les transitions agiles ne prennent pas magiquement. Celles qui réussissent sont le résultat de la convergence de la volonté du management et de son adoption au sein des équipes de développement. C’est dire si ‘pivoter’ vers cette approche du développement de produits informatiques n’est bien souvent pas un long fleuve tranquille… Dans cet article, je vous propose une liste (non exhaustive) d’excuses et d’anti-patterns vraiment rencontrés lors de certaines de ces transitions. Ils sont autant de signaux d’alerte qui doivent vous faire prendre conscience que l’adoption de l’agilité n’est pas gagnée… Dans la plupart des cas, vous verrez qu’ils ne traduisent que de la résistance au changement.
Le Product Owner, un rôle sensible
Le rôle du Product Owner, que vous partiez sur Scrum ou Kanban, est très important. C’est lui qui porte la vision du produit ou du projet, et celui qui assume la bonne priorisation des fonctionnalités à délivrer. Il est actuellement le plus exposé des rôles, et a souvent bon dos pour ‘scier la branche’ des démarches agiles.
Excuse : ‘le Product Owner n’est pas assez technique’
Cette excuse est pratiquement hors sujet : le Product Owner n’a pas à être technique. Il doit d’abord avoir les moyens de porter la bonne vision fonctionnelle du produit à développer, il n’a donc pas vocation à être technique : c’est parfois plus pratique, donc apprécié, mais aucunement obligatoire pour remplir ses fonctions. Bien entendu, un bagage technique minimal permet de comprendre et bien prendre en compte les contraintes de l’équipe de développement. Si ce bagage là ne fait pas partie de la panoplie de votre PO, gardez bien à l’esprit qu’on ne fait de la technique que pour remplir un objectif limpide : apporter une plus-value fonctionnelle. Si votre PO est la bonne personne pour garantir cela, passez outre le fait qu’elle n’est pas ‘technique’.
Anti-pattern : le Product Owner n’est pas autonome dans ses décisions
Le rôle est encore jeune en France. Aussi, les Product Owners expérimentés sont encore une denrée rare. Ceci explique que les PO de nombreux projets actuels sont encore un peu ‘verts’, et doivent rendre pas mal de comptes à leur hiérarchie. Cultiver une situation de PO ‘fantoche’ est très dangereux. D’abord, c’est inconfortable pour la personne, qui peut se retrouver bien souvent contredite dans ses choix, et vis-à-vis de l’équipe de développement, cela peut porter le message suivant : il n’y a pas de vision claire pour le produit que nous développons. Rien de mieux pour mettre quelqu’un en déficit de confiance : il faut absolument éviter cela. Choisissez bien vos PO et faites leur confiance. Laissez-leur les clefs, donnez-leur les moyens de réussir, et instaurez une culture de l’acceptation bienveillante de l’échec.
Difficile de réussir sans elles : les pratiques d’ingénierie agile
Scrum est un cadre, Kanban un système. Par essence, ils ne prescrivent pas de pratiques d’ingénierie. Et pourtant, ne pas les prendre en compte serait une erreur.
Excuse & erreur : ‘la conception émergente, ça ne marchera pas pour nous’
Big Design Up Front, ça vous parle ? Avez-vous déjà été confronté à un architecte ou une équipe de développement qui vous soutient mordicus que, pour correctement développer votre produit, il va falloir penser TOUTE l’architecture, le modèle de données, la conception en amont ? Je vous assure qu’en 2013 c’est encore possible, je l’ai vécu ! La conception émergente est le lot de bien des équipes agiles, et ça fonctionne. N’en déplaise à d’autres équipes (qui n’essaient même pas…), le match Big Design Up Front vs Emergent designest déséquilibré. Le premier amène un effet tunnel avant de délivrer de la valeur métier, donne des maux de tête, débouche bien souvent sur des choix overkill et n’a bien souvent rien de pérenne. Alors qu’à l’inverse, vous pouvez itérer, incrémenter et avoir un design simple. Libre à vous d’opter encore pour la première solution, mais vous ne pourrez pas dire qu’on ne vous a pas prévenus :-)
Excuse : ‘On ne va pas faire de la conception collaborative, le niveau des équipiers n’est pas homogène’
Dans une grande majorité de cas (toujours ?), le niveau technique des équipiers est disparate. Ce fait ne doit pas pour autant vous amener à une forme d’auto-censure sur la conception collaborative. En effet, un junior peut, tout à fait, faire des propositions valables ou apporter un point de vue intéressant. Au-delà de l’émergence d’un bon design, c’est aussi un moyen de faire grandir une équipe. Il ne faut pas oublier que l’amélioration continue des personnes est aussi un objectif des approches agiles et que l’approche collaborative du travail qu’elles promeuvent fonctionne et est épanouissante.
Excuse : ‘le refactoring permanent, c’est du gâchis!’
Cette phrase peut tout à fait servir en complément de ‘la conception émergente, ça ne marchera pas pour nous’ (en fait, ça s’est passé EXACTEMENT comme ça…).Pourtant, le refactoring, ce n’est pas sale. Ce n’est que l’équivalent d’un bon entretien de sa voiture, de son jardin, sauf que c’est votre code que vous entretenez. D’abord faire quelque chose qui marche, puis grâce au filet du TDD (ou au moins de sa batterie de tests unitaires…), faire quelque chose de propre, et ainsi de suite. Le refactoring ‘permanent’, ce n’est pas plus du gâchis qu’un design overkill, qui a mis X mois à voir le jour, pour finalement être mis à mal par une fonctionnalité dont on n’avait pas connaissance durant cette phase ‘d’architecture’…
Toute ressemblance avec des situations réelles n’est pas fortuite. L’agilité n’est pas un chemin semé de roses : parfois, ça ne prend pas. Inutile alors d’insister, certaines équipes ne sont pas faites pour cette approche du développement informatique. Par manque de volonté, par peur du changement, par préférence au retour vers une zone de confort (le fameux ‘c’était mieux avant’). Sans acceptation du changement, toutes vos tentatives resteront vaines.