Un des grands défis de l'Agile est d'apprendre à l'organisation à affronter ses "crises" dans un mode "résolution de problèmes" et transformer l'incident en opportunité d'apprentissage et de progrès.
Classiquement, un incident business surgit : un client fait un retour négatif sur une fonctionnalité, menace de se désabonner si on ne corrige pas rapidement (genre dans le mois) le problème.
On peut vite partir "en vrille" : qui a fait ça ? qui est incompétent ? Le sujet est en général géré hors du cadre strict du projet technique et il faut commencer à se justifier... c'est là que l'organisation échoue. On met en place des solutions "quick win" qui cassent tout le processus agile en place et démotive les protagonistes... bref, c'est facilement le mauvais chemin qui est suivi.
Que faut il faire ? En fait cela semble assez évident quand on prend un peu de recul sur la situation... et que l'on applique la philosophie Agile : C'est à l'équipe de résoudre ses problèmes.
- un problème prioritaire survient : on le lève au PO. C'est un feed back client qui est bienvenu... puisque c'est justement un des principes agile que d'attendre le feed back business pour s'adapter au lieu de monter des usines à gaz qui répondent à tout à des coûts prohibitifs.
Le PO intègre alors sa prise en charge pour le Sprint suivant. Cela lui laisse en général le temps de réfléchir avec l'équipe à la bonne réponse à apporter et peut échanger avec les différents acteurs (client, équipes d'experts, équipe technique).
Au final c'est l'équipe qui est challengée pour trouver une solution au "problème" remonté par le client et qui va se forger une nouvelle expérience qui va la faire progresser. La dead line client peut alors être vécue comme "un challenge" et non comme un vexation (on a développé de la m....).
Au final il est à parier que l'équipe saura produire une solution optimale qui répondra au besoin du client et l'équipe sortira grandie de cet épisode, prête à relever le "prochain incident business"
Hello world!
Il y a 2 ans
