Olivier Ledru

Les équipes et organisations qui utilisent le cadre agile Scrum espèrent toutes que les efforts porteront leurs fruits, et qu’elles seront bientôt sorties de tous leurs problèmes grâce à la magie de l’agilité. La première étape consiste généralement à appliquer un cadre de travail avec plus ou moins de rigueur. Mais cette étape est souvent vu comme un objectif à part entière et non un simple premier pas. Nous allons explorer comment sortir d’une application mécanique de Scrum pour progresser vers une utilisation performante de Scrum, en particulier par l'utilisation disciplinée d'une "Definition of Done" stricte.

J'adore les jeux de société. Quand j'étais enfant, le choix était un peu limité autour de Monopoly, Scrabble, la Bonne Paie, la Bataille Navale.

Contexte Lorsque l’on débute un projet, c’est une initiative qui est lancée sur la base d’une idée. On espère cette idée bénéfique pour l’utilisateur et rentable pour l’entreprise. Le produit résultant du projet n’existe pas encore. Mais on émet déjà l’hypothèse que l’idée est assez intéressante pour mériter un investissement en temps, moyens, formations, efforts, sueur…. Je vois des hypothèses partout ! Au lancement d’un projet, nous travaillons avec de très nombreuses hypothèses dans un environnement complexe et incertain. Il faut ici avoir conscience de l’incertitude qui nous entoure. Ainsi, on évitera de plonger dans un biais d’excès de confiance qui nous ferait prendre des suppositions pour des certitudes, même après de longues analyses du contexte. Imaginons que l’on soit très confiant, par exemple à 90% sur chaque hypothèse, et qu’on identifie initialement quelques dizaines d’hypothèses. Cela fait quand même pas mal de chance pour que les choses ne se passent globalement pas comme prévues ! La question à laquelle la « Courbe de Vérité » nous aide à répondre est celle consistant à équilibrer l’investissement en regard de la solidité des faits dont on dispose. Truth Curve selon Giff Constable. HiPPOs = Highest-Paid Person’s Opinion = Opinion de la personne la mieux payée (Cf. https://www.lamobilery.fr/blog/danger-effet-hippo-reunion ) Nos hypothèses peuvent être plus ou moins risquées, avec un gain escompté plus ou moins important. Il est primordial de lever les hypothèses à la fois les plus intéressantes et risquées rapidement avant de faire de gros investissements. Cela peut se faire progressivement et en se basant sur les apprentissages réalisés. On sort alors d’une logique binaire GO/NO GO. Refermer la boucle La démarche Lean UX nous apporte de nombreux outils pour valider de manière itérative et incrémentale nos hypothèses. Cela est heureusement réalisable bien plus rapidement qu’en développant et livrant un logiciel dans les mains de l’utilisateur. On parle alors d’« Apprentissage Validé » (Validated Learning). Il est important ici de comprendre que pour minimiser les gaspillages, le fameux MVP sera bien plus petit qu’une « première version » du produit. En effet, cette première version met souvent plusieurs semaines voire des mois à arriver dans les mains de l’utilisateur final. Les techniques les plus légères vont être de simples entretiens et enquêtes auprès d’une poignée d’utilisateurs supposés bien ciblés. Il est ainsi possible de refermer des boucles de feedback avant même d’avoir livré un incrément du produit utilisable par l’utilisateur. En quelques heures, si nos premières enquêtes nous invitent à continuer les investissements, on pourra plus tard présenter à ces utilisateurs des maquettes d’une solution en basse-fidélité puis haute-fidélité élaborées en quelques jours. Dans le cas contraire, on aura appris que nos hypothèses étaient erronées et qu’il est plus intéressant de pivoter sur d’autres idées ou d’arrêter après un investissement faible. Nous obtenons un Apprentissage Validé, avec un temps d’apprentissage (Time to Learn) record, sans même avoir fabriqué d’incrément « Terminé ». Saluons au passage les expériences qui invalident nos hypothèses car ce sont celles qui nous font le plus apprendre. En effet, elles nous prouvent que nous risquions de continuer sur une fausse route ! Pour faciliter cette acceptation et pour éviter de rentrer dans des biais cognitifs de confirmation, il est primordial que l’investissement et donc la prise de risque délibérée soit les plus petits possibles. Stop ou encore ? Après nous être ainsi assurés rapidement de la véracité de nos hypothèses les plus risquées et que la solution mérite au moins partiellement d’être bâtie, nous pourrons commencer à tester notre capacité à fabriquer un produit utilisable et de grande qualité. La fabrication du produit se fait par accumulation d’incréments « terminés », en l’enrichissant progressivement, semaines après semaines, en fonction de l’efficacité avérée de notre solution. En même temps que cette fabrication incrémentale, d’autres hypothèses sont testées, si possible sur le terrain avec les utilisateurs, par la même équipe pour continuer à découvrir des solutions. L’équipe est bien responsable de résoudre des problèmes complexes de manière émergente et non seulement de fabriquer un produit. La boucle de feedback de notre « Apprentissage Validé » se referme alors au-delà de la livraison des incréments « terminés », par collecte de données sur le terrain. On observe alors un « Time to Learn » qui va au-delà du « Time to Market », que l’on cherchera à minimiser avec des petites livraisons très fréquentes et très ciblées pour faciliter la récolte de données. Conclusion Sur votre produit, quels sont les travaux dont la valeur n’est pas certaine à 100 % ? Quel est le principal problème que vous cherchez à résoudre ? Quelles sont vos hypothèses de travail ? Si vous souhaitez explorer plus en détail ces concepts, n’hésitez pas à nous contacter pour vous inscrire aux prochaines sessions de formation « Professional Scrum with UX ». Vous y découvrirez comment exprimer vos hypothèses (problématique business ; impact business ; bénéfices utilisateurs…) ainsi que la manière de les exploiter pour maximiser la valeur de votre solution pour l’utilisateur.

Working overtime in stressful situations is not a viable long-term remedy and should not be seen as a professional solution, but as a warning signal to be heard courageously.

In your Scrum Master mission, a manager has asked you to support the implementation of an Agile framework in a team that, according to him, really needs it!

How to use "Visible Status" with the information radiator to help the call to action? How to use explicit indicators to make decisions?

Your Sprint is over. Your increment is “Done”, you have coded cleanly, your unit tests and integration tests are bright green, you are proud of your work. The Sprint Review is running smoothly. The Sprint Retrospective allows the team to find 1 or 2 areas of improvement without revolutionizing the world.

The Scrum Master is often expected to facilitate and animate every Scrum events. But, according to the Scrum Guide, the role of the Scrum Master regarding the different events is to ensure that the event takes place and that attendants understand its purpose.