« Et n’oubliez pas, peu importe où vous allez, vous êtes là. »
– Confucius

Il y a près de deux ans, j'ai rejoint PagerDuty en tant que coach Agile avec une expérience limitée de travail avec des équipes de livraison Kanban. J'ai commencé à coacher deux équipes Scrum, mais dès que mes équipes ont appris que leurs pairs utilisant Kanban étaient plus heureux et plus performants, elles ont poussé pour le changement.

Aujourd'hui, presque toutes les équipes de livraison sont passées de Scrum à Kanban. Mais avant d'aborder les raisons qui ont poussé ces équipes à passer à Kanban, parlons de la culture qui leur a permis de faire ce changement en premier lieu.

Comment la culture PagerDuty a permis aux équipes de passer à Kanban

William McKnight, ancien président et directeur général de 3M, a déclaré à plusieurs reprises : « Embauchez de bonnes personnes et laissez-les tranquilles. » La culture d'ingénierie de PagerDuty est exemplaire de cette philosophie. Les équipes ici sont auto-organisées et ont en grande partie le contrôle de leur propre destin.

Alors que toutes les équipes de livraison suivre les principes Agile , certains choisissent Scrum et d'autres Kanban , pour gérer leur travail au quotidien. Au fur et à mesure qu'une équipe évolue et que son travail change, elle peut choisir une manière différente de faire les choses. En tant que coach agile, je peux aider une équipe à déterminer ce qui lui convient le mieux, mais je ne suis pas propriétaire de sa solution de processus. C'est un voyage que, en fin de compte, l'équipe doit entreprendre ensemble.

Alors pourquoi presque toutes nos équipes sont passées à Kanban ? Et était-ce pour les bonnes raisons ?

Pourquoi la plupart des équipes sont passées à Kanban

La transition ne s'est pas faite du jour au lendemain. Elle a commencé avec une équipe et s'est propagée à l'ensemble du département de développement de produits au cours des deux années suivantes. Lorsque les membres de l'équipe ont entendu parler pour la première fois du succès de leurs pairs avec Kanban, ils ont eu envie de l'essayer eux-mêmes. Certaines de leurs idées préconçues sur Kanban étaient fondées sur la réalité et d'autres étaient des idées fausses. En tant que coach Agile, mon objectif, ainsi que celui du reste de l'équipe de direction Agile, était d'aider nos équipes à dépasser ces idées fausses et à décider de passer ou non à Kanban pour les bonnes raisons.

Idées reçues : les mauvaises raisons de passer à Kanban

Kanban est la destination ultime pour une équipe performante. Scrum et Kanban aident les équipes à donner la priorité à la livraison de valeur aux clients dans les meilleurs délais, et aucun des deux n'est supérieur à l'autre. Mais, dans le contexte d'une équipe donnée, Kanban n'est pas toujours le meilleur choix. À un moment donné, une équipe sera mieux servie par Scrum ou Kanban.

Kanban signifie aucune estimation. Les équipes Kanban travaillent généralement à dimensionner l'ensemble de leur travail de la même manière (par exemple, en utilisant une « taille de segment » de trois jours ou moins par ticket). Il s'agit toujours d'une estimation même si elle n'utilise pas de points d'histoire ou d'estimation de temps spécifique.

Kanban signifie plus d'engagements . Kanban signifie qu'il n'y a plus d'engagements de sprint (engagements de travail pris dans un délai de 2 à 4 semaines), mais cela ne signifie pas qu'il n'y a plus d'engagements. Une équipe Kanban est responsable de son temps de cycle (le temps qu'il lui faut pour terminer un ticket), de la même manière qu'une équipe Scrum est responsable de sa vélocité de sprint engagée (mesure de la quantité de travail que l'équipe accomplit dans un délai unique). Le temps de cycle est utilisé à la fois pour la réflexion empirique sur les processus et pour la prévision des versions.

