Laissez l'équipe faire ses choix techniques !

Introduction

Ce que j'aime bien dans l'agilité, c'est le côté "bons sens" et pragmatique. Et ce que j'aime particulièrement dans Scrum, c'est le nombre limité de rôles, et la précision du périmètre de responsabilité pour chacun de ces rôles. Voir mon précédent article "Scrum : quel est le rôle le plus important ?".

Pour un projet de développement logiciel, les équipiers sont essentiellement des développeurs. Tout comme le Product Owner a la responsabilité de la partie fonctionnelle (quelles fonctionnalités et pour quand ?), les équipiers ont la responsabilité de tout ce qui est technique : choix des technologies, choix de l'architecture de l'application, règles communes de codage, qualités, innovation, etc ...

Qu'est-ce que j'entends par "Innovation" ?

Nous sommes dans un métier d'artisanat, nous faisons rarement 2 fois la même chose, et l'éco-système bouge très vite, il y a très souvent des nouvelles technos intéressantes, de nouveaux langages, de nouvelles méthodes ou façon de développer, etc ... 

Donc par "innovation", j'entends tout ce qui va permettre de faire du développement moderne, non pas pour être à la mode, mais pour mieux répondre aux besoins en profitant au mieux des nouveautés. Il y a donc bien sûr les nouveaux outils et les nouveaux frameworks. Mais il y a également les changements (nouveautés ou remises en questions) sur la façon d'écrire le code, le commenter ou pas, le présenter, l'organiser, l'architecturer, etc ... Cela porte donc sur des choix structurant pour l'ensemble du projet (choix d'architecture par exemple), mais également sur les choix quotidiens du développeur pour écrire son code, comme par exemple mettre en place une API fluent parce que le code sera plus lisible et bien plus facile à utiliser pour les successeurs !

Innover ou pas ? 

J'observe que la question est souvent posée, et parmi les réfractaires, on peut trouver des managers et des développeurs.

De mon point de vue, les managers devraient pousser plus à l'innovation. Mais il y a malheureusement plusieurs raisons pour qu'ils ne le fassent pas. Par exemple, ils peuvent avoir peur que cette innovation soit excessive par rapport aux besoins et aux contraintes du projet. Ou encore, ils ont un manque de compétences pour en juger.

Et d'un autre côté, certains développeurs sont eux aussi septiques par rapport à l'innovation, mais c'est souvent par peur de l'inconnu en sortant de leur zone de confort.

Pour ma part, c'est évident, il faut innover en permanence. Nous sommes dans un métier qui bouge en permanence, tant du point de vue outils que méthodes, il est important que les développeurs suivent un minimum les évolutions, à la fois pour produire des logiciels modernes, et également pour entretenir leur employabilité !

Mais bien sûr, cette innovation doit être dosée et maitrisée. Il ne faut pas être excessif et se jeter en permanence sur les nouvelles technos à la mode. De même, il me semble très dangereux de faire cohabiter, au sein d'un même produit, plusieurs librairies qui rendent le même service. Idéalement, l'architecture doit permettre, si besoin, de remplacer une librairie par une autre, s'il y a réellement un intérêt.

Une erreur : l'innovation par certains !

Parmi les erreurs que j'ai pu observer ou vivre, il y a la solution de confier l'innovation à une personne (ou un groupe de personnes). Pour un manager, c'est rassurant, certes. Mais les effets négatifs sont nombreux.

Déjà, cette solution est très frustrante et démotivante pour l'ensemble de l'équipe. Bon nombre de développeurs sont intéressés pour chercher et tester de nouvelles technos. Et s'ils ne le sont pas, il faut les y inciter, car cela fait partie de notre métier.

Par ailleurs, cette approche limite l'innovation, puisqu'elle est confiée aux idées et aux visions d'une seule personne.

Et enfin, cette façon de faire limite énormément l'implication de l'équipe pour l'intégration de ces nouvelles technologies, induisant prise de distance et démotivation.

Une autre erreur : la validation par tous !

Parmi les profils de développeurs, il y a ceux qui sont plus dans "la production" et ceux qui sont plus dans "l'apprentissage" (j'essaierai de publier un article à ce sujet). Je ne suis pas sûr que ces profils puissent travailler ensemble au sein d'une même équipe "projet" (i.e. travaillant ensemble sur un projet). Mais ces profils cohabitent au sein de tout service développement logiciel, et cela peut être une réelle et importante difficulté à gérer pour les managers.

Mais pour revenir à l'innovation, une erreur me semble-t-il, est de faire valider toutes les innovations par l'ensemble des développeurs d'un même service. En faisant cela, on met en dualité les 2 types de profils précédent, pour lesquels il ne peut pas y avoir de consensus. Soumettre l'adoption d'une innovation à l'approbation générale a comme seule issue de limiter cette innovation, puisque les profils les plus "conservateurs" ou "craintifs", refuseront toutes innovations.

Le premier effet est donc une innovation extrêmement limitée.

Le second est un désengagement et un découragement de ceux qui sont dans "l'apprentissage" et qui pourraient pousser ces innovations indispensables. Le service de développement logiciel n'évolue pas, et en quelques années, il est dépassé et produit des logiciels d'un autre temps. Dommage...

Conclusion

Chaque développeur est un artisan, qui doit être passionné par son métier, et qui a la responsabilité d'innover régulièrement.

Et chaque manager doit avoir conscience de cette nécessité, de l'aspect indispensable de l'innovation, sans excès et maitrisée, il doit donc laisser une marge de manoeuvre aux développeurs pour cette innovation, il doit leur faire confiance pour les choix d'innovation qu'ils feront pour le projet en cours, il doit inciter tous les membres de l'équipe vers cette innovation, et il doit accompagner les "conservateurs" pour que ces derniers puissent comprendre les enjeux, dépasser leurs craintes et sortir de leur zone de confort.