Récemment, j’ai redécouvert l’atelier « the anti problem » de Game storming, mais pour un contexte un peu différent que celui décrit dans le livre : les rétrospectives agiles.
Au passage, ce livre est une mine d’or pour concevoir vos ateliers collaboratifs.
Un peu de contexte d’abord
C’est un atelier permettant à une équipe travaillant déjà sur un problème, mais étant à court d’idées, de trouver d’autres solutions. Le format consiste globalement à :
- Prendre le problème que l’on a à résoudre
- Formuler la contraposée du problème
- Essayer de résoudre ce nouveau problème
- Le reste dépend de vous !
Un exemple pour une rétrospective
Imaginons un projet Scrum où il est difficile de mettre en place des démos, pour diverses (bonnes) raisons : contexte avec peu de clients, répartis dans le monde, plutôt des prospects sur un marché agressif…
Bref pas l’idéal pour faire des démos avec les futurs utilisateurs. Le problème est donc de ne pas pouvoir avoir de feedbacks réguliers d’utilisateurs sur ce que nous produisons.
C’est là que l’anti problème arrive
On pose la question simple. C’est quoi ton anti problème ?
La contraposée de ce problème serait d’avoir des démos qui ont bien lieu, avec beaucoup d’utilisateurs et trop de feedbacks ! Difficile même de tout prendre en compte.
L’équipe imagine en rétrospective des solutions pour ne plus avoir autant de retours lors de ces démos. Et pourquoi pas ne plus en avoir du tout (pour se débarrasser de la démo) ?
Comment faire pour capter ces informations avant la démo, voire, faire bien du premier coup ?
Bien sûr, les solutions vont dépendre du contexte, on évoquera surement du maquettage, du prototypage, de meilleurs critères d’acceptation, mais aussi, on l’espère, des solutions plus innovantes spécifiques à l’équipe Scrum.
Le bilan
Un problème sans solution est un anti problème mal posé.
Citation (personnelle) d’Albert Einstein
Bien qu’il semble un peu compliqué à introduire auprès des équipes, j’aime bien cet atelier car il force à s’extraire de la solution classique qui ne marche pas, à reconsidérer le besoin initial qui nous a conduit à la solution classique, et à repenser d’autres solutions.
Avec une approche « Problème », on serait tenté de mettre en place une démo coûte que coûte, au risque d’avoir une solution artificielle, à base de visio conférence par exemple ou de démo par le Product Owner sans l’équipe, en suivant les contraintes des clients, en décalé des sprints.
Avec une approche « Anti problème », on dépasse la solution (la démo), pour se concentrer sur le pourquoi (converger vers la bonne solution au plus vite) et cela passe par d’autres solutions.
Et toi, c’est quoi ton anti problème ?
Hey, vous avez lu mon dernier post ? C’est sur la prochaine formation Lean startup !