Que vous soyez déjà engagé dans l’un des deux frameworks agiles les plus en vogue, ou que vous recherchiez celui qui correspond le mieux à vos besoins, explorez les différences clés entre Scrum et Kanban et passez le test pour savoir celui qui vous correspond le mieux.
Dans ma vie de Product Manager (PM), j’ai été confronté à différentes situations et utilisé Scrum comme Kanban. Parfois, l’équipe était rodée et parfaitement à l’aise avec ses process et rituels. D’autres fois, face à des retards ou des déconvenues, elle se questionnait sur son organisation. Comment alors décider de la pertinence d’une méthodologie pour son équipe ? Y-a-il un bon timing pour passer de Scrum à Kanban (ou inversement) ?
🎡 Scrum, le consensus pour tous types d’entreprises
J’ai retrouvé Scrum dans la majorité des contextes que j’ai connus, que cela soit au sein de grands groupes, de start-ups ou de scale-ups. En travaillant dans un environnement Scrum, les journées sont rythmées par les réunions récurrentes : dailies, sprint plannings, rétrospectives ou autres refinements. Je ne peux donc pas travailler en flux tendu et je dois toujours avoir de l’avance dans mes User Stories (US) pour alimenter mon équipe lors du prochain sprint.
J’ai donc une vision très claire sur le travail à venir et je suis en mesure d’estimer assez précisément les dates de sortie de mes nouvelles fonctionnalités. La structure offerte par Scrum me permet donc de clarifier les objectifs de mon sprint auprès de mon équipe. En revanche, cela signifie que je dois être suffisamment préparé pour anticiper les besoins de mon équipe. Si une user story urgente apparaît, elle ne peut généralement être embarquée que lors du sprint suivant, à moins d’impacter celui en cours. Cependant il est souhaitable d’éviter ça le plus possible afin de respecter les objectifs qui ont été définis en amont du sprint.
🌈 Kanban, vers plus de liberté ?
J’ai récemment fait l’expérience de Kanban lors d’une mission pour une start-up. Comparé à Scrum, mon quotidien est bien plus léger et flexible. Mon nombre de réunions diminue : terminé les dailies, le sprint planning ou la rétro, etc… Avec Kanban, je n’ai plus de cérémonies obligatoires venant “imposer” un rythme à l’équipe. De fait, je ne suis pas contraint de préparer toutes les US des quinze prochains jours pour une date précise : je peux aussi choisir d’alimenter le backlog en continu, si je suis trop juste pour tout anticiper par exemple. J’ai enfin la possibilité de glisser une US urgente en prochaine tâche à prendre par les développeurs, ce qui se révèle plutôt pratique en cas de changement soudain de priorité, vous en conviendrez…
Le revers de la médaille ? En tant que PM, je n’ai pas une visibilité aussi forte sur l’avancement de l’équipe. Difficile pour moi de me prononcer sur une potentielle date de release. Ma visibilité se base essentiellement sur l’avancée des tickets sur le tableau Kanban, d’où l’importance pour moi de travailler avec une équipe de développeurs suffisamment sensibilisés et rigoureux pour bouger leurs tickets de colonne en temps réel. Je dois également me responsabiliser pour détecter (même si mon Tech lead peut m’aider) les tickets qui n’ont pas quitté la colonne “en cours” depuis quelques jours, afin d’en discuter avec le développeur en charge.
Vous l’aurez compris, ces deux frameworks présentent donc chacun des avantages et des inconvénients pour un PM.
✅ Passez le test !
Vous vous demandez si vous évoluez dans le framework produit le plus adapté à votre contexte ?
Pour vous aider, je vous propose un quizz rapide afin d’obtenir la réponse à cette question en 3 minutes seulement. Attention, pas de vérité absolue ici !
Partie 1 : Le contexte
Q1 : Quel degré de visibilité le management me demande-t-il ?
💧 J’ai besoin de donner beaucoup de visibilité au management qui me sollicite régulièrement sur l’avancée des développements.
⭐️ Je dois donner de la visibilité de manière occasionnelle au management.
🔥 Je n’ai pas spécialement besoin de donner de visibilité au management.
Q2 : À quel stade de développement/croissance en est mon produit ?
💧 Le développement du produit accélère (post-MVP).
⭐️ La croissance du produit ralentit : nous sommes entrés dans une phase plus calme après un fort développement.
🔥 Le produit se construit (pré-MVP).
Q3 : Les priorités Produit sont-elles changeantes ?
💧 Non, une fois que le plan est établi, on ne le change sous aucun prétexte.
⭐️ Oui, les priorités changent mais cela peut être anticipé.
🔥 Oui, les priorités changent de façon incessante.
Q4 : Quel est le degré de maturité Produit/Agile dans mon organisation ?
💧 Mon entreprise n’est pas du tout Agile.
⭐️ Mon entreprise est en transition vers l’agilité : elle part d’une méthodologie de cycle en V ou d’un domaine initialement éloigné de la tech (pas de produit digital à l’origine par exemple).
🔥 Mon entreprise est Agile, elle maîtrise l’état d’esprit de l’agilité et sait l’appliquer sans forcément être “by the book”.
Partie 2 : Les besoins de l’équipe
Q5 : Quel est le besoin d’encadrement au sein de l’équipe (niveau de process) ?
💧 Les process, c’est la vie. Il y en a partout dans mon organisation et ça me convient bien.
⭐️ On a une base de process, parfois on en ajoute, parfois on en enlève.
🔥 C’est “freestyle” !
Q6 : Quel est le degré de certitude sur ce qu’on doit construire ?
💧Très clair.
⭐️ Globalement, c’est clair.
🔥 Encore flou.
Partie 3 : La dynamique de l’équipe
Q7 : Comment l’équipe réagit-elle face aux obstacles et aux problèmes imprévus ?
💧L’équipe cherche à résoudre les problèmes de manière structurée en utilisant les méthodes prédéfinies.
⭐️ L’équipe évite les obstacles autant que possible en suivant rigoureusement les processus établis
🔥 L’équipe est habituée à résoudre rapidement les problèmes sans avoir besoin de formaliser des procédures.
Q8 : Quel est le niveau d’autonomie et de responsabilité des membres de l’équipe ?
💧Les membres de l’équipe sont encouragés à prendre des décisions et à gérer leur propre travail de manière autonome.
⭐️ Les membres de l’équipe ont des rôles et des responsabilités définis mais ils ont encore besoin de validation pour certaines actions.
🔥 Les membres de l’équipe ont une grande liberté d’action et peu de contraintes en termes de responsabilités définies.
🔍 Les réponses
Comptez vos émojis et comparez-les avec la grille ci-dessous :
- Une majorité de 💧 ?
Vous opérez dans un environnement nécessitant une haute visibilité pour le management, une structure et des process bien établis (voire peut-être même un stade de croissance post-MVP pour votre produit). Dans ce contexte, Scrum offre le cadre structuré et les processus nécessaires pour répondre à ces besoins. - Une majorité de 🔥 ?
Votre environnement de travail privilégie la flexibilité et la réactivité face aux changements constants, avec un besoin moins prononcé de visibilité stricte et de structures rigides imposées par des processus formels. Kanban, avec son approche plus fluide et adaptable, peut s'avérer être l'outil parfait pour gérer vos projets sous ces conditions. - Une majorité de ⭐️ ?
Votre situation est probablement quelque part entre Scrum et Kanban, bénéficiant d'une structure modérée tout en nécessitant une certaine flexibilité. Vous pouvez passer de l’un à l’autre en fonction de votre contexte. Il est donc important de considérer les aspects uniques de votre équipe, de votre produit, et de votre environnement de travail pour déterminer quel cadre ou quelle combinaison de cadres pourrait vous convenir le mieux. Si vous n’êtes pas convaincus par Scrum ou Kanban, pas de panique ! On vous propose d'autres framework en dessous.
En conclusion, je suis convaincu qu’il n’existe pas de méthodologie parfaite, mais plutôt des méthodologies bénéfiques à une équipe dans un contexte donné, pendant un certain temps. Le contexte de l’équipe évoluant, un changement de méthodologie peut s’avérer pertinent afin de s’adapter aux nouvelles réalités.
4 points clés à retenir pour conclure :
- La méthodologie choisie doit être adaptée à mon équipe et à mes besoins.
- Je dois rester ouvert aux changements si l’approche actuelle ne semble plus fonctionner efficacement, et garder à l’esprit que le choix de la méthodologie n’est pas gravé dans le marbre.
- Explorer différentes méthodologies peut m’aider à trouver celle qui correspond le mieux à mes besoins (sans pour autant faire la girouette).
- Et si ni Scrum, ni Kanban ne semble idéal, il existe aussi d’autres alternatives telles que Scrumban, Shape Up,…
Merci à Julie Crépet et Naban Tuo pour leurs conseils avisés lors de l'écriture de cet article.
Pour en savoir plus : téléchargez notre Product Management Toolkit
