Un frein à la productivité
Dans le développement logiciel, le transfert de tâches d'une personne à une autre, pratique courante dans les organisations cloisonnées, est pointé du doigt par une analyse publiée par Scrum.org. Ce mode de fonctionnement, souvent matérialisé par un « passage par-dessus le mur » entre équipes de conception, développement, test ou déploiement, génère des pertes de temps, de connaissance et d'énergie.
Scrum.org, organisme de référence pour le framework Scrum, explique que chaque transfert introduit une rupture. Le développeur qui remet son code à un testeur doit expliquer son fonctionnement, ce qui prend du temps. Le testeur, de son côté, n'a pas le contexte complet pour comprendre les choix effectués. En conséquence, les bugs sont plus difficiles à identifier, les corrections prennent plus de temps et la motivation des équipes s'érode.
Une culture du « fini-parti »
L'analyse met en lumière une culture du « fini-parti » où chaque personne se considère responsable d'une étape seulement, sans vision d'ensemble du produit. Cela conduit à une perte de responsabilité collective et à un ralentissement global. Scrum.org recommande de favoriser des équipes pluridisciplinaires capables de mener une fonctionnalité de bout en bout, sans avoir à la passer à d'autres spécialistes.
Comment réduire les transferts
Plusieurs pistes sont avancées pour limiter les dégâts. D'abord, il est conseillé de constituer des équipes stables et autonomes, qui possèdent toutes les compétences nécessaires (développement, test, conception, déploiement). Ensuite, l'usage de pratiques comme l'intégration continue, la revue de code systématique et le pair programming permet de réduire la distance entre écriture du code et vérification. Enfin, les rituels Scrum – comme la mêlée quotidienne et la revue de sprint – offrent des occasions de synchronisation qui peuvent remplacer une partie des transferts informels.
Conséquences sur la qualité
Le coût des transferts ne se limite pas au temps perdu. L'analyse souligne qu'ils ont un impact direct sur la qualité logicielle. Un développeur qui code sans connaître les tests automatisés peut écrire un code difficile à tester. Un testeur qui n'a pas participé aux discussions de conception peut passer à côté de cas d'usage importants. En supprimant les murs, les équipes améliorent à la fois leur vélocité et leur capacité à livrer un produit sans défauts.
Un changement culturel nécessaire
Pour Scrum.org, corriger ce problème ne relève pas uniquement d'une réorganisation technique, mais d'un vrai changement culturel. Il s'agit de remplacer la logique de flux linéaire – où chaque étape est indépendante – par une logique de flux continu, où l'équipe entière partage la responsabilité du résultat final. Cette transformation passe par l'abandon du « jet par-dessus le mur » et par l'adoption d'une posture d'équipe unique, focalisée sur la valeur délivrée au client.
