Slack Facilité, 20 avril 2018:

« Hey gang! Petite question du vendredi: l’un de nos projets part en mode support v1/dev v2 avec 40 personnes au total et 6 max pouvant être dédiées au support v1. Dans vos expériences, qu’avez-vous mis en place en terme de répartition de l’équipe de support? On a déjà pensé à 5 équipes de dev (SCRUM) + 1 équipe de support et améliorations (KANBAN), 6 équipes (SCRUM) avec un membre de support dans chaque équipe ou une équipe de support qui tourne, d’autres idées? »

Mets-en que j’ai d’autres idées!

J’ai même d’autres questions. À quel moment dans notre histoire commune est venue l’idée de séparer l’entretien de l’évolution? Séparer le développement de nouvelles fonctionnalités du support de celles déjà livrées?

On s’entend que d’un point de vue Fordisme, cette division verticale du travail a beaucoup de sens. On peut même étendre ce raisonnement en amont, appliquer la même équation à la conception (architecture, design, analyse) et structurer le travail comme une bonne et belle chaîne de montage où chacun cogne sur son clou avant de passer le travail au suivant.

En ajoutant une belle matrice d’imputabilité, on peut même forcer chaque division à accomplir sa tâche, et uniquement sa tâche, de manière standard et mesurée.

Le contrecoup

D’un autre côté, si cette structure de travail paraît efficace d’un point de vue gestion, il en est tout autre d’un point de vue production.

Premièrement, les effets constatés à long terme sur la culture sont désastreux. En divisant le travail par compétence, on crée un environnement où les échecs des uns sont toujours attribuables à l’incompétence de celui qui est passé avant ou de celui qui vient après. Généralement, plus on se situe loin sur la chaîne de livraison, plus on a l’impression de rattraper les erreurs des autres.

Deuxièmement, on crée des délais. Comme je l’ai déjà écrit dans un article sur le sujet, une division du travail basée sur la spécialisation autour d’une compétence (ou d’une étape précise du cycle de production) causera fort probablement des goulots et de la surcharge dans un système où les travaux en cours ne sont pas limités. Cette surcharge causera des délais considérables dans la livraison.

Enfin, d’un point de vue informationnel, l’organisation du travail en silo est très inefficace. Nous ne devons jamais perdre de vue que nous sommes dans un domaine où le savoir et l’information sont les pierres angulaires de ce que nous produisons.

Le travail du savoir

Tout développement informatique est en premier lieu une quête de savoir. Il faut voir le processus de conception et de réalisation comme des grandes étapes d’apprentissage où l’on commence sans aucune connaissance de la solution et qu’on se dirige graduellement vers 100% de connaissance de la solution.

Ce qu’il y a d’embêtant avec le savoir:

• Il réside dans la tête des gens;
• Il est coûteux à transférer et ce n’est pas sans risque (pensez au jeu du téléphone);
• Il expire lorsque le contexte évolue et il est impossible d’en connaître la date d’expiration.

Lorsqu’on sépare l’entretien du développement, on s’expose donc à plusieurs risques au niveau de la connaissance. Chaque fois qu’il y a un bogue dans l’application en production, l’équipe d’entretien en apprend un peu plus sur le produit et sur ses faiblesses. Cette connaissance est difficilement injectable dans le processus de l’équipe de développement. On perd donc une superbe opportunité d’améliorer la qualité du produit dans les développements futurs.

Les boucles de renforcement négatives

Et qu’arrivera-t-il dans les périodes de surcharge? Une équipe de développement qui doit aller plus vite en raison d’un délai serré sera tentée de couper dans la qualité. Ceci entraînera une augmentation des problèmes en production qui sont gérés par l’équipe d’entretien. Et si l’équipe de développement est encore à risque de rater sa date butoir, on empruntera un ou deux membres de l’équipe d’entretien, qui est déjà en sous-effectifs dû au manque de qualité des dernières livraisons.

Que fait-on alors?

On laisse l’équipe de développement gérer ses propres bogues. L’équipe conserve alors toute la connaissance pour faire sa première boucle d’apprentissage (la réparation du bogue), une seconde boucle (comment corriger la source de ce bogue), et même une troisième boucle (améliorer ses méthodes de production).

L’importance des cadences

Cette magie n’opérera pas seule par contre. Comme je le mentionne régulièrement, notre travail est celui du savoir et de la connaissance. Il est donc primordial de laisser une place de choix à la réflexion et à l’introspection au sein de l’équipe. Je vous garantis qu’il n’y a rien de mieux qu’une bonne rétrospective basée sur des observations à fréquence régulière pour améliorer un système de livraison. Si vous ne savez pas comment aborder ces rencontres, je vous suggère ces quelques ressources:

https://plans-for-retrospectives.com/fr/

http://www.funretrospectives.com/

Et pour ceux qui veulent quelque chose d’un peu plus factuel: https://www.infoq.com/articles/blockers-defects-process-improvement

Et pendant qu’on y est…

Tant qu’à discuter de composition d’équipe, pensez aussi à inclure des gens qui ont des connaissances diverses du produit qui est développé. Des designers, des testeurs, des analystes d’affaires, des utilisateurs, des administrateurs de systèmes, des pilotes, des codeurs, des concepteurs et tout ce qu’il vous faut pour livrer de la valeur à vos clients!