Vélocité négative : comment relever la limite de complexité

Atteindre la limite de complexité peut sembler inévitable, mais certains signes indiquent que les équipes s'en approchent. Tout d'abord, il convient de préciser qu'il n'y a aucune métrique absolue permettant de savoir à quel point vous êtes proche de la limite de complexité, mais les indicateurs suivants peuvent vous donner une idée.

L'indicateur le plus clair qu'une équipe a atteint la limite de complexité ? Elle passe plus de temps à gérer la complexité organisationnelle qu'à résoudre les problèmes complexes sur lesquels elle devrait se concentrer. L'analyse des métriques DORA du délai d'exécution des changements (vitesse) et du taux d'échec des changements (qualité) montre si les équipes ralentissent ou accélèrent au fil du temps. Même si d'autres facteurs influencent ces métriques, elles constituent un bon indicateur de l'efficacité de l'équipe.

La satisfaction des développeurs est un autre indicateur de la complexité organisationnelle à laquelle les équipes de développement sont confrontées. Plus que tout autre profil, les personnes qui occupent des rôles de développeurs aiment passer leur temps à résoudre des problèmes complexes, et détestent les tâches inutiles qui se présentent. Le faible niveau de satisfaction des développeurs indique clairement que la complexité organisationnelle pose problème à votre équipe de développement.

Lorsque les entreprises se rendent compte que leurs équipes sont submergées par la complexité, elles lancent souvent un « projet de simplification » visant à rétablir la simplicité au sein de leur organisation. La simplification est une stratégie perdante pour deux raisons. Tout d'abord, la complexité augmente plus vite qu'une organisation ne peut simplifier son environnement. Ensuite, ces « projets de simplification » opèrent au sein même de l'environnement complexe qu'ils visent à simplifier.

Un point de départ commun pour la simplification consiste à réduire le nombre d'applications en les désactivant ou en les consolidant dans la mesure du possible. La désactivation d'une application exige que l'équipe comprenne toutes les dépendances en amont et en aval, qui utilise l'application, comment remplacer la fonctionnalité, où et comment les données seront archivées ou migrées. Elle doit également s'occuper de toutes les autres complications engendrées par ce type de tâche. Malheureusement, la réduction de la complexité n'est pas proportionnelle à l'investissement considérable en efforts nécessaires pour y parvenir. Il y a une limite à la quantité d'applications qu'une entreprise peut désactiver sans affecter l'activité principale ou l'expérience utilisateur, mais il n'y a pas de limite au nombre de nouveaux composants logiciels que les ingénieurs peuvent créer. Au cours des 12 mois nécessaires à la désactivation d'une application, il est probable que des centaines de nouveaux microservices aient été créés. Étant donné qu'un environnement technologique sain se développe au fil du temps, limiter l'environnement à un nombre fixe d'applications ou de composants logiciels pour réduire la complexité n'est pas pratique.

Les projets de simplification comprennent généralement le remaniement de la structure organisationnelle afin de simplifier le flux de communication. Les structures organisationnelles les moins compliquées impliquent de grandes équipes hiérarchiques où tout le personnel se trouve dans les mêmes locaux. Les structures organisationnelles les plus complexes impliquent de petites équipes distribuées et autonomes. La loi de Conway nous montre que les grandes équipes hiérarchiques sont susceptibles de créer des applications monolithiques, tandis que les petites équipes distribuées sont susceptibles de produire des applications à l'aide d'architectures modulaires, comme des microservices. La production rapide de logiciels de haute qualité est rendue possible par des modèles d'architecture modulaire tels qu'une architecture de microservices. Cela signifie qu'une structure organisationnelle plus complexe est plus susceptible de garantir la réussite. Même si la « simplification » de la structure organisationnelle simplifie la compréhension, elle va à l'encontre de l'objectif ultime du projet de simplification.

La simplification est importante et utile, mais il est préférable de l'intégrer en tant qu'amélioration continue pour les équipes de développement (et les équipes d'équipes) plutôt que comme une activité ponctuelle. La simplification peut retarder l'atteinte de la limite de complexité, mais ne redonnera pas à une organisation les libertés rythmées d'un environnement de start-up.

Pour retrouver l'efficacité de l'équipe de développement, les entreprises doivent relever la limite de complexité. Cette action implique essentiellement d'augmenter le degré de complexité organisationnelle que chaque équipe peut gérer avant que cela n'ait un impact sur la satisfaction au travail, ainsi que sur la qualité et la vitesse avec lesquelles l'équipe livre des logiciels.

L'ingénierie de plateforme est un concept important qui vise à relever la limite de complexité au sein d'une organisation. Des équipes d'ingénierie de plateforme solides se concentrent sur la réduction de la charge cognitive des équipes de développement, en faisant abstraction de la complexité de l'organisation dans leur travail quotidien. Lorsqu'elle est correctement implémentée, ce type d'ingénierie permet aux équipes de rééquilibrer l'essentiel de leurs efforts en faveur de la résolution des problèmes les plus complexes, tout en consacrant moins de temps à la complexité organisationnelle.