Kanban signifie moins de réunions. Kanban recommande certaines réunions, mais ne les prescrit pas comme le fait Scrum. Cela étant dit, la plupart des équipes auraient du mal à réussir sans réunions organisées. Les équipes qui réussissent doivent être alignées sur des objectifs et élaborer un plan pour y parvenir, qu'elles utilisent Scrum ou Kanban.

La plupart des équipes Kanban de PagerDuty ont remplacé les réunions Story Time par Replenishment (les deux ont pour but de préparer l'équipe aux travaux futurs) et ont continué à organiser des rétrospectives, des critiques et des stand-ups quotidiens. Comme le backlog d'une équipe doit encore être maintenu, certaines équipes continuent également à organiser des réunions de raffinement du backlog. La planification de sprint disparaît dans Kanban.

Même si des économies peuvent être réalisées en termes de réunions, globalement, le changement n’est pas significatif entre Scrum et Kanban.

Réalités : les bonnes raisons de passer au Kanban

Scrum est moins flexible. Scrum utilise une itération comme timebox et scopebox, et il y a peu de flexibilité pour ajouter ou supprimer du travail une fois qu'une itération a commencé. Chez PagerDuty, nos équipes sont propriétaires de ce qu'elles construisent, ce qui signifie que nous sommes une véritable organisation DevOps. De par leur nature de propriétaire de ce que nous construisons, certaines équipes sont interrompues par un travail qui doit être accéléré. Scrum considère cela négativement comme une « injection de sprint », qui va à l'encontre des mesures de vitesse de l'équipe. Kanban est flexible et permet à l'équipe de créer une classe de service pour accélérer les travaux hautement urgents.

Scrum est plus prescriptif. Scrum comporte plus de règles à suivre et une structure plus structurée. Il est donc plus adapté à une équipe nouvellement formée, qui peut bénéficier d'un soutien structurel supplémentaire. Pour les équipes plus matures, les règles de Scrum peuvent commencer à gêner l'équipe et à la ralentir.

La culture d’équipe et d’organisation est importante. Certaines équipes sont motivées par des engagements internes réguliers envers leurs jalons (par exemple, les engagements de sprint). D'autres équipes trouvent cela stressant et préfèrent améliorer leurs performances en se concentrant sur l'amélioration de leur temps de cycle. Certaines équipes préfèrent gérer les travaux en cours (WIP) via un engagement de sprint, d'autres préfèrent gérer les travaux en cours en contrôlant le flux de tickets dans le système. Certaines équipes trouvent intéressant de dimensionner leur travail à l'aide de points d'histoire. D'autres trouvent que les conversations de pointage offrent des rendements décroissants et trouvent que la décomposition de leur travail à l'aide d'une taille de bloc (par exemple, trois jours ou moins) est un processus plus efficace.

Kanban est génial… mais

Les équipes de PagerDuty utilisent presque toutes Kanban aujourd'hui. Les coachs agiles ont aidé les équipes à décider si elles effectuaient le changement pour les bonnes raisons. Lorsque les équipes n'ont pas effectué la transition pour les bonnes raisons (par exemple, elles pensaient que cela résoudrait un dysfonctionnement de Scrum), elles ont rapidement découvert que la discipline, la communication et l'estimation nécessaires à Scrum étaient également nécessaires pour réussir avec Kanban.

Le choix d'un processus pour votre équipe implique de prendre en compte de nombreux aspects. J'espère que cet article de blog vous aidera à réfléchir au processus de votre équipe et à déterminer si une transition vers Kanban aiderait réellement votre équipe à mieux atteindre ses objectifs finaux, ou si elle transfèrerait simplement ses problèmes Scrum vers Kanban.

Avez-vous des leçons apprises ou des histoires à partager sur l'utilisation de Scrum ou Kanban par votre équipe ? Partagez-les sur notre Page communautaire pour nous faire savoir ce qui fonctionne le mieux pour votre équipe.

Cet article de blog a été inspiré par l'article de blog interne d'Andrea Roberts de PagerDuty « Scrum ou Kanban ? Choisir le bon outil pour votre équipe. »