Kanban est le nouveau Scrum

Scrum est la nouvelle norme d’organisation du travail autour d’un produit mais cela n’est pas en adéquation avec toutes les organisations. Les plus grosses d’entre elles qui sont souvent dans une culture hiérarchique et de contrôle avec d’anciennes pratiques managériales trouvent Scrum trop agile, trop simple pour leur organisation complexe. A l’inverse des startups qui se lancent peuvent trouver Scrum trop lourd, trop compliqué pour leurs besoins.

Naturellement 2 courants ont émergé :

• Complexifier Scrum : Scrum of Scrums, LeSS, Scrum@scale, SAFe ;
• Simplifier Scrum : Kanban.

J’aime la simplicité. J’aime le no bullshit. J’adore Kanban, encore plus que Scrum. Mais commençons par parler de Scrum of Scrums, Less, Scrum@scale et SAFe.

Scrum of Scrums

C’est la version officiel de Scrum pour gérer le multi-équipe sur un produit. En plus du Scrum classique, avec le Scrum of Scrums, il convient d’ajouter de courtes réunions quotidiennes au cours desquelles une personne de chaque équipe (pas forcément le SM ou le PO, bien au contraire !) se réunissent pour suivre les progrès entre les différentes parties du produit afin d’anticiper tout problème de dépendance ou de synchronisation.

LeSS (Large Scale Scrum)

Après le Scrum for Scrum, LeSS est le plus simple à mettre en place. LeSS recommande un PO, un seul Product Backlog partagé par toutes les équipes et un Sprint Backlog par équipe. Les sprints de toutes les équipes sont synchronisées. Le Sprint Planning change, il est désormais en deux parties : une partie avec une personne par équipe pour choisir les éléments du Product Backlog pour le sprint courant, l’autre partie pour que chaque équipe produise leur Sprint Backlog. Le Sprint Review lui ne change pas. Le Sprint Retrospective est divisé en deux parties tout comme le Sprint Planning.

Scrum@scale

Avec Scrum@Scale, le PO doit avoir une vision stratégique, prioriser le backlog au niveau entreprise, portfolio et produit, distribuer les tâches entres les équipes, gérer des planning de releases et les plannings de synchronisations. Le SM lui doit coordonner les équipes pour ne pas qu’elles fassent deux fois le même travail et gérer tous les problèmes du quotidien.

SAFe

SAFe est le plus compliqué, il ajoute des niveaux : portfolio, program, team mais aussi des rôles : Product Manager, System Architect, Release Train Engineer, Portfolio Manager, Entreprise Architect, Epic Owner. Il mélange de l’agile mais aussi des choses plus lourdes de l’ancien monde. Je ne rentrerai pas dans les détails ici mais les entreprises pratiquant SAFe ne sont généralement finalement pas très agile :).

Kanban, la prochaine étape de l’agilité ?

En Kanban pas de sprint, les changements sont les bienvenus en tout temps. Kanban fonctionne très bien avec le déploiement et l’intégration continue (CI/CD). Il n’y a pas vraiment de rôle mais souvent il y a un Product Manager ou Product Owner. Par contre pas de SM, ce n’est pas du Scrum. On dit que le Kanban est le prochain level de l’agilité car il utilise tout ce que l’on a appris avec Scrum et permet un nouveau mode d’organisation encore plus flexible.

Concrètement cela (peut) ressembler à ce tableau :

Backlog	To Do	Development – Doing	Development – Done	Testing – Doing	Testing – Done	Done
Add Google Analytics reports in the Dashboard Allow SSO connection Add a password recovery system	Translate support pages in French Add a FAQ Page Add tools to crop images inside the backoffice	Correct the css style in the support page Change the UI of the dashboard page	Fix Bug A234	Add a paypal payment option	Update security Fix Bug A233	Configure a cloud object storage Install a SSL certificate

Il y a autant de façon de faire du Kanban que de types de projet. J’aime particulièrement bien ce board avec ces 7 colonnes car il reste simple. Les items peuvent êtres des bugs, des tâches, des users stories, il n’y a pas vraiment de règle. Les priorités entre ce qu’il y a à faire peuvent être implicitement définies par l’endroit où se trouve l’item (plus il est haut, plus il est prioritaire) mais il est aussi possible de faire autrement comme par exemple utiliser la priorisation MoSCoW avec un code couleur.

