Olivier Ledru

How to develop trust through self-management, psychological safety and Transactional Analysis as tools for improving relationships and communication within the Scrum ecosystem.

It's common practice to ask the Scrum Master to take on the role of facilitator in the 5 Scrum events. Let's go beyond this and move towards more learning strategies, for both the Scrum Master and the Scrum Team.

Comment développer la confiance à travers l’autogestion, la sûreté psychologique ainsi que de l’Analyse Transactionnelle en tant qu’outils d’amélioration des relations et de la communication dans l’écosystème de Scrum.

Il est fréquent de demander au Scrum Master de tenir le rôle de facilitateur dans les 5 événements de Scrum. Dépassons ce cap pour aller vers des stratégies plus apprenantes, à la fois pour le Scrum Master et pour la Scrum Team.

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.