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
