Scrum, Kanban, Scrumban, Shape Up ! Lequel vous convient le mieux ?

Quelle est la meilleure approche à utiliser au sein de votre organisation ? Devriez-vous travailler avec Scrum, Kanban, Scrumban ou encore Shape Up ? J’imagine que vous souhaitez augmenter vos chances de réussite, mais vous ne savez pas quelle option vous aidera le plus. Comme on me pose souvent cette question, je décortique mes éléments de réflexion au sein de cet article !

Quelle approche agile utiliser ? Il y a de très nombreuses possibilités. Savoir laquelle vous aidera le mieux dans votre contexte peut sembler difficile et, malgré tout, c’est un choix que vous devez faire. Personne d’autre ne peut le faire pour vous. Pourtant, vous devez comprendre les implications derrière ce choix.

Laissez-moi vous aider à comprendre les différences entre les approches Agile courantes. À la fin de cet article, vous devriez comprendre l’essence de chaque option possible et être en mesure de choisir celle qui vous convient le mieux.

Prenons un peu de recul

Scrum, Kanban, Scrumban et Shape Up sont, en 2022, les choix de framework et approches Agile les plus courants. Bien sûr, vous trouverez aussi et toujours d’autres possibilités comme eXtreme Programming, LeSS, Spotify Model, etc. Mais celles-ci sont moins courantes que les premières citées.

Oups ! J’ai omis de parler de SAFe ? La raison est simple : Je ne considère pas SAFe comme un framework agile en raison de sa haute, trop haute, prescriptivité. C’est pourquoi je ne le mentionne pas et je vous encourage à faire de même à moins que vous ne vouliez rater vos chances de réellement devenir agile.

Quelle est la tendance actuelle des VRAIES approches Agiles ? En essayant de répondre à cela, j’ai publié un sondage sur mon LinkedIn pour comprendre ce que les gens utilisent pour créer de la valeur plus rapidement. Voici le résultat :

Je n’ai pas cherché à prouver quoi que ce soit avec ce sondage. Je voulais seulement savoir quels frameworks agile les gens de mon réseau utilisent. J’ai été assez surpris de voir encore Scrum si loin devant les autres car dernièrement, je vois actuellement beaucoup de gens s’e plaindre en disant que c’est un mauvais framework. Je m’attendais à voir Kanban ou Scrumban se rapprocher encore plus, mais ce n’est pas ce que le sondage a montré.

L’un des plus grands défis que je vois est de comprendre les implications de chaque option. Presque tout le monde a une interprétation particulière et ses raisons de choisir tel ou tel framework. Ceci étant dit, sans surprise, les implémentations diffèrent d’une entreprise à l’autre. Je n’ai jamais vu d’application puriste d’un framework Agile, ce qui est bien, mais il faut comprendre ce qui fait partie du framework et ce qui ne l’est pas.

Pour un peu plus de clareté, le tableau suivant résume les principales différences entre Scrum, Kanban, Scrumban et ShapeUp.

Vous pouvez regarder ce tableau et me demander : « Et alors ? Lequel devrais-je choisir ?” Il n’y a pas de réponses simple ! Avant de choisir, nous devons nous intéresser à votre contexte. C’est parti pour la suite !

SCRUM

Sans aucun doute, Scrum est de loin le framework Agile le plus utilisé au monde. Pour la plupart des organisations, c’est le choix incontestable. Mais est-ce un choix conscient ou juste un effet de mode ?

Scrum s’est transformé en une entreprise hautement rentable. Scrum.org et Scrum Alliance ont certifié des millions de professionnels dans le monde. Avec une telle abondance de praticiens, il est naturel que Scrum soit très utilisé. Mais est-il le bon choix pour vous ?

J’ai travaillé avec Scrum pendant plus d’une décennie et je l’ai perçu comme un excellent framework. Mais il est très facile de tomber dans plusieurs pièges. Les voici:

