Pourquoi le “courage” est une valeur Scrum et “avoir raison” ne l’est pas

Je vois souvent des situations comme celle-ci dans les équipes logicielles:

Alice: “Nous ne pouvons pas commencer les tests car nous attendons toujours des nouvelles de Bob pour savoir quand le RC sera prêt. Il nous le fera tous savoir sur la chaîne officielle Slack. Soyez prêt. »
Bob:« Je sais que vous attendez tous le RC, mais j’ai d’abord besoin d’une confirmation de Craig, et il ne répond pas à son e-mail. »Craig:« Habituellement, c’est Dan qui prend cette décision mais il est en vacances et il ne m’a pas informé de cela lorsqu’il m’a confié ses tâches… ».

Typically , je (mal) diagnostique cela comme un problème d’ignorance. Les rôles et responsabilités ne sont pas assez clairs! Créons une autre liste de contrôle, créons un autre rôle, définissons un autre OKR. Cela aidera les gens à comprendre exactement quand ils ont raison ou tort.

Aujourd’hui, j’ai eu une petite révélation: ce n’est pas un problème d’ignorance – c’est un problème d’indécision. Souvent, nous n’avons pas la moindre idée, nous ne voulons simplement pas prendre de décision.

Le modèle mental en place dans notre industrie est que la création de logiciels est comme la fabrication de voitures électriques (ou de fusées). Il semble que nous soyons amoureux de l’idée de l’ingénieur archétypal, dont les décisions sont imprégnées de la précision rigoureuse de la méthode scientifique. Mais faire du logiciel, c’est vraiment plus jouer au rugby (malgré les clichés). C’est chaotique et désordonné. Cela dépend beaucoup plus de la prise de décision instantanée et des lectures rapides de vos coéquipiers que de votre capacité à raisonner soigneusement.

Alors, qu’est-ce qui empêche les gens de prendre de bonnes décisions locales? Même si j’ai une connaissance parfaite de la façon de faire quelque chose, j’éviterai de prendre des décisions qui pourraient me causer des ennuis si j’échoue. En fait, cette peur pourrait me laisser paralysé.

Nous avons beaucoup entendu parler de «sécurité psychologique» et de «sécurité pour échouer» récemment, mais cela se résume à quelque chose de plus simple: le courage – et cela commence avec nous en tant que praticiens agiles. Arrêtons de nous cacher derrière le mode de fonctionnement par défaut du «processus processus processus» et commençons à nous concentrer sur l’aide aux gens à prendre les décisions difficiles et significatives qu’ils sont censés prendre chaque jour.