On peut aussi ajouter une estimation de temps pour chacun des items. Ainsi, nous aurons une vue “valeur / effort”. Enfin, il est conseillé de limiter le Work in Progress (WiP), c’est à dire de limiter le nombre d’items maximum dans chaque colonne. Pour la colonne To Do (items à l’état prêt), il est possible de mettre une limite basse. Mais encore une fois ce n’est pas obligatoire.

Dans Kanban, les développeurs ne peuvent pas hiérarchiser le backlog en fonction de leur opinion. Seul le PM / PO peut le faire. De plus, il peut redéfinir les priorités à n’importe quel moment.

Scrumban est le terme pour désigner les équipes qui mixent les deux : du Scrum comme processus et du Kanban pour la visualisation. Parfois Kanban remplace complètement Scrum pour des équipes Scrum qui ont beaucoup d’expérience. C’est mon approche privilégiée du moment pour le développement : manifest craftmanship + TDD + Kanban + CI/CD.

Vous me direz que c’est trop agile. Que ce n’est pas possible pour une ETI ou une grande entreprise. Et bien figurez-vous qu’Amazon qui a sûrement plus d’employés, de produits et de problèmes critiques que vous, déploie 23 000 fois par jour !

Kanban : un exemple concret de A à Z

Le projet / produit

Vous lancez un nouveau produit : une plateforme de mise en relation entre les influenceurs et les entreprises.

Le pitch : Les entreprises ont besoin de travailler leur marque employeur. Cela peut par exemple leur permettre de recruter plus facilement des profils sur des métiers en tension. Les influenceurs, experts métiers ou célébrités locales, peuvent promouvoir ces entreprises auprès de leurs communautés.

Concrètement, une entreprise recherchant un profil technique spécialisé en Kubernetes va être mise en relation avec un youtuber expert Kubernetes afin que celui-ci parle de cette entreprise dans sa prochaine vidéo. A l’issue de cette vidéo, l’entreprise reçoit de nouvelles candidatures ciblées pour son poste et recrute son talent.

Le Portfolio Kanban

C’est un Kanban de fonctionnalités, plus précisément de MMFs (Minimal Marketable Features).

Planned	In Progress	Done
Personas system (meta-tags) for companies Payment management (multy party) Make pillar pages for seo ROI page	Add influencers Tag management system on influencers Filter influencers Add gigs	Implementation of the architecture Business Sign Up

Il est possible d’aller plus dans le détail si vous avez plusieurs équipes en divisant la partie “In Progress” en deux : Team A, Team B.

Il est également possible de faire un Kanban Roadmap si vous avez des besoins de planification plus important.

in 6 months	In 3 months	This month	Ready to Start	In Progress	Done
ROI page	Make pillar pages for SEO	Payment management (multi party)	Personas system (meta-tags) for companies	Add influencers Tag management system for influencers Filter influencers Add gigs	Implementation of the architecture Business Sign Up

Le Team Kanban

C’est le Kanban de tâches. Il y en a un par équipe. Il est lié au Portfolio Kanban : chaque carte du Porfolio Kanban est le parent de une ou plusieurs cartes du Team Kanban. Ainsi, si une des tâches est en Work In Progress (Development ou Testing) alors la carte parent doit être aussi dans In Progress, si toutes les cartes enfants sont terminés (Done) alors la carte parent est elle aussi terminée.

Backlog	To Do	Development – Doing	Development – Done	Testing – Doing	Testing – Done	Done
Setup Stripe payment Setup multi party payout Create a pillage page to attract influencers Create a pillage page to attract companies Create a page with all ROI stats	Create a form in admin to add a persona Filter influencers with a persona	Bulk import of influencers for an admin Create an influencer signup page Filter influencers by social networks Filter influencers by gigs	Create an influencer profile page Filter influencers by location Create a form to add a gig	Filter influencers by tags Create a generic list of gigs	Create a generic list of jobs tags Create a tag system	Create the GIT repo Setup the front environment Setup the back environment Setup the database Create the signup form Create a form to add manually an Influencer for an admin Create a generic list of skills tags Create a generic list of cities tags

La Kanban Card

Chaque item (tâche) dans le tableau Kanban est communément désigné comme une carte. Cette carte peut être un simple texte ou aller plus dans le détail en y ajoutant une description sous forme de user story, une ou des maquettes voire des prototypes, des conditions d’acceptation, une estimation du temps, des tags (comme une priorité MoSCoW ou encore pour spécifier le produit si une seule équipe travaille sur plusieurs produits ou bien la DoD associée), une dépendance (sous forme de liens prédécesseur-successeur entre cartes), etc.

Filter influencers by social networks peut alors devenir ceci.

User story	Wireframe / Mockup / Prototype	Tags	Acceptance criteria
As a Company, I want to filter influencers by social networks so that I can see relevant influencers for my need. Estimated time: 4 hours Dependency : Create a tag system card		Should have Classic DoD	Scenario : The company wants to filter influencers by social networks Given that I want to filter influencers by social networks When I click on the “filter by social networks” menu and select some items Then I only see influencers who offer gigs on the social networks that I have selected

Les outils

Pour les tableaux Kanban vous avez le choix en beaucoup d’outils : Trello, Notion, Kanbanize, Jira mais vous pouvez également utiliser des Post-it et un tableau blanc. Pour les Mockups, Figma est assez complet.

Le Feedback

Le projet se développe, des tâches sont terminées ainsi que des fonctionnalités. C’est bien mais ce n’est pas suffisant. Il faut désormais prendre en compte le feedback (données, utilisateurs, clients).

Si vous êtes en b2b avec peu de clients ou d’utilisateurs, le Sprint Review (en mode Scrum) avec ces parties prenantes suffit pour obtenir le feedback nécessaire à l’amélioration du produit.

Si vous êtes en b2b avec beaucoup de clients ou en b2c avec beaucoup d’utilisateurs, il faut se servir de toutes les data que vous avez à votre disposition.

Il y a les données que vous récoltez en interrogeant explicitement vos utilisateurs : formulaire, questionnaire, popup, chat, emailing via des logiciels et service comme : Typeform, SurveyMonkey, Messenger, ManyChat, Helpscout, Intercom, Autopilot, Wisepops, Mailchimp.

Et il y a les données que vous récoltez automatiquement : solution interne ou open source, Amplitude, Mixpanel, Google Analytics, Hotjar. Certains de ces outils vous permettent même de faire de l’A/B Testing sans code supplémentaire.

L’A/B testing est très important pour continuellement améliorer votre produit. Il peut aussi bien servir pour le webmarketing (tester différentes publicités, tester différents messages) que pour le produit (tester différentes versions d’une page et voir celle qui fonctionne le mieux). Dans le cas du produit, vous choisissez un but (exemple : avoir le plus d’inscriptions possible) puis vous testez des variations sur des audiences similaires (exemple : 2 formulaires d’inscription différents). La variation qui obtient le meilleur résultat sera utilisée dans la version finale du produit. La variation peut porter sur la mise en page, les boutons, les textes, les images, etc. Le but est d’améliorer le produit et tout ce qui tourne autour de lui : augmenter les ventes, augmenter le taux de conversion des inscriptions, augmenter le chiffre d’affaires par client, augmenter le temps passé sur le logiciel, augmenter le nombre de clic sur un bouton, diminuer le churn, etc.

Une fois que vous avez assez de données et qu’elles sont statistiquement significatives, vous pouvez créer la carte Kanban correspondant à la variation la plus efficace. Imaginons que nous avons testé 2 versions de la carte Filter influencers by social networks : une version avec toutes les options non cochées par défaut (celle actuellement utilisée) et toutes les options cochées par défaut et que le résultat donne cette 2ème version vainqueur, alors nous pouvons ajouter une nouvelle carte à notre Kanban.

User story	Wireframe / Mockup / Prototype	Tags	Acceptance criteria
As a Company, I want to see by default all influencers so that I can narrow down relevant influencers by filtering them by unchecking social networks that do not interest me. Estimated time: 1 hour Dependency : Filter influencers by social networks		Should have Classic DoD	Scenario : The company wants to filter influencers by social networks Given that I want to filter influencers by social networks When I click on the “filter by social networks” menu Then I see that all options are checked by default

Le Kanban est donc vivant, il évolue continuellement. Vous ajoutez des fonctionnalités, des users stories, des tâches, des résolutions de bugs, des résultats d’A/B testing. Vous pouvez même l’utiliser pour les actions marketing et de communication (à quoi bon lancer une nouvelle feature si le marketing n’est pas prêt ?). Bref, il n’y a pas vraiment de règles et cela dépend de vos besoins. C’est la beauté de la flexibilité offerte par l’agile !