• Orientation processus : Scrum peut sembler rigide avec ses événements. Vous avez un Sprint régi par un Sprint Planning, un Daily Scrum, une Sprint Review et une Sprint Retrospective. Bien que l’objectif soit de créer de l’espace pour les échanges nécessaires, les équipes oublient le sens de chaque événement et les enchainent les uns après les autres, bêtement.
• Cercle vicieux : Scrum fonctionne par cycles d’une à quatre semaines. Les cycles sont imparables. Les équipes Scrum n’auront aucune pause entre les Sprints. Une fois qu’un Sprint est terminé, l’autre démarre immédiatement. Cela peut être accablant si les équipes n’apprennent pas à le gérer correctement. De nombreux développeurs détestent les cycles car ils les perçoivent comme contre-productifs pour leur travail.
• Usine à features : L’âme de Scrum ne réside pas dans son processus mais dans l’état d’esprit qui le sous-tend. Deux parties essentielles déterminent à quel point les équipes peuvent être responsabilisées : les objectifs de produit et les objectifs de sprint. Le problème est que de nombreuses équipes Scrum ont du mal à fonctionner avec des objectifs et tombent dans un mode d’usine de fonctionnalités ou il faut produire, produire et produire. Le seul objectif devient donc de livrer des fonctionnalités à la fin de chaque Sprint.

Mon point de vue sur Scrum : Simple à comprendre, simple à mettre en œuvre. Les défis vont au-delà du framework lui-même. Il est complexe de transformer le fonctionnement des organisations. La plupart des implémentations de Scrum ne touchent que les équipes techniques, développeurs et livraison des produits, ce qui sera sous-optimal et garantira de mauvais résultats.

Pour prospérer avec Scrum. Il est essentiel de comprendre que ce framework est incomplet de nature et que les équipes doivent ajouter des pratiques pour s’assurer qu’ils créent de la valeur. Par exemple, Scrum ne mentionne aucune pratiques de product management mais aucune organisation travaillant avec sur produits numériques ne peut réussir sans cela.

Scrum isn’t limited to delivery, as many people think. It’s a framework to create value from end to end.

Kanban

Kanban est apparu comme un système de planification lean, planifier, concevoir et produire au plus juste, issu de Toyota. À la fin des années 1940, Toyota a introduit le “juste à temps” dans sa production. Contrairement à la pratique standard consistant à produire des biens et à les mettre sur le marché, Toyota a introduit un système d’attraction basé sur la demande des clients. Ce fut la naissance de Kanban.

Techniquement, Kanban n’est pas un framework Agile. C’est une méthode allégée pour aider les gens à améliorer leur façon de collaborer en rendant leur flux de travail visible et transparent. J’aime dire que Kanban est un processus d’amélioration des processus. Je recommande particulièrement l’excellent article de Romain sur le sujet.

Je suis souvent confronté à une discussion sur la question de savoir si Kanban est un framework ou non. Honnêtement, cette discussion est inutile. De nombreuses équipes choisissent d’utiliser Kanban comme méthode de travail. Alors, que signifie travailler avec Kanban ?

Kanban a un ensemble de caractéristiques et de règles à suivre. Au-delà de cela, l’équipe doit le comprendre de manière indépendante. Voici ce qui fait partie de Kanban :

• Visualiser le flux : un tableau avec des couloirs représentant le flux de travail de l’équipe. Ce tableau doit être visible et accessible à tous les membres de l’équipe. Il précise les étapes nécessaires à la réalisation d’une tâche.
• Travail en cours : Kanban limite le travail en cours (WIP) par activité. Cela oblige l’équipe à résoudre les problèmes lorsqu’ils sont bloqués. Les membres de l’équipe ne sont pas autorisés à dépasser les limites WIP.
• Cartes : chaque carte représente une tâche que l’équipe doit exécuter. La carte suivra tout le flux de travail jusqu’à ce qu’elle soit terminée.
• Principes : Commencez par ce que vous faites maintenant. Poursuivre les améliorations progressives. Encourager les actes de leadership à tous les niveaux.

Quand je dis que Kanban n’est pas un framework, cela signifie, par exemple que Kanban ne définit pas des rôles ou des événements. Pour reprendre les mots de Romain,

La méthode Kanban se définit autour de 6 pratiques :

1. Visualiser
2. Limiter le travail en cours
3. Entretenir le flux
4. Rendre le processus explicite
5. Mettre en place des boucles de feedback
6. Améliorer par la collaboration et évoluer par l’expérimentation

avec ses propres principes…

• Démarrez là où vous êtes
• Poursuivez un changement incrémental et évolutif
• Respectez les processus, rôles, responsabilités et titres actuels
• Encouragez les actes de leadership à tous les niveaux dans votre organisation

et ses paradoxes…

• ralentir pour être plus performant
• refuser une demande à forte valeur pour préserver l’efficacité générale
• ne pas faire son travail, mais aller aider un.e autre membre de l’équipe

