Essec Business School

La crise du Covid-19 qu’on traverse actuellement a impacté les travailleurs de deux manières bien distinctes. D’une part, les personnes aux métiers essentiels, y compris les professionnels de la santé et les soignants, les services d’urgences, mais aussi ceux travaillant dans les secteurs alimentaires et agricoles et qui continuent d’aller travailler chaque jour. Le résultat est une reconnaissance renouvelée de leur contribution sociétale qui, espérons-le, survivra à la crise. D'autre part, une grande partie de la population active doit travailler depuis son domicile. Même si cette situation peut paraître confortable pour beaucoup par rapport aux luttes vécues par les travailleurs en première ligne, elle n'est pas sans difficultés. Au-delà des défis liés à la justice sociale et à l’équilibre de la vie familiale, des questions importantes se posent quant à savoir si le télétravail fonctionne réellement.

Une profession qu’on devrait examiner de plus près est celle de développeur de logiciels. Le développement de logiciels n’a jamais été aussi pertinent, étant donné l’ère du numérique, et en particulier dans un temps où les connexions humaines, sociales et professionnelles s’appuient presque exclusivement sur les technologies digitales (Yoo, 2010). A première vue, on peut penser que l’impact du télétravail est moins important pour les développeurs de logiciels. Le codage peut être fait depuis n’importe où et les développeurs bien versés en technologies ne devraient pas avoir de problème avec les outils de collaborations. Aujourd’hui, de nombreuses pratiques dans le développement de logiciel se sont inspirées par le fonctionnement des communautés open-source. Tant que Github fonctionne, on devrait s’en sortir, non ? 

Ce n’est pas tout à fait faux. Le développement de logiciels est une activité qui peut (c’est souvent le cas) se faire à distance. Il y a quand même quelques mises en garde. Les développeurs des logiciels qui doivent maintenant faire du télétravail font face aux mêmes défis personnels que tout le monde pendant cette période inédite. Mais il y a aussi des complexités liées au travail que les équipes de développement de logiciels doivent gérer, notamment ceux qui suivent une approche de développement agile. Ces perturbations sont liées au produit, au processus du développement, et au tissu social de l’équipe.

Les défis du développement de logiciels agile en télétravail

Premièrement, il y a des défis liés au produit logiciel et à son architecture. L’architecture du logiciel est la structure fondamentale du système de logiciel et elle décrit comment le système est divisé en éléments et comment les éléments interagissent. Les systèmes peuvent être plus ou moins modulaires, ce qui a des implications directes sur le niveau de la communication et de la coordination nécessaires au sein des équipes de développement et entre équipes. Les équipes travaillant sur un système modulaire auront moins de difficultés à s’adapter au télétravail. Pourtant, le développement du logiciel agile moderne essaie d’être adaptable et allégé, ce qui veut dire que les décisions architecturales sont reportées autant que possible. Un tel report des décisions architecturales mène aux architectures qui sont, dans une certaine mesure, émergentes. Cela a des avantages en temps normal mais peut être moins adapté au télétravail car il exige un niveau de coordination plus intensif. En fait, les structures de plate-forme, qui fixent à l'avance une base extensible sur laquelle des équipes agiles peuvent travailler plus indépendamment, peuvent être mieux adaptées.

Deuxièmement, le télétravail est susceptible de mener à des difficultés avec le processus du développement de logiciels. Un des principes clés du développement agile des logiciels est l’accent mis sur le travail itératif et collaboratif. Les membres d’équipes ont la propriété commune du code, se retrouve régulièrement, et suivent les pratiques collaboratives fixées par les méthodes comme Scrum ou Extreme Programming. Par exemple, une pratique adoptée par les équipes agiles est le “pair programming”, où deux développeurs développent le code ensemble (Kude et al., 2019). Un des buts de pair programming est d’assurer un contrôle qualité instantané. Par opposition à l'approche du pair programming, les équipes peuvent également s'appuyer sur des solutions techniques pour le contrôle qualité, telles que les tests automatisés. Le pair programming s’étend au-delà du contrôle qualité comme il aide à créer les structures et comportements positifs de travail en équipe dont on a beaucoup besoin en ces temps exceptionnels (Kude et al., 2019). Cependant, lorsqu'on vise principalement l'assurance de la qualité, on peut facilement supposer que les approches techniques telles que les tests automatisés fonctionnent de manière plus fiable que pair programming. L’approche collaborative et itérative du développement agile s’applique également aux clients et aux utilisateurs finaux, qui sont régulièrement impliqués dans les activités de développement à un stade précoce et d’une manière continue. Cette implication peut être un problème pendant une crise comme celle qu’on traverse actuellement car le retour d’expérience des clients sont peut-être indisponibles si les utilisateurs ou l’entreprise des clients ne travaillent pas comme d’habitude.

