Un cadre de décision

Les équipes qui peuvent décrire le travail de la semaine prochaine aujourd'hui sont candidates à Scrum. Les équipes qui ne peuvent pas décrire le travail de demain aujourd'hui sont candidates à Kanban.

Évaluez-vous sur une échelle de 1 à 5 : 1 signifie « nous avons une feuille de route priorisée et la plupart des sprints se déroulent à peu près comme prévu ». 5 signifie « la moitié de notre travail arrive de façon imprévue — incidents, escalades clients, demandes ad hoc d'autres équipes ». La plupart des équipes de fonctionnalités produit se situent à 1–2. La plupart des équipes de plateforme, DevOps et support se situent à 4–5. Les équipes à 3 sont véritablement ambiguës — et « Scrumban » (cadence Scrum avec flux de type Kanban pour le travail imprévu) est une réponse raisonnable pour elles.

L'idée clé : la prévisibilité n'est pas une question de discipline. Une équipe peut être extrêmement disciplinée et avoir quand même un travail imprévisible parce que le domaine l'exige. Ne confondez pas « nous ne pouvons pas prévoir » avec « nous ne planifions pas ».

Le sprint de Scrum est un engagement limité dans le temps : l'équipe accepte de protéger une période fixe des changements de périmètre. Cela ne fonctionne que si l'organisation respectera réellement la limite.

Posez deux questions : Votre propriétaire de produit peut-il dire « non, ça attend le prochain sprint » à un VP sans être contredit ? Et l'équipe peut-elle réalistement assister à la planification, à la mêlée quotidienne, à la revue et à la rétro à chaque cycle sans que ces cérémonies soient annulées pour « quelque chose de plus urgent » ? Si les deux réponses sont oui, vous pouvez maintenir la cadence de Scrum. Si l'une ou l'autre est non, les sprints s'effondreront en flux continu avec des réunions supplémentaires — le pire des deux mondes.

Kanban n'exige pas d'engagement de cadence. Vous pouvez toujours tenir des rétrospectives et des sessions de planification régulières, mais rien ne se brise si vous en sautez une ou la décalez de quelques jours. Pour les équipes dans des organisations qui contournent régulièrement les plans, l'absence de limite de sprint de Kanban est de l'honnêteté, pas du laisser-aller.

La structure est un échafaudage — elle compense ce que l'équipe n'a pas encore construit comme mémoire musculaire. Une équipe de six développeurs qui travaillent ensemble depuis deux ans pourrait ne pas avoir besoin d'une définition formelle de « prêt » parce qu'ils l'ont intériorisée. Une équipe formée le mois dernier, oui.

Signaux concrets qui pointent vers plus de structure (Scrum) :

• Plus de deux développeurs ont rejoint l'équipe au dernier trimestre
• L'équipe n'a pas d'historique partagé de ce que « terminé » signifie
• Le travail commence régulièrement sans critères d'acceptation clairs
• Les rétrospectives révèlent des problèmes de communication répétés

Signaux qui pointent vers moins de structure (Kanban ou fondamentaux seulement) :

• L'équipe a une composition stable et un contexte partagé
• Les développeurs s'auto-organisent efficacement sans attribution de rôles
• Les éléments de travail sont bien compris et relativement uniformes
• Le principal problème de coordination est le débit, pas l'alignement

Les nouvelles équipes bénéficient presque toujours de commencer avec plus de structure et de l'assouplir à mesure que la confiance se construit. L'inverse — ajouter de la structure à une équipe qui a déjà des difficultés — semble punitif et engendre du ressentiment.

Scrum est un cadre tout-ou-rien par conception. Vous ne pouvez pas exécuter « la moitié d'un sprint » — soit vous vous engagez à la limite de temps et aux cérémonies, soit vous n'avez pas Scrum. L'adopter signifie changer la façon dont l'équipe planifie, révise et réfléchit en un seul mouvement. C'est une transition big-bang, et elle fonctionne mieux lorsque l'équipe est engagée et qu'un scrum master (ou équivalent) est prêt à accompagner les premiers sprints difficiles.

Kanban est incrémental par nature. Vous commencez par visualiser votre flux de travail actuel sur un tableau — aucun changement de processus requis pour l'instant. Ensuite, vous ajoutez des limites de travail en cours. Ensuite, vous commencez à mesurer le temps de cycle. Chaque étape ajoute de la valeur indépendamment. Si une étape ne fonctionne pas, vous la retirez sans tout défaire.

Pour les équipes sceptiques face au changement de processus ou échaudées par des adoptions de méthodologie passées, le chemin incrémental de Kanban présente moins de risques. Vous prouvez la valeur à chaque étape avant de vous engager davantage. L'approche big-bang de Scrum est plus rapide vers l'adoption complète mais a un taux d'échec plus élevé dans les équipes qui ne sont pas prêtes pour l'engagement.

La mauvaise méthodologie est récupérable — mais le coût de récupération varie. Une équipe qui essaie Scrum pendant deux sprints et décide que ça ne convient pas a perdu un mois d'ajustement et un peu de bonne volonté. Une équipe qui se réorganise autour de SAFe et achète des outils d'entreprise a un chemin de retour beaucoup plus difficile.

Évaluez honnêtement votre coût de changement : Combien de personnes doivent changer leurs habitudes quotidiennes ? Achetez-vous des outils ou faites-vous des changements d'organigramme pour soutenir la méthodologie ? Les parties prenantes externes sont-elles formées à nouveau sur la façon d'interagir avec l'équipe ? Plus il y a de points de contact, plus le coût de se tromper est élevé — et plus l'argument pour commencer avec l'option la plus simple est fort.

Pour la plupart des équipes qui font leur premier choix de méthodologie, la réponse est : commencez avec Kanban (faible engagement, facile à inverser) ou Scrum (engagement modéré, réversible en un sprint). Ne commencez pas avec un cadre de mise à l'échelle. Ne commencez pas avec quelque chose qui nécessite une coordination inter-équipes que vous n'avez pas encore. Adaptez le poids de la méthodologie au poids de la décision.