Ainsi, de mon expérience, j’ai remarqué que les équipes expérimentées travaillent avec Kanban. En revanche, les moins expérimentés sont confus avec une telle flexibilité et ont tendance à perdre leur temps avec des activités telles que la gestion de leur tableau, la résolution d’obstacles, etc.

Kanban isn’t against Scrum. Most aspects could be combined and even beneficial. You know where I’m getting. Let’s talk about Scrumban now.

Scrumban

Beaucoup de gens pensent que Scrumban est un hybride de Scrum et de Kanban. C’est peut-être même ce qui se passe dans la pratique, mais ce n’était pas l’idée initiale de Corey Ladas, créateur de Scrumban. Son objectif initial était d’utiliser Scrumban pour passer de Scrum à Kanban.

Curieusement, si vous travaillez Scrum, vous êtes peut-être déjà dans une sorte de Scrumban sans le savoir.

Une équipe travaillant avec Scrum a besoin de sept étapes pour appliquer Scrumban :

• Visualisez le travail : créez un tableau Kanban visuel avec votre flux de travail. Assurez-vous que chaque membre de l’équipe y a accès.
• Auto-organisation : n’attribuez pas de tâches aux membres de l’équipe. Laissez-les choisir les tâches une fois qu’elles sont disponibles.
• Connaissez vos limites : Définissez des limites WIP pour chaque étape de votre flux de travail. Cela vise à assurer la collaboration lorsque les membres de l’équipe sont bloqués. Personne dans l’équipe ne peut dépasser la limite.
• Passez du flux poussé au flux tiré : créez des buffers entre les étapes pour clarifier le processus. Par exemple, un flux traditionnel comporte les étapes suivantes, À faire, En cours, Test, Terminé. En ce qui concerne les tests, il se peut que personne ne teste, mais vous pensez que quelqu’un le fait. Un push and pull impliquerait une étape intermédiaire, par exemple, Test Ready. Cela donnerait à l’équipe une transparence totale de la réalité.
• Ordonnez : Trier les PBI, priorisez. Utilisez les lignes de nages. C’est une séquence; personne ne peut choisir ce qui ne se trouve pas dans la voie. Les membres de l’équipe ne peuvent choisir que ce qui est en haut. Jusqu’à cette étape, Scrumban est entièrement compatible avec Scrum, mais les étapes 6 et 7 les placeront dans des directions différentes.
• Arrêtez d’estimer : les équipes Scrumban n’évaluent aucun travail. C’est perçu comme du gaspillage. Ils ne le font tout simplement pas.
• Planification des déclencheurs : Scrumban n’a pas d’événement à planifier. Vous voulez faire une rétrospectives ? C’est dans une logique du “juste à temps, quand il le faut”. Donc cela se produit à la demande. Par exemple, une fois que la voie To Do atteint un niveau minimum, il est temps de planifier. Ce n’est pas similaire à la planification de sprint. Il faut mettre en place des déclencheurs pour voir quand tel ou tel événement s’avère nécessaire.

Pour moi, Scrumban est un hybride de Scrum et Kanban, même si ce n’était pas l’intention initiale. je dois être honnête; Je n’ai jamais travaillé entièrement avec. Je reste principalement sceptique quant aux étapes six et sept. Mon point de vue est qu’il faut de l’ancienneté pour sauter l’estimation et la planification. J’imagine que cela fonctionne bien lorsque l’équipe est responsabilisée, digne de confiance et suffisamment expérimentée pour s’autogérer.

L’inconvénient que je vois avec Scrumban est le manque d’objectifs. Je vois une concentration extrême sur la réalisation des choses alors qu’il manque la direction sur “pourquoi cela compte” en premier lieu. Dans la plupart des endroits où j’ai travaillé, j’imagine que les parties prenantes aiment ScrumBan car elles pourraient pousser leurs souhaits et les équipes les exécuteraient. Comme je l’ai dit, il faudrait de l’ancienneté et de l’expertise pour utiliser Scrumban efficacement.

Shape up

Basecamp est une entreprise prospère avec une façon particulière de travailler. Ils n’appellent pas leur style Agile ou ne se rapportent à aucun autre cadre. Il y a trois ans, Ryan Singer a publié un livre révélant le fonctionnement de Basecamp. Le livre est assez long (160 pages) mais donne des exemples solides de pourquoi ils font ce qu’ils font et comment cela fonctionne pour eux.