Troisièmement, le tissu social d’une équipe peut faire faire à des difficultés. Beaucoup de communication et de coordination instantanées peuvent être faites via les outils de collaborations qu’on doit utiliser en faisant du télétravail. En particulier, les équipes habituées au travail distribué peuvent trouver relativement facile de passer au télétravail, et cela peut bien réussir à court terme si les défis évoqués ci-dessus peuvent être relevés. Cependant, si les équipes sont habituées à échanger sur place parfois la configuration entièrement distribuée peut devenir plus problématique avec le temps. En fait, même si la communication directe concerne des interactions rapides liées à des tâches qui peuvent être effectuées en ligne, beaucoup de choses se passent entre les lignes. La recherche nous montre que les facteurs de travail en équipe, tels que la sécurité psychologique ou la compréhension partagée (Edmondson, 1999; Kude, 2019), sont un fondement du fonctionnement des équipes de développement de logiciels. Dans les équipes où les membres se font confiance et se sentent en sécurité pour s'exprimer (en d'autres termes, les équipes où la sécurité psychologique est présente), la culture de l'apprentissage rapide des approches agiles peut très bien fonctionner et rendre les équipes plus fortes. Dans les équipes où la sécurité psychologique est absente, les membres de l'équipe risquent de mal interpréter un retour d'information souvent direct et parfois dur. Dans le cadre du télétravail, les malentendus et les critiques perçues comme inadéquates peuvent s'accumuler et détériorer la précieuse confiance restante. Cela risque moins de se produire dans les équipes qui ont une compréhension commune des uns et des autres, du processus de développement et du produit logiciel final. La compréhension commune doit cependant être entretenue et elle peut devenir rapidement obsolète à mesure que les circonstances changent. Il peut être délicat d'entretenir la compréhension commune de l'équipe en mode de crise.

Le développement depuis son domicile en pratique

