Le développement de logiciel est un effort complexe dans lequel les suppositions et les décisions devraient être prises le plus tard possible.

The Best Laid Plans often go awry

https://www.scrum.org/resources/blog/best-laid-plans-often-go-awry par John Gillespie

Quand Henry Ford a conçu ses usines en 1913 pour construire la Modèle T, il a réduit le temps nécessaire pour assembler une voiture de plus de 12 heures à 2 heures 30 minutes.  Ce processus a permis la production d’une automobile à prix ciblé pour “le travailleur”.  Toutes les voitures avaient la même conception et toutes étaient peintes en noir.

Les designs préconfigurés fonctionnent quand les prévisions rencontrent les attentes (qui en 1913 aurait demandé une voiture rouge ?) et quand un spécialiste peut remettre son travail au suivant sans aucune perte de temps dans la transmission.

Quand une société est dans le business de produire des produits et des services innovants, ses plans reposent sur une ou plusieurs estimations et suppositions.   Ces évaluations ne sont rien de plus que des probabilités.  Baser un plan de projet sur des suppositions exige que votre système puisse manager les changements.

Marie Poppendieck a exposé dans Lean Software Development, An Agile Toolkit, “le simple fait mathématique ici au travail est que toute variation est toujours amplifiée comme elle déplace le long d’une chaîne d’événements connectés. Une petite variation dans une étape peut représenter une énorme variation cinq étapes plus loin”.  Donc la question reste entière quant à pourquoi les managers continuent à planifier des projets en se basant sur des suppositions séquentielles.

Pour comprendre comment un changement inattendu peut causer des retards significatifs en aval, visualisez une chaussée très occupée avec des voitures se déplaçant selon la limitation de vitesse.  Le trafic s’écoule régulièrement jusqu’à l’entrée d’un nouveau véhicule ou autre événement qui fasse qu’un conducteur actionne ses freins.  Le trafic sur la chaussée ralentit ou s’arrête alors pendant une brève période puis recommence à s’écouler de nouveau sans signe apparent de pourquoi il a ralenti en premier lieu.  L’exemple de cette route illustre comment, à moins que les systèmes ne soient conçus pour se concentrer sur le flux, ils ne fonctionneront pas efficacement à pleine capacité.  Parce que le développement de logiciel est un effort complexe dans lequel les suppositions et les décisions devraient être prises le plus tard possible.  Le fait de prendre des décisions au dernier moment possible permet à l’équipe Scrum de changer pour travailler sur les articles d’arriéré de produit de plus de valeur en fonction des données les plus récentes.

L’empilement de beaucoup de suppositions l’une après l’autre dans un plan de projet réduit significativement la probabilité d’un résultat positif.

Par exemple, considérez cinq tâches tout d’une probabilité de 90 % d’achèvement en une semaine: (0.9 * 0.9 * 0.9 * 0.9 * 0.9 = 0.59). Dans ce cas, nous avons cinq tâches sur lesquelles nous nous sentons confiants, mais le résultat cumulatif est que nous sommes à seulement 59 % de probabilité de finir ces cinq tâches en cinq semaines.  Je soutiendrais que basé sur mon expérience de professionnel en management de projet, il est aussi peu probable que cinq tâches séquentielles atteignent jamais chacune un niveau de confiance de 90 %.  Alors, êtes-vous encore étonné quand vous lisez Standish Group’s Chaos Report qui indique qu’approximativement 70 % de tous les projets des technologies de l’information échouent à atteindre leurs objectifs et sont significativement en retard et sur-dépensent ?

Ceci n’empêche pas que vous devriez adorer les statistiques 🙂

La meilleure façon d’optimiser la livraison de valeur est de faire des tâches ajoutant une valeur visible pour les parties prenantes.  La documentation de chaque flux de valeur mettra en évidence l’avancée et les retards entre les transitions.  En évaluant quantitativement des activités du flux de valeur, le coût des retards devient aussi visible.  Cette visibilité aidera l’organisation à déterminer où la constitution d’équipes fonctionnelles transverses améliorera immédiatement les temps de réponse.

L’utilisation de Scrum pour rendre ces inefficacités visibles est seulement le premier pas.

Le leadership a-t-il le désir et l’engagement d’effectuer le changement ?  Craig Larman, l’auteur des Laws of Organizational Behavior, a observé que les organisations sont implicitement optimisées pour éviter de changer les positions de statu quo et les structures de pouvoir. Il a aussi noté que si vous voulez changer la culture d’une société, vous devrez changer la structure de votre organisation parce que la culture/comportement et la mentalité suivent les systèmes organisationnels et leur design.

Les organisations comme des sociétés d’assurance et banques ont typiquement les silos de spécialisation fortifiés autour des applications, technologies et fonctions.  Chacun de ces départements a développé des règles soigneusement travaillées et des procédures interdisant le changement.  Ces processus administratifs ont pour conséquence fortuite de perturber le flux de valeur qui va du concept à la livraison au client.

Marie Poppendieck a décrit cette situation Lean Software Development: An Agile Toolkit, “la règle établie pour résoudre un problème renforcera souvent le problème, créant une spirale vers le bas : Comme un problème empire, les managers appliquent encore plus agressivement la même politique qui cause le problème.”  La mise en place d’équipes fonctionnelles transverses qui ont toutes les compétences pour achever le travail sans avoir à traverser des silos fonctionnels aura un impact étonnamment positif sur la capacité des organisations d’améliorer la qualité et le temps nécessaire pour commercialiser.

Votre direction a-t-elle le courage et l’engagement d’entreprendre le dur labeur d’éliminer les processus et les procédures qui n’ajoutent pas de valeur ?

La plupart des sociétés considérant l’adoption de Scrum devront changer leurs structures organisationnelles pour soutenir des équipes fonctionnelles et transverses autonomes.  Si la structure organisationnelle ne change pas, les comportements ne vont pas probablement changer.  Si votre modèle business dépend de l’innovation, ce changement devrait être d’une priorité supérieure.