Shape Up est destiné aux équipes de développement de produits qui ont du mal à livrer.

Formez-vous, arrêtez de tourner en rond et expédiez le travail qui compte.

Shape Up est le petit « nouveau » sur la scène Agile. Le livre a été publié en 2019, bien que Basecamp fonctionne de cette façon depuis plus d’une décennie. Après avoir mis Shape Up à la disposition du public, certaines entreprises se sont montrées curieuses et ont commencé à adopter cette façon de travailler. Je trouve certaines choses assez intéressantes à propos de Shape Up, et ce sont :

• Absence de Backlog: Shape Up n’a pas de backlog. Ils ont des idées et les façonnent à un niveau que les équipes peuvent mettre en œuvre. Cette approche oblige les équipes à rester attentives aux problèmes actuels et à travailler sur ce qui compte le plus. Les idées non sélectionnées à construire au cours du cycle suivant sont rejetées.
• Shapers and Builders : Ces rôles segmentent clairement discovery et delivery. Les shapers travaillent à comprendre les problèmes et à définir des solutions de haut niveau tout en réduisant les risques de mise en œuvre. Les builders mettent en œuvre des solutions prédéfinies. Ils ne se demandent pas si le problème vaut la peine d’être résolu, mais se concentrent sur la réalisation de la bonne solution.
• Petites équipes : Une fois qu’une idée passe au cycle suivant, une équipe de deux ou trois personnes la mettra en œuvre. Aucune équipe n’aurait plus de trois personnes, et les équipes sont dynamiquement définies. Cela signifie que les gens changent souvent les équipes avec lesquelles ils travaillent.
• Cycle Strict : Chaque cycle dure précisément six semaines, ni plus, ni moins. L’équipe a ce temps pour mettre réaliser les choses. S’ils n’y parviennent pas, ils ne continueront pas à travailler dessus à moins que l’idée ne devienne un autre cycle.
• Cool Down : après chaque cycle, l’équipe a un temps de souffle, de recharge de deux semaines. Contrairement à Scrum, les équipes auraient une flexibilité totale pendant cette période. L’équipe peut l’utiliser pour régler la dette technique, corriger des bogues ou faire ce qu’elle veut. C’est à ce moment que les shapers apporteront des idées à la table des paris et se mettront d’accord sur ce qui fera le cycle à venir.

Encore une fois, Basecamp est une entreprise prospère. Il est difficile de croire ce qu’ils ont accompli. Je pense que beaucoup a à voir avec la façon dont ils fonctionnent. Leur produit compte des millions d’utilisateurs dans le monde et un effectif d’une cinquantaine de personnes. Je ne peux donc qu’imaginer que Shape Up fonctionne incroyablement bien pour eux. Pourtant, je suis curieux de savoir comment cela se passerait dans les grandes organisations. Envoyez nous vos REX !

En conclusion

Nous venons de parler de Frameworks. Maintenant, vous vous demandez peut-être lequel dois-je choisir ? Lequel correspond le mieux à mon contexte ? Vous devez toujours y répondre par vous-même, mais je peux vous donner quelques conseils pour faciliter la réflexion :

Et donc…

Vous l’avez compris ? Vous ne trouverez un choix parfait pour votre contexte. Quel que soit votre choix, pour bénéficier de l’agilité, vous devez être prêt à entreprendre un parcours d’apprentissage.

No framework will get you far without a value-driven mindset.

J’encourage les équipes à franchir une étape après l’autre. Examinez votre contexte et demandez-vous : « Que pourrions-nous faire maintenant pour augmenter nos chances de créer de la valeur plus tôt ? » Faites une action à la fois et vous serez surpris des résultats. Par exemple en utilisant la méthode Mikado. Faites-le aussi souvent que possible. La constance et le courage vous mettront sur la bonne voie.

Ma dernière recommandation est d’éviter le dogmatisme. Vous pouvez mélanger les pratiques de différents frameworks. Votre objectif ne devrait jamais être de maîtriser Scrum, Kanban ou tout ce que vous choisissez. Votre objectif devrait être de trouver de meilleures façons de collaborer et de créer de la valeur plus rapidement. C’est ça l’agilité.

Il ne s’agit jamais de maîtriser un framework. Il s’agit d’améliorer la collaboration et de créer de la valeur plus tôt.