L'agilité suggère que les échecs des équipes doivent être courts en terme de durée, pour qu'elles puissent apprendre rapidement de leurs erreurs. L'apprentissage par l'échec est une approche, mais on peut aussi apprendre rapidement de ses succès, à travers l'expérimentation ou en utilisant un plan d'acquisition des connaissances.
Dans le post de blog stop failing so fast, Sami Honkonen nous explique pourquoi l'objectif n'est pas d'échouer mais de réussir:
Échouer "rapidement" ne signifie pas forcément que votre échec doit être le plus court possible. Il est facile d'échouer vite. La question est d'échouer vite et bien mais dans l'optique de réussir. Si vous ne cherchez pas la réussite, votre approche n'a pas de sens.
Comme Sami le décrit, les expériences nous aident à apprendre et à augmenter nos chances de succès:
Lorsqu'on apprend à faire face à nos erreurs de manière productive, elles deviennent un atout. Pour tester une idée (ou une hypothèse), on définit une expérience, on agit en supposant que cette hypothèse est vraie et cela nous motive, comme si on avait la conviction que cela fonctionnera. Si ce n'est pas le cas, on en tire des enseignements. Il faut réessayer de manière systématique.
Jerry Neumann affirme qu'on ne peut pas apprendre de l'échec, mais uniquement du succès:
Tout système complexe est trop compliqué pour l'assimiler par l'échec. On peut apprendre quelques trucs comme: "ne pas dépenser tout son argent pour des chaises fantaisie" ou "ne pas embaucher son compagnon de beuverie comme EVP (Earned Value Professional) pour le Business Development". Mais vous pouvez aussi passer votre vie à apprendre de toutes les erreurs que tous les fondateurs de startups ont faits à travers l'histoire, et je vous garantis que lorsque vous fonderez votre propre entreprise, vous en découvrirez de nouvelles. (...)
On devrait plutôt essayer d'apprendre des succès. Les entrepreneurs que j'ai connu et qui ont réussi, ont eu la possibilité d'identifier un ou plusieurs échecs, et d'en ressortir les choses qui ont été bien faites. Ce sont sur ces points positifs qu'ils se sont focalisés.
"Nous apprenons beaucoup de nos succès comme de nos échecs et je suppose que nous apprenons bien plus" a déclaré Bruce Nussbaum. Dans son poste de blog stop fetishizing failure, il propose un "play mode" pour faire face aux problèmes et apprendre:
L'échec est généralement associé à la résolution d'un problème. On suppose qu'il y a une solution adaptée à un problème, et si on ne peut pas la trouver, on échoue. Mais que faire lorsqu'on ne sait même pas identifier les problèmes ou qu'il y a plusieurs façons de les traiter ? Je préfère le "play mode" qui consiste à relever les défis. Lorsqu'on joue à ce jeu là, il y a des règles, mais elles changent au fur et à mesure de la partie. Il y a plusieurs façons de jouer au jeu, différentes façons de gagner. Quand quelque chose ne fonctionne pas, on en essaye une autre. On contourne les obstacles. Est-ce un échec? Je ne pense pas.
Michael Plishka a partagé son point de vue sur le sujet comme un moyen d'apprendre plus vite dans son poste de blog innovation - it was never about failure. Sa vision de l'apprentissage par l'échec est:
L'échec, comme Nussbaum le souligne dans l'article ci-dessus, est en effet douloureux et peut être un facteur limitant. Il y a une finalité à l'échec à long terme qui est impitoyable. Quand un pont "échoue", il s'écroule et des gens sont blessés. Quand il y a un "échec" de puissance, l’électricité n'est tout simplement pas là. Les échecs sont des absences de réussite, et comme un espace vide, ils n'apportent aucune information, hormis qu'il n'y a pas de succès.
Et sa vision de l'apprentissage par le succès est:
Le succès (…) n'a rien (…) d'enrichissant si tout fonctionne mais qu'on ne sait pas pourquoi. On est gai comme un pinson tant qu'on pense que tout va bien, jusqu'à ce que les choses aillent mal. Si on ne retient rien de ses échecs ni de ses réussites, comment apprend-on ?
Michael a répondu:
On apprend par ses actions, par sa curiosité, en "bidouillant", en expérimentant. Si on se permet de laisser nos échecs et nos réussites "à vide", il n'y a plus de possibilité d'apprendre, ni de se développer. C'est seulement quand on prend du recul et qu'on se demande : "Où je vais? Comment j'y arrive? Comment cet élément va pouvoir m'aider ou me poser problème?" qu'une conception innovante peut voir le jour.
Al Shalloway nous rappelle que l'échec n'est pas un but, et suggère de se concentrer sur un apprentissage rapide dans son blog why I hate "fail fast" and "good enough":
Peu importe comment vous le qualifiez, l'échec a une connotation négative. On ne recherche pas l'échec. Personne n'est fier d'un échec, bien qu'on puisse être fier de lutter contre. Le simple terme "échec rapide" révèle qu'on ne veut pas que l'échec dure trop longtemps - on veut passer outre le plus rapidement possible. La vérité, ce que nous voulons, c'est apprendre rapidement. Corriger rapidement si on est "hors course". On n'envisage même pas de sortir de la partie sur un échec. Avec cette attitude, on n'échoue jamais. Échouer rapidement n'est pas le but. Apprendre rapidement l'est.
Au lieu de subir des échecs et d'en tirer des leçons, on peut planifier un apprentissage comme le décrit Alistair Cockburn dans son rapport how "learn early, learn often" takes us beyond risk reduction où il explore des approches pour apprendre plus tôt dans le développement du produit:
Le problème n'est pas que l'apprentissage ne se fait pas suivant l'approche traditionnelle, mais qu'il intervient à l'intégration et de nouveau, à la vente, c'est-à-dire tard. Ce sont souvent les premiers moments où les membres de l'équipe doivent mettre leurs idées en commun, et la première fois que le client, l'utilisateur ou l'acheteur peuvent voir le nouveau système.
Il mentionne quatre catégories de connaissances que les projets doivent acquérir pour couvrir les risques au cours du développement.
Quel est la bonne chose à développer.
Combien le développement va coûter.
Si l'équipe est la bonne, comment ses membres peuvent travailler au mieux ensemble.
Où se trouve les imperfections techniques de leurs idées.
Pour permettre l'apprentissage au plus tôt, les activités doivent être inclues dans le plan du projet. Alistair décrit comment cela impact le plan:
"L'ancien" style, encore fréquemment utilisé, de planification de projet est une liste des tâches à accomplir pour développer le système. Une méthode efficace, rapide et peu coûteuse de planification est le type "Blitz Planning" AC-bp. Ce plan de projet conventionnel fournit toujours un bon point de départ, en permettant d'avoir un aperçu sur ce qui va être impliqué dans le développement du système et en estimant la taille approximative et la difficulté de l'effort à fournir.
Le plan de projet le plus récent, le style agile, est simplement une énumération des fonctionnalités ou des user stories intégrée dans une seule liste, généralement avec l'élément dont la valeur est prioritaire pour l'entreprise placé en haut de la liste (voir ci-dessus les raisons pour lesquelles ce n'est pas forcément le meilleur ordre de priorité).
L'approche d'acquisition des connaissances, à l'inverse, débute par un brainstorming à propos des quatres catégories de connaissances qui doivent être acquises, ainsi que l'ensemble de départ des fonctionnalités devant être livrées, ce qui fait cinq axes de travail possibles. Ils sont habilement reliés les un aux autres à travers une séquence de tâches visant à réduire les risques, fournir des informations cruciales, et développer le produit de façon optimale.
Qu'avez-vous fait pour apprendre tôt et rapidement?