fra

SCRUM : Déterminer la cause profonde d'une crise. Qui ramasse la balle ?

En regardant le championnat du monde de rugby, vous avez peut-être vu de nombreux sprints et mêlées pendant le match. Dans le langage du rugby, une mêlée est "une méthode de reprise du jeu dans laquelle les joueurs se serrent les uns contre les autres, tête baissée, et tentent de prendre possession du ballon" [réf. Wikipedia]. Il faut du temps à un profane du rugby comme moi pour comprendre cela, car cela ne semble pas logique. Pourquoi ne pas simplement ramasser le ballon et courir !

Scrum semble aujourd'hui plus lié au développement de logiciels agiles qu'au rugby. Il est présent partout et connaît un grand succès. Au sein de mon entreprise (Kepner-Tregoe (KT)), notre groupe de développement de produits a récemment mis au point une nouvelle gamme de produits... using the agile method. La clé est le progrès, pas la perfection.

Progrès - cela veut-il dire "pas le temps" ?
L'utilisation de la méthode agile peut être une voie parfaite à suivre pour de nombreuses applications. Cependant, selon mon expérience avec certaines équipes et industries, la façon dont le "progrès" est défini est préoccupante, car pour moi, le "progrès" est le critère le plus important pour la prise de décision. L'un de mes clients m'a dit : "Le marché nous demande de réagir rapidement et nous devons être en avance sur le jeu". Mais, considérez le revers de la médaille. Le développement d'un correctif pour une "cause première trouvée" n'a pas été mis en œuvre et les responsables de l'analyse des causes premières m'ont expliqué : "Pourquoi trouver la cause ? Elle ne sera pas corrigée de toute façon". Et, pourquoi devraient-ils trouver la cause si elle n'est pas prioritaire dans les sprints ? Ce qui est troublant, c'est que d'autres tâches telles que la maintenance normale sont également négligées. La raison pour laquelle on demande aux équipes de concentrer les activités de développement sur les sprints est d'obtenir un avantage concurrentiel et d'être les premiers sur le marché à introduire de nouvelles fonctionnalités.

En faisant de la vitesse le critère le plus important, on a tendance à prétendre qu'il n'y a "pas de temps" pour d'autres éléments importants. Lorsque le développement se fait sous pression, comment donner la priorité aux développements agiles plutôt qu'à l'analyse des causes profondes et à la mise en œuvre d'un correctif ? Sans parler de l'exécution d'une maintenance régulière ? Je suis d'accord pour dire que la perfection n'est peut-être pas nécessaire dans le développement de nouveaux logiciels, mais la perfection est nécessaire pour mettre en œuvre un correctif afin d'éliminer la cause première. Combien de fois l'introduction d'un nouveau logiciel échoue-t-elle parce que des problèmes cachés n'ont pas été examinés et corrigés ? Nous appelons cela crocodiles à l'affûtqui attendent d'attaquer à tout moment, surtout quand on s'y attend le moins.

Ce n'est pas une question de "manque de temps" - nous avons tous le même temps. C'est la priorité que nous accordons à certaines choses qui fait la différence.

Alors qui ramasse la balle ?

Les deux parties devraient. Je sais que cela semble contradictoire. Dans un match de rugby, une seule partie peut récupérer le ballon, mais les deux parties doivent s'efforcer d'améliorer leur tactique pour gagner.

Les responsables de l'analyse des causes profondes doivent apporter une contribution claire et concise au développement. Une description claire du problème et une cause première testée logiquement qui décrit précisément l'hypothèse montrant comment cette cause crée le problème. Cette description doit permettre à l'équipe de développement de mieux comprendre et de justifier clairement les mesures à prendre. Grâce à cette description claire, l'équipe de développement peut évaluer avec plus de précision ce qui est nécessaire pour résoudre le problème. Par exemple, plutôt que de se dire qu'il s'agit d'un bogue logiciel, l'équipe travaillera sur une cause précise, par exemple : "en fonctionnant à la vitesse xyz, la machine s'arrête car les limites ont été fixées trop strictement".

Des descriptions claires ou, comme nous le disons ici chez KT, des travaux "séparés et clarifiés" permettent également aux équipes de fixer les bonnes priorités, en examinant :
- Quel est l'impact actuel : comment affecte-t-il le cycle de développement actuel ? Si nous ne le corrigeons pas, notre nouveau développement fonctionnera-t-il toujours ?
- Quel est l'impact futur : combien de temps pouvons-nous repousser cette question jusqu'à ce que les choses tournent terriblement mal ?
- Délai : est-ce que ça rentre dans le cycle de sprint actuel, de combien de temps avons-nous besoin ?

Si les deux parties se mettent d'accord et améliorent la qualité et la tactique du jeu qu'elles pratiquent, le jeu sera bien meilleur à regarder et bien plus motivant.

Image du blog 1
Certification technique, avoir une expertise ou utiliser une expertise
Image du blog 1
La dette technique est réduite au minimum dans une culture de résolution des problèmes.

Nous sommes experts en :

Nous contacter

Pour tout renseignement, information complémentaire ou un devis