Olivier Ledru (he)

Selon le Guide Scrum (version 2020), le Scrum Master a pour objectif de s’assurer que le cadre Scrum est compris et appliqué de manière efficace, par la Scrum Team ainsi que par les parties-prenantes. Cela implique que la facilitation des événements n'est pas la chasse gardée du Scrum Master, bien au contraire !

A quoi correspond la facilitation dans une Scrum Team ? Qui s'assure que les événements sont correctement facilités, et comment ? Comment le Scrum Master peut servir la Scrum Team en passant le relais à ses co-équipiers ?

TL-DR Kanban et Scrum sont deux outils qui se complètent très bien. L’un apporte des informations pour analyser la performance du flux de création de valeur, l’autre apporte des artéfacts et des boucles de rétroaction pour rendre transparent la performance de vos processus. Introduction Tôt ou tard, les équipes “Agiles” s’orientent sur le choix de processus et stratégies pour remplir leur mission, par exemple en retenant un cadre ou une méthode reconnus. Une routine s’installe assez rapidement, laquelle endort la vigilance de l’équipe. On observe en particulier des équipes qui installent Scrum ou Kanban et qui stagnent rapidement. Des failles apparaissent mais l’équipe ne les voit pas ou n’arrive pas à les combler avec ses outils habituels. Comment maintenir voire relancer l’amélioration continue ? Quelles pourraient être les prochaines étapes de ces équipes ? Kanban puis Scrum Certaines équipes font le choix d’utiliser Kanban pour rendre transparent le flux de création de valeur en introduisant un système fonctionnant en flux tiré et en limitant le travail en-cours entre une étape de début et une étape de fin. Pour que Kanban fonctionne bien, il est nécessaire d’avoir une rigueur et une discipline fermes, sous peine de n’avoir aucun gain voire de revenir aux anciens travers. Malgré la bonne volonté des membres de l’équipe, qui va garder la tête froide pour que cela ne se produise pas, que l’équipe sorte la tête du guidon ? Kanban ne prescrit aucun rôle. Mais pour autant, ne serait-ce pas une bonne idée qu’une personne soit identifiée explicitement pour s’assurer que les processus choisis sont bien utilisés, que les engagements de qualité sont au niveau requis par le produit, que la cohésion de l’équipe résiste aux tempêtes ? Soyons fous, appelons cette personne “Scrum Master” ! La focalisation sur le flux de valeur peut donner l’impression à l’équipe de n’être qu’une simple “Feature Factory” pour laquelle l’enjeu est juste d’assurer que le débit de travail est élevé. L’équipe perd le sens de sa mission par manque d’objectifs à court et moyen terme. Ne serait-ce pas une bonne idée de rendre explicite ces objectifs ? Soyons fous, appelons-les “Sprint Goal” et “Product Goal” ! L’équipe rencontre ses partie-prenantes de temps en temps. L’équipe se rassemble de temps en temps pour clarifier ses objectifs et pour analyser son propre fonctionnement. L’équipe comprend l’intérêt de tous ces événements, non prescrits par Kanban mais qui sont sains pour maintenir en place un système empirique. Pourquoi ne pas cadencer ces événements et apporter le confort d’une certaine régularité ? Appelons cette cadence un “Sprint” ! Enfin, l’équipe rencontre des difficultés à ses étapes de début et ses étapes de fin. Les débats sur la clarification des priorités, les choix des prochains items sont souvent difficiles. L’équipe est mise sous pression par toutes les parties-prenantes du produit qui veulent toutes que leurs désirs soient satisfaits en priorité. Comment trancher dans ces choix stratégiques délicats ? L’équipe se sent-elle légitime pour le faire ? Kanban ne répond pas à ces questions et laisse l’équipe déterminer quelle heuristique utiliser, que ce soit en tirant aux dés, en prenant les demandes des clients par ordre alphabétique ou chronologique. Qu’en est-il en sortie du tuyau ? Quand est-ce le bon moment pour livrer le produit aux utilisateurs ? Qui va trancher pour décider cela ? L’option proposé par Scrum est ici de faire incarner la responsabilité de ces choix par une personne unique, laquelle travaillera en collaboration avec tous les acteurs pertinents mais avec le mandat nécessaire pour décider et ainsi éviter les discussions interminables. Appelons cette personne “Product Owner” ! Voilà quelques pistes qui illustrent en quoi une équipe qui utilise Kanban peut bénéficier des apports de Scrum pour franchir un nouveau cap. Les équipes utilisant déjà Kanban pourront ici réfléchir aux apports des autres éléments de Scrum dans leur contexte. Scrum puis Kanban De nombreuses équipes font le choix d’utiliser le cadre de travail Scrum. Malgré leur bonne volonté, malgré le strict respect des règles du jeu du cadre, tout ne se déroule pas toujours pour le mieux. Le flux de travail progresse plus de manière visqueuse voire chaotique que véritablement fluide. En premier lieu, le management visuel est sous-exploité et il n’est peut-être pas assez explicite. Scrum apporte les boucles de feedback et trois artefacts minimaux, mais Scrum est surtout un conteneur utilisé pour rendre transparent l'efficacité de vos processus. On peut donc y ajouter d’autres éléments, sans dénaturer Scrum. Il est fréquent par exemple que le travail n’avance pas toujours de manière très fluide au sein du Sprint. Les limites d’en-cours au sein du Sprint ne sont pas explicites et de ce fait, les débordements passent inaperçus et ne déclenchent pas les discussions voire les adaptations requises. Chaque Développeur a tendance à travailler sur un item qu’il affectionne sans vraiment tenir compte de ce que font ses co-équipiers. Tout le monde est occupé, le travail avance, mais les items tardent à se terminer, mettant ainsi en péril l’atteinte du Sprint Goal. Et si les Développeurs utilisaient une stratégie de visualisation de leur travail pendant le Sprint, afin de détecter en temps réel les goulets d’étranglement, les items qui traînent et les blocages, afin d’y réagir plus rapidement ? La prédictibilité (l'Art subtil de répondre à LA question "Dis papa, c'est quand qu'on arrive ?") est également mise à mal par les équipes Scrum qui utilisent des métriques peu fiables, telle que la vélocité qui est un cumul d’estimation et que personne ne peut interpréter correctement en dehors de l’équipe. Kanban propose d’utiliser quelques métriques (travail en cours ; âge des items en cours ; débit ; temps de cycle) qui sont aisément compréhensibles par toute l'équipe mais aussi par les parties-prenantes. Ces métriques permettent de faire des simulations statistiques apportant des réponses probabilistes (nous avons 85% de chance de terminer 42 items d'ici Noël ; lorsque nous nous engageons à travailler sur un item, celui-ci a 85% de chance d'être terminé en moins de 8 jours) bien plus satisfaisantes. Afficher un intervalle de temps avec une probabilité est nettement plus pertinent que de donner des réponses binaires sur des dates possibles de livraison d'un incrément. Et après ? Il est fort probable qu’une équipe réellement performante utilise plusieurs outils. En particulier Scrum et Kanban se combinent à merveille. Bien sûr, cela n’empêche pas d’utiliser encore d’autres outils tels que TDD ou Pair-programming empruntés à XP (http://www.extremeprogramming.org/rules.html ; https://www.scrum.org/resources/blog/scrum-and-extreme-programming-xp ). Dans tous ces cas, ces processus ne sont pas prescriptifs quant à la cadence de déploiement des incréments dans les mains des utilisateurs. Scrum apporte une cadence de boucle de rétroaction sur le produit et le process. Kanban aide à améliorer le tuyau que nous maîtrisons, de l’étape A à l’étape B, il nous reste à clarifier A et B. Faisons de notre mieux en étant pleinement conscients de nos choix. Conclusion Expérimentez, apprenez à utiliser plusieurs outils, puis déterminez ceux qui conviennent le mieux dans votre contexte. Ne vous arrêtez pas à votre outil favori habituel. Ne choisissez pas entre fromage ou dessert, prenez fromage ET dessert. Enfin, n'hésitez pas à me contacter pour vous aider à mettre en place Scrum ET Kanban dans vos équipes, en participant à mes formations https://www.scrum.org/PSK

TL-TR La réussite de l’entreprise est directement liée la satisfaction des utilisateurs aujourd’hui mais aussi dans la durée. Pour assurer cette réussite, l’implémentation de différents « Key Value Measures » pour piloter ensemble les quatre « Key Value Areas » proposés par « Evidence-Based Management » offre un pilotage avec une vision globale de la situation, approche nettement plus pertinente qu’une optimisation locale portée par les KPI habituels. Introduction Les équipes ont des objectifs à atteindre, des produits à réaliser, des services à délivrer. Il est normal de chercher des indicateurs permettant de suivre la progression du travail. Surtout ces indicateurs servent de base aux discussions et permettent de clarifier les adaptations requises. En effet, ces indicateurs doivent servir à ajuster la trajectoire lorsqu'elle dévie dangereusement de l’atteinte des objectifs. Pour piloter cette trajectoire, l’équipe a besoin d’une vision transparente de son avancement vis-à-vis des objectifs. Les « Key Performance Indicators » généralement utilisés n’apportent pas un degré suffisant de transparence car ils n’exposent qu’une face du contexte, voire deviennent dangereux car ils nous induisent en erreur en nous faisant négliger nos angles morts. Le problème exposé par l’optimisation locale des KPI Par définition, les « Key Performance Indicators » prétendent mesurer les « performances » du système. Mais qu’entend-on par « performance » ? Souvent, la performance est vue comme la capacité de production du système, l’atteinte d’un résultat voire la finalisation d’un produit. Le dictionnaire Larousse nous propose : • Ensemble des qualités qui caractérisent les prestations (accélération, vitesse maximale, autonomie, etc.) dont un véhicule automobile, un aéronef sont capables. Le leitmotiv devient d’en faire toujours plus ! L’équipe s’attache alors à « accroitre » ses performances et surtout à afficher des KPI plaisantes afin d’éviter les questions et discussions fâcheuses voire confrontantes. Le reste devient accessoire, on se complait dans des "Vanity Metrics" pour se cacher derrière des tableaux affichant des informations rassurantes. Ces "Vanity Metrics" nourrissent des jeux politiques et de pouvoir dans lesquels l'important est de ne pas perdre sa place ou sa crédibilité, plus que d'échanger ouvertement sur la réussite du collectif. Or, l’accroissement des performances d’une équipe ne garantit malheureusement pas son succès, juste que le produit résultant du travail de l’équipe sera peut-être réalisé plus rapidement. Il est aisé de courir de plus en plus vite, vers l’échec du produit. Comment faire pour éviter ces biais et avoir une vision plus globale du système ? Elargir la vision avec les KVA & KVM Avoir des indicateurs liés à la capacité de production d’une équipe est pertinent, à condition que l’enjeu ne soit que d’accroitre cette capacité. Mais est-ce vraiment notre objectif, notre critère de réussite ? Est-ce bien là qu'il faut focaliser notre attention et nos efforts ? Les conditions de réussite de l’équipe sont liées également à sa capacité à mettre à disposition ses livrables dans les mains de l’utilisateur, et ainsi que celui-ci tire un bénéfice de l’utilisation du produit. L'intérêt du produit pour l'utilisateur est de lui rendre service, en lui faisant gagner du temps, de l'argent, de la sécurité, du confort, du plaisir... Enfin, la réussite dans le temps nécessite de se questionner en permanence sur l’écart entre la satisfaction actuelle des utilisateurs et la satisfaction potentielle que l'on peut espérer en poursuivant nos efforts. On voit se dessiner ici quatre quadrants complémentaires, dont deux sont liés aux capacités de production et de livraison du système (A2I et T2M) et les deux autres sont liés à l’accueil de notre produit sur le marché, dans l’instant présent et dans la durée (CV et UV). Il est toujours conseillé de focaliser les efforts. Vouloir régler tous les problèmes en adressant les quatre quadrants en même temps est maladroit. Se focaliser sur l'ajustement d'un seul paramètre permet de tirer des conclusions bien plus clairement que lorsque plusieurs paramètres ont été modifié en même temps. Ainsi, en fonction du contexte, il sera nécessaire de choisir lequel de ces quatre quadrants mérite l’attention et les prochains efforts, tout en surveillant les impacts sur les trois autres. Bien sûr, le contexte complexe dans lequel évolue l’équipe nous invitera régulièrement à reconsidérer la trajectoire et potentiellement à se focaliser sur un autre quadrant. Cette vision beaucoup plus globale du système nous offrira un tableau de bord bien plus intéressant et nous évitera de nous tromper d’axe de progression. N'est-ce pas plus judicieux d'avoir une vision globale, à 360° ? Il reste alors à suivre régulièrement les tendances sur les 4 quadrants. Pour ce faire, l’équipe va déterminer et choisir au moins une ou deux « Key Value Mesure » pour chaque quadrant, représentative dans le contexte de l’équipe de la valeur que l’équipe escompte apporter aux utilisateurs et à l’entreprise. A titre d’exemple, on peut suivre l’évolution des capacités d’innovation de l’équipe en suivant la tendance des incidents, si possible à la baisse, ainsi que la capacité de l’équipe à mettre effectivement ses livrables dans les mains de l’utilisateur, si possible à une fréquence de plus en plus haute. En complément, on suivra l’évolution de la satisfaction des utilisateurs (à quel point leur propre travail est-il facilité maintenant qu’ils utilisent notre produit ?) et les opportunités restantes qui justifieraient (ou non) des investissements complémentaires. Cette vision globale permettra de réagir rapidement si l’on a manqué notre cible. La cible peut être manquée par exemple si les utilisateurs n’adoptent pas le produit livré pourtant dans le respect des coûts et des délais ; si les investisseurs sont déçus du chiffre d’affaire réalisé bien en deçà des prévisions ; si notre produit est actuellement satisfaisant mais que nos concurrents proposent des mises à jour nettement plus fréquentes pour grignoter nos parts de marché. Conclusion Bien sûr la capacité de production de l’équipe est importante. Mais la réussite de l’équipe se mesure davantage à la valeur du produit pour les utilisateurs qu’à sa simple capacité de production. Rendre transparent la situation, l’inspecter régulièrement et avoir le courage de s’adapter lorsque les mesures nous indiquent clairement que la trajectoire doit être rectifiée nécessite un pilotage et une vision globaux de l’activité. Cette vision globale est nécessaire afin d’assurer la satisfaction de tous, maintenant et dans la durée. Pour aller plus loin, lisez le EBM Guide disponible ici https://www.scrum.org/resources/evidence-based-management-guide. N’hésitez pas à me contacter pour vous accompagner dans la mise en place d'EBM dans votre contexte ou pour participer à mes formations https://www.scrum.org/courses/professional-agile-leadershiptm-evidence-based-managementtm-training

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?