L'exemple d'une société française de médias et de publicité illustre la pertinence de ces défis. Dans cette organisation, la norme pour les équipes de développement de logiciels était de travailler sur place. En fait, les membres de l'équipe étaient assis physiquement près les uns des autres, ce qui rendait la communication très instantanée et immédiate. J'ai eu une première conversation avec le responsable technique et "Scrum master" (un rôle clé dans les équipes Scrum qui facilite l'approche Scrum) de l'une des équipes de développement de l'entreprise peu après le début de la situation de travail forcé à domicile. À ce moment-là, la situation semblait être sous contrôle et le contexte soudain de télétravail semble moins problématique. En fait, le principal problème semblait être que les développeurs avaient des difficultés à établir les connexions à distance avec les serveurs. Avant la crise, l'entreprise était plutôt conservatrice en ce qui concerne le télétravail et la culture du “home office”, en raison de inquiétudes liées à la sécurité. Par conséquent, le premier défi était la mise en place de l'infrastructure technique pour pouvoir réellement travailler à domicile. Une fois ce problème résolu, tout semblait aller dans la bonne direction. 

Cependant, les deux conversations qui ont suivies, quelques semaines après le confinement, ont révélé des défis nouveaux et inattendus. Tout d'abord, toujours en ce qui concerne le processus de développement du logiciel, les utilisateurs finaux internes à l'entreprise pour lesquels l'équipe développait une solution spécifique n'étaient pas disponibles pour donner leur avis. Étant donné que la solution devait être utilisée "sur le terrain", il n'y avait aucun moyen d'évaluer les prototypes dans les conditions réelles, ce qui entravait l'approche de prototypage rapide que l'équipe suit habituellement. Deuxièmement, deux défis fondamentaux sont apparus en ce qui concerne l'architecture du produit. D'une part, la personne interrogée a identifié un problème assez critique de coordination entre les équipes. L'équipe a fait une mise à jour d'un composant qui était également utilisé par une autre équipe. L'équipe avait envoyé un bref message à l'autre équipe, qui a répondu positivement. Mais, probablement en raison des circonstances difficiles, l'autre équipe n'avait pas réalisé les conséquences plus larges de ce changement. En conséquence, l'autre équipe a dû faire face à la perte de données importantes et la résolution de ce problème a nécessité des efforts de coordination conséquents. La personne interrogée a expliqué qu'en temps normal, les équipes auraient eu plus de discussions sur ce changement et ses implications, et "pas seulement un message par tchat. Vous ne pouvez pas expliquer une telle complexité en une seule phrase... Le fait est que le gars est juste devant nous [normalement]". 

En revanche, étant donné l’absence de possibilités de communication ad hoc, la coordination a été reléguée aux réunions formelles. Lorsqu'une question spécifique concernant une nouvelle fonctionnalité nécessitait une coordination supplémentaire, le "product owner" s'est adressé directement à un développeur et a coordonné les activités de manière individuelle - au lieu de soulever la question lors d'une réunion d’équipe, ce qui aurait sensibilisé l'ensemble de cette dernière. Le propriétaire du produit a peut-être insisté plus que d'habitude pour cette nouvelle fonctionnalité, étant donné que l'avenir du projet n'était pas clair pendant la crise actuelle et qu’il s'efforçait de produire des résultats rapides. Dans de telles situations, il peut parfois être difficile de prévoir quelles modifications du code sont pertinentes pour le reste de l'équipe. En fait, favoriser la prise de conscience et la compréhension partagée entre les membres est l'un des points forts du développement de logiciels agiles dans des contextes de collaboration. Pour cette équipe, le changement a entraîné des difficultés de coordination en cascade qui ont temporairement affecté le flux.

Qu'arrivera-t-il aux équipes de développement de logiciels lorsque la crise sera terminée ?

Quels seront les effets de la crise à moyen et à long termes pour les équipes de développement de logiciels ? Quelles équipes vont bien gérer la situation ? Que va-t'il se passer quand les équipes retourneront à nouveau au bureau ?

Bien que ce sont des questions ouvertes qui nécessitent plus de recherche, ce qui sera probablement le cas pour les autres entreprises peut aussi être attendu pour les équipes de développement de logiciels. La crise actuelle va élargir le fossé entre les équipes qui fonctionnent bien et celles qui ne fonctionnent pas bien. Beaucoup vont peut-être avoir des difficultés dès maintenant, mais celles qui avaient du mal avant la crise auront très probablement encore plus de difficultés après. Par contre, les équipes qui travaillaient bien ensemble avant la crise peuvent même en tirer profit et revenir encore plus fortes.

Les équipes qui avaient des difficultés avec les aspects techniques et sociaux avant la crise peuvent avoir encore plus de difficultés après. Peut-être elles vont se débrouiller pendant la période du télétravail exigé. Mais la mode de crise peut avoir un effet néfaste pendant la période après-crise. Les équipes qui ne fonctionnait pas bien déjà vont avoir encore plus de mal pendant la crise actuelle car elles ne possèdent pas les architectures et démarches nécessaires, ainsi que les facteurs du travail d’équipe essentiels. Ces équipes pourront avoir encore plus de mal une fois la crise sanitaire surmontée et les équipes de retour au bureau. Pendant la crise, la communication est peut-être réduite au minimum pour la continuité de l’activité. Cela peut signifier que les démarches formelles et les décisions architecturale peuvent être contournées pour atteindre les objectifs à court terme et pour prendre la voie du moindre effort. Pendant la période du télétravail forcé, les conflits qui se profilent à l’horizon peuvent s’intensifier et nuire au travail d’équipe. Pourtant, le scénario le plus probable est que les désaccords qui auraient dû être adressés ne le seront pas ; ce qui peut causer des problèmes plus tard lorsque des conflits surgiront à nouveau. Ainsi, lorsqu'elles travaillent à domicile, les équipes qui ne fonctionnement pas peuvent non seulement accumuler une "dette technique", en termes d'obligations techniques qui devront être traitées ultérieurement (Ramasubbu et Kemerer 2016), mais aussi une "dette sociale", qui fait référence aux conséquences futures des décisions relatives aux personnes et à leurs interactions (Tamburri et al., 2015).

Les suites de la crise se dérouleront différemment pour les équipes qui fonctionnent bien, c’est-à-dire celles qui travaillent sur la base des d'architecture et processus de développement qui équilibrent la stabilité et la flexibilité ainsi que celles qui ont développé des structures et des comportements de travail en équipe solides, par exemple en développant avec succès la sécurité psychologique de l'équipe et des niveaux élevés de compréhension partagée. Ces équipes peuvent en fait être en mesure de tirer parti des circonstances particulières et de saisir les opportunités qui y sont associées. Nous avons observé l’impact de la pandémie dans nos vies personnelles sur notre bien-être. Certains individus ont moins de mal à trouver les stratégies personnelles pour gérer la crise. En tout cas, une situation inédite est susceptible de changer notre priorité et nous laisser nous concentrer sur les aspects essentiels de notre vie. Une telle augmentation de pleine conscience peut aussi être possible pour les équipes de développement de logiciels : les équipes vont peut-être améliorer leur pleine conscience partagée (Yu et Zellmer-Bruhn, 2018 ; Liu et al., 2020), c’est-à-dire "la conviction partagée par les membres de l'équipe que leurs interactions sont caractérisées par la prise de conscience et l'attention portée aux événements présents, et par le traitement expérimental et sans jugement des expériences au sein de l'équipe" (Yu et Zellmer-Bruhn 2018, p. 324). Les équipes qui ont réussi à traverser la crise peuvent disposer des ressources nécessaires pour appliquer leurs enseignements et réévaluer leurs routines, leurs processus de développement, le soutien des outils et l'architecture. Ce faisant, leurs structures de travail en équipe et leurs comportements seront probablement d'une grande utilité. En outre, les équipes qui fonctionnent bien auront réalisé qu'elles peuvent compter sur leurs relations de confiance et leurs modèles mentaux partagés et que ces facteurs de travail en équipe les aident à traverser des périodes d'incertitude et de difficultés. Cela les aidera à être encore plus attentives à ces facteurs de travail et à continuer à les chérir et à les développer.

En résumé, on peut s’attendre à des résultats intéressants quand les équipes se retrouveront après le confinement. On verra probablement que des équipes qui ont créé de la dette social et technique auront des difficultés durant une certaine période, le temps de se remettre. Ce processus va exiger la résolution des problèmes techniques et sociaux qui ont émergé pendant la période de télétravail. Les équipes qui ont bien fonctionné avant la crise vont peut-être bénéficier de cette situation extraordinaire, tel un catalyseur externe pour devenir un groupe plus attentif et soudé. Il sera intéressant d'examiner plus en détails les leçons qu’on peut tirer de la crise pour les équipes de développement de logiciels mais pas seulement. 

Réferences

Edmondson, A., 1999. Psychological safety and learning behavior in work teams. Administrative Science Quarterly, 44(2), pp.350-383.

Kude, T., Mithas, S., Schmidt, C.T. and Heinzl, A., 2019. How pair programming influences team performance: The role of backup behavior, shared mental models, and task novelty. Information Systems Research, 30(4), pp.1145-1163.

Liu, S., Xin, H., Shen, L., He, J. and Liu, J., 2020. The Influence of Individual and Team Mindfulness on Work Engagement. Frontiers in Psychology, 10, p.2928.

Ramasubbu, N. and Kemerer, C.F., 2016. Technical debt and the reliability of enterprise software systems: A competing risks analysis. Management Science, 62(5), pp.1487-1510.

Tamburri, D.A., Kruchten, P., Lago, P. and Van Vliet, H., 2015. Social debt in software engineering: insights from industry. Journal of Internet Services and Applications, 6(1), p.10.

Yoo, Y., 2010. Computing in everyday life: A call for research on experiential computing. MIS Quarterly, 34 (2), pp.213-231.

Yu, L. and Zellmer-Bruhn, M., 2018. Introducing team mindfulness and considering its safeguard role against conflict transformation and social undermining. Academy of Management Journal, 61(1), pp.324-347.