Démarrer avec SCRUM ou KANBAN ?

Suite à mon annonce de l’organisation de formations de sensibilisation KANBAN sur Grenoble avec Laurent Morisseau les 13 mars et 20 novembre 2013 (Voir la vidéo de présentation), j’ai reçu quelques messages amusants me demandant si je faisais « enfin » mon coming-out en abandonnant Scrum 🙂

Cela m’a fait penser à la discussion que j’avais eu lors d’Agile Rennes 2012 sur le fait que certains présentaient Kanban comme le futur de l’agilité et que je n’étais pas de ceux-là.

Depuis mes découvertes de SCRUM et KANBAN en 2005, j’ai eu beaucoup plus souvent l’occasion de mettre en œuvre du SCRUM que du KANBAN, et sans remettre en cause les bénéfices de chaque approche et sans même les comparer, je trouve SCRUM beaucoup plus adapté aux problématiques que je rencontre lors d’une transition à l’agilité, et je vais vous expliquer mon point de vue.

Petit rappel : j’ai découvert l’Agilité et le Lean à peu près en même temps (courant 2005).

  • L’Agilité est venue à moi par le biais de Scrum car cette méthode était déjà pratiqué depuis 18 mois au siège de Yahoo en Californie avec de très bons échos, et cela m’intéressait de la déployer en Europe, en Asie et en Inde pour améliorer les pratiques de développement des équipes Yahoo locales.
  • je suis allé au Lean car j’ai eu l’opportunité de participer à 1 semaine de formation donnée par les Poppendieck dans les locaux Californiens de Yahoo (je me rappelle avoir dit à ma chef de l’époque : « Je n’ai pas vraiment de raison d’y aller, mais je ne peux pas rater une telle occasion » … et par chance elle a accepté 😉

Bénéfices du Kanban

L’argument principal utilisé par les promoteurs de Kanban est le fait qu’il permet une transition dans la douceur. C’est en effet un avantage indéniable de Kanban puisqu’il permet tout d’abord de visualiser, sans la changer, la façon de travailler de l’entreprise pour pouvoir l’améliorer ensuite.

David Anderson disait à Londres en 2007 : « I don’t care about your practices! », ce qui signifie que « les entreprises utilisent les meilleures pratiques car elles pensent qu’elles permettent de livrer de la valeur métier aux utilisateurs, et pas parce que quelqu’un leur a dit de le faire ». Kanban est donc bien un outil de transformation par l’amélioration des processus des entreprises.

Mais est-ce que la douceur seule est une réponse appropriée aux situations que je constate dans les différentes entreprises que j’accompagne … je dirais que cela ne suffit pas !

Bénéfices de SCRUM

Lorsque vous mettez SCRUM en place dans une entreprise, c’est clairement une rupture, voir même plusieurs ruptures !

  • Rupture Méthodologique : De nouvelles réunions avec de nouveaux contenus et de nouveaux horaires … et toujours fixes !
  • Rupture Organisationnelle : Disparition du Chef de Projet, Métier et Développeurs au contact, Middle Management dans le flou …
  • Rupture Produit : Définition du produit par petits bouts, en gardant la vision globale, et en acceptant le changement tout au long du projet
  • Rupture Humaine : Nécessité de travailler ensemble, en équipe et accepter de collaborer … et laisser son individualisme au vestiaire !

Je vois beaucoup de vertus à ces ruptures car elles me font penser aux stratégies de rupture du discours marketing.

Parce qu’elles s’appuient sur une vision différente de l’univers concurrentiel, les stratégies de rupture sont synonymes, pour l’entreprise, de position dominante et de croissance.

Rupture Méthodologique

La culture des entreprises est majoritairement ancrée sur la mise en œuvre d’une méthodologie commune et contrôlée. Lorsque l’entreprise réalise que sa méthodologie actuelle n’est pas aussi efficace qu’elle le souhaite, la mise en place d’une autre approche structurée comme SCRUM peut être considérée comme rassurant pour les top managers car elle leur garantit que l’on va faire autrement, mais dans un cadre maitrisé et parfaitement défini, bien que flexible.

Cette rupture est alors vue comme un mal nécessaire au bien être de l’entreprise, et donc à sa réussite future.

Rupture Organisationnelle

Les projets réussissent, les entreprises grossissent et leurs structures internes également. Beaucoup de top managers sont conscients d’avoir un trop grand nombre de strates de management et que leur efficacité n’est pas toujours démontrée, mais comment réorganiser l’entreprise sans mettre en péril les projets car généralement les managers intermédiaires sont à la fois responsables des individus et du succès des projets que ces individus réalisent. Avec SCRUM, la responsabilité du succès du projet est clairement déléguée à l’équipe (Product Owner, Scrum Master et Equipier).

Cette rupture peut donner l’occasion au top management de restructurer l’entreprise sans risque de pénaliser les projets … source réelle de revenus pour l’entreprise.

Rupture Produit

Avec SCRUM, qu’il est loin le temps des documents d’expression de besoin de 50, 100 ou 300 pages rédigés en une seule fois, durant des mois, par des responsables métier de bonne volonté, mais rapidement désappointés par le temps nécessaire pour les réaliser. Que n’a-t-on pas entendu sur les équipes techniques qui ne comprenaient pas que le temps c’est de l’argent et que les concurrents eux ne nous attendaient pas. Et tout cela pour parfois déployer un produit qui ne répondait plus aux besoins immédiats des utilisateurs, mais à ceux collectés des mois, ou des années avant.

Cette rupture est généralement la plus aisée à mettre en œuvre dans les entreprises car ses bénéfices sont facilement explicables. Bien sur il est nécessaire d’enrichir SCRUM avec des techniques spécifiques de définition de produit Agiles (Product Vision, Story Map, Impact Mapping …), car je vous le rappelle cher lecteur, SCRUM est simplement une méthode de gestion de projet, donc de réalisation … et c’est déjà très bien 🙂

Rupture Humaine

Dans notre époque difficile, où le travail est difficile à trouver, nombreux sont les individus qui cherchent à se rendre indispensables pour leur entreprise. C’est donc une course à la spécialisation individuelle, qui pourra également donner l’occasion de renégocier son salaire à la hausse, et à la dissimulation d’information. En effet, si je suis le seul à savoir des choses importantes, je pourrais manipuler ou orienter les décisions à mon seul bénéfice.

SCRUM ne fonctionne correctement que si les individus travaillent ensemble, collaborent au quotidien et acceptent les règles et la discipline de l’équipe. L’entraineur de l’équipe de Rugby de Grenoble qui vient de battre Castres au terme d’un match héroïque disait à ses joueurs dans les vestiaires : « Vous avez été monstrueux aujourd’hui, et si vous continuez à mettre vos égos de cotés au bénéfice du collectif, je pense que nous pourrons obtenir quelque chose de vraiment bien » (Il parlait d’une possibilité d’accession aux barrages pour les demi-finales du Top 14).

Cette rupture est réellement la plus difficile à mettre en œuvre car elle peut contrecarrer les objectifs individuels de « carrière », heurter les croyances que l’entreprise n’est pas le lieu ou l’on s’épanouit, et peut même générer des craintes d’une mise en situation délicate du fait d’une exposition supérieure. Mais notre monde actuel fortement basé sur l’individualisme ne me semble pas pérenne et je crois qu’il est nécessaire que les individus acceptent de travailler ensemble au bénéfice de l’équipe … cette rupture me semble donc également nécessaire.

Conclusion

Comme vous l’avez compris, mon propos n’est pas de dénigrer Kanban mais simplement d’expliquer pourquoi je trouve que dans le cadre d’une transition, les ruptures associées à SCRUM sont très bénéfiques pour l’entreprise. Une fois la transition établie, l’évolution des équipes matures de SCRUM vers KANBAN, ou, comme me le disait un de mes clients, la réalisation du Product Backlog en continue, me semble être la meilleure des solutions.

Il y a peut-être également une autre piste avec la « Rupture Douce » proposée par Laurent Sarrazin (Livre chez Lulu), lisez le et dites moi ce que vous en pensez ?

Bien que bénéfiques, ces ruptures sont très difficiles à mettre en œuvre et génèrent beaucoup de résistances au sein de l’entreprise. Il est donc absolument nécessaire de mettre en œuvre un réel accompagnement de cette transition. Accompagnement qui va bien au delà de la simple mise en œuvre des pratiques de la méthode SCRUM.

Cet accompagnement doit être à la fois interne (par des gens qui connaissent l’entreprise) et externe (pas des gens qui ont une réelle expérience de mise en œuvre) car c’est la complétude des 2 approches qui se révèle être réellement bénéfique pour l’entreprise – Vous allez me dire que cela ressemble à de l’auto-promotion, peut-être, mais quoi qu’il en soit, c’est réellement ma conviction profonde !

10 réflexions sur « Démarrer avec SCRUM ou KANBAN ? »

  1. Je suis tout à fait en phase avec ça : ce cadre proposé par SCRUM permet de faciliter la rupture qu’il impose. Non seulement cela rassure à priori mais le fait de se tenir à un cadre produit très rapidement des effets positifs dans les organisations, ce qui a tendance à faciliter l’adoption de la nouvelle méthodologie. C’est en tout cas de cette manière que je l’ai vécu à chaque fois que j’ai participé à ce genre de transition.
    De la même manière, je suis parfaitement en phase avec le constat que les équipes matures ont tendance à aller naturellement, et par étapes, vers le KANBAN. C’est d’ailleurs, je trouve, souvent un problème auquel sont confrontées les équipes : certaines personnes qui ont rapidement pris leurs marques avec SCRUM ont tendance à accélérer à migration vers KANBAN quand le reste de l’équipe n’est pas encore prêt. Je l’ai notamment vu quand on m’a reproché de vouloir mettre en place du déploiement continu alors que « le livre SCRUM dit qu’il faut faire une démo avant de livrer » 🙁

  2. Bien d’accord sur les vertus des ruptures.
    Juste une petite précision rugbystique qui ne remet pas en question l’excellent parcours du FC Grenoble en Top 14 : je pense que Fabrice Landreau évoquait la possibilité d’accéder aux barrages, pour les équipes classées de 3ème à 6ème.

  3. « c’est la complétude des 2 approches qui se révèle être réellement bénéfique pour l’entreprise » => « complémentarité » 🙂

  4. Bonjour Alex

    Bonne année !

    Merci pour ces définitions.

    Ce que j’ai pu remarquer :
    Les équipes commencent plusieurs mois avec du Scrum mais très vite Scrum ne suffit plus.

    Pourquoi ?
    Surement à cause des forces internes et à la pression des Seigneurs Sith !

    Mais aussi à cause de la Réalité (discutable je suis d’accord), plusieurs projets, de la dette …

    Alors l’équipe passe à un Scrumban pour gérer en mode Stories et non plus en mode projets.

    Pour Kanban, je l’utilise pour cartographier et améliorer le SI, donc pour moi ces pratiques ont leur cadre d’utilisation : Projet et process (voir BI).

  5. Je pense exactement le contraire de ce qui est expliqué dans l’article.
    Pour moi Kanban est un meta-process s’adaptant au contexte actuel de l’équipe (au sens large).
    Alors que SCRUM (enfin scrum pas bullshit – oui presque une oxymore ^^) fait appel à des valeurs bien spécifique qui sont partagées par bien peu de personnes, et surement non aisées à trouver dans une équipe lambda, non recrutée expressément dans ce sens.

    Kanban est pour moi un outil bien plus approprié que SCRUM pour tenter des transitions vers l’agile, avec toutes les pincettes que j’utilise avec cette activité (et je ne parle pas de la bullshit transformation agile).

    Dommage que tu n’ai pas eu l’occasion de voir du Scrum qui marche vraiment avec des équipes qui s’éclatent … moi j’en vois tous les jours … et avec des individus normaux … mais c’est toujours difficile.
    Alex

  6. Dans ma boite, on utilise les deux en fonction de l’impact que l’on veut avoir et des problèmes que l’on veut adresser. On part du principe que la phase de diagnostic s’en trouve renforcée mais que l’impact du coaching sera meilleur avec . On ne parle pas Scrumban qui ne veut pas dire grand chose tant ce que l’on met derrière diffère trop. On utilise une base Scrum avec des pratiques Kanban ou l’inverse. On fait plus du patchwork sur mesure.

    Ca faisait un moment que j’avais en tête d’écrire sur les critères de choix pour faire du Scrum ou du Kanban et c’est article m’a aidé à passer le cap. Pour éviter de polluer ce site, j’ai écrit ici : http://sretiere.wordpress.com/2013/01/09/agile-transformation-framework/

    Pour la petite histoire, je bosse en tant que coach Agile dans le même centre Agile que Laurent Sarrazin évoqué plus haut.

  7. Je n’ai pas dit que SCRUM c’était pas bien et que ca ne pouvait pas marcher avec des individus normaux.
    Cela demande juste l’acceptation par une majorité de l’équipe de certaines valeures.
    Kanban on part juste de « visualize your work » & « limit your wip ».

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *