Comment créer de l’agilité dans les projets (avec Dimitar Karaivanov de Kanbanize)

Lisez la transcription :

Nous testons la transcription de nos podcasts à l'aide d'un programme logiciel. Veuillez pardonner toute faute de frappe, le robot n'est pas toujours fiable à 100%.

Ben Aston :

Lean, Scrum, Scrumban, XP, SAFe, DaD, LeSS, DSDM, Kaizen, Kanban. Ça vous dit quelque chose ? Eh bien, ce ne sont que quelques-unes des méthodes existantes pour livrer en agile. Mais laquelle est la meilleure et pourquoi ? Continuez à écouter ce podcast pour comprendre comment vous pouvez apporter de l’agilité dans vos projets et les bénéfices d’une approche et d’un ensemble d’outils Kanban.

Merci de nous écouter. Je suis Ben Aston, fondateur de The Digital Project Manager. Bienvenue dans le podcast DPM. Nous avons pour mission d'aider les chefs de projet à réussir, d’aider ceux qui gèrent des projets à livrer plus efficacement. Nous sommes ici pour vous aider à élever votre niveau en gestion de projet. Consultez thedigitalprojectmanager.com pour découvrir nos formations et ressources que nous proposons dans le cadre de l’adhésion. Ce podcast vous est présenté par Clarizen, le leader des logiciels de gestion de portefeuille et de projets d'entreprise. Visitez clarizen.com pour en savoir plus.

Aujourd’hui, je suis en compagnie de Dimitar Karaivanov. Dimitar est un ingénieur devenu PDG, et il est le cofondateur de Kanbanize. Il est adepte du lean, praticien Kanban et possède un parcours dans le développement logiciel et l’amélioration de processus. Il a écrit plusieurs livres : Lean Software Development With Kanban et How Can Portfolio Kanban Benefit Your Business? Vous voyez le tableau : il est passionné par Kanban. Alors, bonjour Dimitar, merci de nous rejoindre aujourd'hui.

Dimitar Karaivanov :

Ben, merci de m’accueillir. C’est un plaisir de discuter avec toi et ton audience. J’ai hâte pour ce podcast.

Ben Aston :

Heureux de t’avoir parmi nous ! Et manifestement, tu es extrêmement passionné par Kanban et tu as construit tout un produit autour de Kanbanize. Mais du point de vue de PDG, je suis curieux : qu’est-ce que cela signifie vraiment au quotidien ? À quoi ressemble ta journée type en tant que PDG et co-fondateur de Kanbanize ?

Dimitar Karaivanov :

En tant que PDG, surtout dans une entreprise au stade avancé de startup, on porte beaucoup de casquettes. Je parle beaucoup aux clients, assurant souvent la gestion de produit.

Ben Aston :

D’accord.

Dimitar Karaivanov :

Puis j’échange avec l’ingénierie pour transmettre les retours clients, je suis impliqué dans la vente aux entreprises. Bien sûr, je contribue à la stratégie chaque fois que possible, car c’est essentiel pour un PDG. D’ailleurs, la stratégie peut aussi s’appliquer avec Kanban. Nous devrions d’ailleurs en discuter.

Ben Aston :

Oui, absolument. Mais avant d’y venir, j’aimerais en savoir un peu plus sur ton parcours. Comment t’es-tu lancé dans le développement de logiciels de gestion de projet ?

Dimitar Karaivanov :

Souvent, on y arrive par nécessité. J’étais agent du changement pour une grande entreprise allemande. Nous passions des processus en cascade à des processus agiles, et nous avons fait migrer environ 500 personnes de l’ancienne méthode de gestion de projets vers le scrum. Scrum était la norme pour toute nouvelle implémentation agile. Nous avons formé tout le monde à scrum, avec près de 25 équipes agiles ou plus, mais nous avons découvert que si les équipes pouvaient livrer de manière stable, c’était le chaos au niveau gestion, là où étaient les plus grandes parties du travail — dans notre cas, des features, épiques, etc. J’ai compris que nous manquions d’outils pour gérer à la fois au niveau équipe et au niveau coordination/management. Ainsi est née Kanbanize : dans le but de scaler l’agile dans l’organisation.

Ben Aston :

Intéressant. En lançant un outil de gestion de projet pour la première fois, tu as sûrement été inspiré — positivement ou négativement — par d'autres outils existants. Pourquoi avoir voulu en créer un nouveau ?

Dimitar Karaivanov :

Nous utilisions JIRA. C’est le mastodonte de 300 kilos partout. Il comporte de bonnes choses, mais à l’époque, la partie Kanban était très limitée, voire absente. Finalement, notre inspiration provenait plutôt d’un vrai tableau Kanban physique. Avec Kanbanize, nous avons essayé de transposer la visualisation physique du travail à un tableau digital Kanban, avec l’ajout d’une connexion à plusieurs équipes et l’agrégation des données pour le management. Donc, deux vraies sources d’inspiration : JIRA et les tableaux Kanban physiques.

Ben Aston :

D’accord. Bien sûr, tu as ton propre outil de gestion de projet, mais quels autres outils Kanbanize intègre-t-il, ou que tu utilises pour gérer l’entreprise ? As-tu découvert des outils particulièrement efficaces ?

Dimitar Karaivanov :

Je citerais Microsoft Teams, probablement l’application à la plus forte croissance de l’histoire du web. Nous utilisons aussi Kanbanize. Je passe beaucoup de temps sur Teams, surtout avec le télétravail actuel. Ensuite, la moitié de ma journée se passe sur un outil appelé Flow-e (flow-e.com), qui est un projet de notre entreprise. C’est Kanbanize, mais pour les emails : une couche de visualisation sur Outlook qui transforme votre boîte mail en tableau Kanban pour visualiser les emails et garder les conversations dans un flux kanban. Pour moi, c’est un sauveur. Je recommanderais vivement, et c’est gratuit.

Ben Aston :

Je vais regarder ça. Actuellement, j’ai 1189 mails non lus donc si je n’ai pas encore répondu… ce sera dans ma colonne « à lire » !

Dimitar Karaivanov :

Oui, c’est pour cela qu’on a créé Flow-e. Trop difficile de gérer tous les flux d’info. Je le recommande.

Ben Aston :

Revenons à Kanbanize. Tu es le PDG de Kanbanize, ton projet et celui de l’équipe initiale. C’est un tableau Kanban digital qui, parce qu’il est digital, offre plus de prévisibilité, d’analyses et de règles. Mais quel serait le profil de client idéal pour Kanbanize ? Qui utilise votre outil ?

Dimitar Karaivanov :

Nous sommes conçus principalement pour les entreprises d’ingénierie (logicielle, IT/devops, mais aussi ingénierie non IT comme la fabrication, la construction). Nous avons aussi des clients dans le marketing ou l’opérationnel (banque, assurance). Il y a deux cas principaux : la gestion de projet (ingénierie) et la gestion de service (banque, assurance). Ce sont nos clients idéaux. Je pourrais d’ailleurs développer sur la gestion de projet si tu le souhaites.

Ben Aston :

Oui, vas-y !

Dimitar Karaivanov :

Dans mon expérience, les chefs de projet planifient et estiment les projets, puis ce plan se transforme en tâches qui vivent dans un autre système. On a un plan parfait sur PowerPoint ou Microsoft Project, mais le travail réel est dans JIRA ou ailleurs.

Ben Aston :

Exact.

Dimitar Karaivanov :

Comment alors avoir l’état réel ? Il faut aller demander le statut manuellement.

Ben Aston :

Oui.

Dimitar Karaivanov :

Et harceler les gens : « Où en est-on ? Quel pourcentage ? » etc. Nous avons résolu ce problème avec Kanban, et spécifiquement Kanbanize, en connectant la planification à l’exécution. Kanbanize propose une couche dédiée à la planification et une couche à l’exécution, reliées pour transmettre les retours instantanément. Ainsi, dès que l’équipe commence une tâche, l’info remonte automatiquement au management. Si le plan est en danger, le chef de projet est alerté sans attendre une semaine. C’est plutôt génial.

Ben Aston :

Vous recevez une notification « votre projet risque d’échouer ». Un avertissement poli — le mail que tout le monde redoute ! Mais le cœur du sujet, ce sont les membres de l’équipe. Le défi de tout outil reste de faire mettre à jour l’outil par l’équipe. Comment avez-vous conçu le système pour avoir une vue en temps réel et inciter les utilisateurs à documenter l’avancement ?

Dimitar Karaivanov :

Tu as raison, c’est un vrai problème. La solution réside dans la méthode Kanban, qui va bien au-delà d’un tableau blanc au mur. Il existe par exemple le Kanban Maturity Model, qui codifie plus de 150 pratiques. L’un des piliers est la boucle de feedback — les boucles de feedback sont des réunions régulières. Parmi elles, la réunion kanban quotidienne, où l’équipe se retrouve devant le tableau (virtuel ou physique). L’accent est mis sur le travail : on passe en revue chaque carte en cours, on vérifie si elle doit changer de colonne, etc. Ainsi, au moins une fois par jour, les cartes sont à jour.

Ben Aston :

C’est intéressant ce focus sur le travail plutôt que la personne. On connaît tous des daily standups où chacun répète « je fais le widget de la veille ». Mais cela n’apporte pas vraiment d’insights. Se concentrer sur le travail favorise la clarté sur l’avancement réel. Pour en revenir aux outils, comment Kanbanize se différencie-t-il des autres ?

Dimitar Karaivanov :

Je reviens au Kanban Maturity Model (KMM) qui distingue 6 niveaux de maturité, chacun impliquant différentes pratiques. Trello, par exemple, permet d’atteindre 1 ou 2 seulement, car il manque de fonctionnalités Kanban avancées comme la limitation du travail en cours (WIP) sur plusieurs colonnes, des couloirs horizontaux, différents tableaux, etc. Kanbanize met vraiment l’accent sur ces aspects. Les métriques de flux, les simulations Monte-Carlo, etc., sont natives chez nous et nécessitent souvent un add-on payant ailleurs — qui n’est pas toujours bien intégré. Kanbanize est pensé pour des scénarios kanban sophistiqués, notamment le passage à l’échelle, là où Trello reste un bon outil d’équipe, mais peu adapté au-delà, et JIRA repose davantage sur Scrum et sa propre logique. Kanban prévoit les échéances selon les réalisations passées (flux réel) plutôt que sur les estimations d’équipe type Scrum. La différence paraît faible, mais amplifiée à l’échelle de 20, 30, 40 équipes, elle devient énorme. Kanban se base sur l’historique réel du flux; c’est un point fondamental.

Ben Aston :

Prenons un peu de hauteur : tu expliques que Kanban vise à augmenter le débit, donc la capacité à accomplir plus en limitant le travail en cours, non en multipliant les tâches. C’est essentiel : moins on traite de choses en parallèle, plus on finit rapidement, plus on s’améliore en débit et efficacité. Voilà l'esprit kanban.

Dimitar Karaivanov :

Exact, il faut trouver le bon équilibre car trop brider le WIP peut nuire au débit. Chaque organisation doit expérimenter pour trouver sa limite optimale. Il n’existe pas de règle universelle, il faut mesurer et ajuster selon les résultats chaque semaine.

Ben Aston :

Où va Kanbanize dans l’avenir ? Quelles sont les prochaines étapes sur la feuille de route ?

Dimitar Karaivanov :

En 6 semaines ? Nous allons automatiser davantage les tâches décisionnelles du chef de projet : plus besoin de tout calculer soi-même — Kanbanize fait directement les simulations et prévisions. L’intelligence artificielle ? Aujourd’hui, les meilleurs résultats sont encore obtenus avec des méthodes statistiques (Monte Carlo notamment), mais le secteur évolue. Notre objectif est de décharger les PM des tâches de monitoring pour qu’ils se concentrent sur la création de valeur.

Ben Aston :

La plupart de nos auditeurs sont chefs de projet. Penses-tu que leur métier va évoluer avec l’automatisation, se rapprocher du product management ?

Dimitar Karaivanov :

Le chef de projet ne doit pas simplement faire circuler les informations et remplir des rapports, mais enrichir la donnée, remettre en question les besoins et la valeur produite. Aujourd’hui, beaucoup se contentent de transmettre les besoins, faire le suivi et enfin livrer au client. C’est utile, mais pas suffisant. Avec l’automatisation du reporting, ils auront plus de temps pour s’assurer que la solution répond vraiment au problème client. C'est plus humain et plus valorisant.

Ben Aston :

Et au niveau du marché, comment est-ce que tu vois la concurrence et l’évolution des outils PM ?

Dimitar Karaivanov :

C’est un marché saturé au niveau des petites équipes. Kanbanize n’est pas seulement un outil d’équipe, il devient une solution de gestion de portefeuille agile. Cela demande des années de développement. Les géants du secteur comme JIRA misent encore sur scrum. Mais je crois, sans être prétentieux, que l’avenir repose sur la mise en place d’un flux d’informations du terrain vers le top management, pour amener l’agilité au niveau de l’entreprise entière. Les outils d’équipe existeront toujours, mais ceux qui répondront au défi de l’agilité à l’échelle gagneront le marché.

Ben Aston :

Tu as aussi écrit un article intitulé Kanban Powered Business Agility. Peux-tu expliquer ce que signifie, selon toi, l’agilité business ?

Dimitar Karaivanov :

Pour moi, l’agilité business, c’est la capacité à satisfaire son marché par l’apprentissage rapide, l’expérimentation et leur application. Ce n’est ni un cadre, ni une certification, mais la faculté d’apprendre et d’utiliser ce savoir pour créer plus de valeur.

Ben Aston :

Tu sembles être un grand défenseur de Kanban face à Scrum, notamment car Kanban prône « commencez là où vous êtes et évoluez expérimentalement ». C’est une différence fondamentale avec les autres approches plus rigides ?

Dimitar Karaivanov :

Oui, Kanban offre ce point d’entrée humain, progressif, respectueux du contexte. Il ne bouleverse pas tout du jour au lendemain. Bien appliqué, c’est une approche humaine qui réduit le stress et la surcharge, favorise la concentration et la satisfaction au travail. Le principal défaut de Kanban ? Beaucoup le réduisent à un simple tableau, alors qu’il existe une quantité considérable de littérature et de bonnes pratiques derrière.

Ben Aston :

L’avantage de Kanban, c’est aussi que son concept est simple à comprendre contrairement à Scrum et ses nombreuses cérémonies. Kanban permet de s’initier à l’agilité doucement, sans tout bouleverser — un bon point d’entrée.

Dimitar Karaivanov :

Exactement, et vouloir tout imposer d’un coup serait prétentieux. Les entreprises qui délivrent déjà un produit apprécié ont déjà des méthodes qui fonctionnent. Il vaut mieux observer, comprendre, puis améliorer sur cette base. C’est un principe valable dans tous les domaines.

Ben Aston :

Dans ton article, tu parles de raffiner le workflow pour éliminer les gaspillages, être plus lean et réduire le WIP. Mais concrètement, comment fait-on ?

Dimitar Karaivanov :

En observant l’accumulation des tâches sur le tableau. Généralement, après avoir commencé à visualiser son flux, on identifie des endroits où les cartes s’accumulent : c’est là que le workflow coince. On peut alors introduire des colonnes intermédiaires (« Prêt pour revue »…), diagnostiquer les goulots d’étranglement, appliquer des limites de WIP, raffiner, mesurer, ajuster. Et on recommence le cycle !

Ben Aston :

Donc l’objectif est bien d’éliminer les goulots, car la valeur ne se crée qu’à la finalisation des tâches.

Dimitar Karaivanov :

Exact, il faut surveiller le temps de cycle (temps qu’une carte passe sur le tableau). Plus il est court, mieux c’est. S’il s’allonge, c’est qu’il y a accumulation. Il faut alors revoir le workflow et les limites.

Ben Aston :

Tu évoques aussi dans ton article la transformation des HIPPOs (Highest Paid Person’s Opinion) en HIPO (Highest Probability Option) : c'est passer du pouvoir hiérarchique à la décision basée sur la donnée. Quel est ton conseil à ton équipe là-dessus ?

Dimitar Karaivanov :

Ce n’est pas facile. J’ai moi-même fait beaucoup d’erreurs. Dès que j’entends une décision prise à l’instinct, sans donnée, j’interroge et challenge pour encourager à réfléchir : « comment es-tu arrivé à cette conclusion ? » Tout le monde veut avoir raison, et en tant que PDG, j’ai forcément du poids. Mais quand la data infirme mon avis, je dois écouter. J’encourage systématiquement à rechercher la data, à argumenter avec des faits. Ça prend du temps mais c’est la culture qu’on veut ancrer. Persévérance et exigence sur ce point finissent par payer.

Ben Aston :

Pour finir : pour ceux qui veulent commencer à rendre leurs projets plus agiles via Kanban, que recommandes-tu comme tout premier pas ?

Dimitar Karaivanov :

Il faut d’abord visualiser le travail. Un simple tableau physique suffit (post-its, magnets, colonnes…). Aucune excuse pour ne pas visualiser. Ensuite, limiter le WIP, même si on commence avec une limite très haute, que l’on réduira au fil du temps. Troisième conseil : se former sérieusement auprès de Kanban University, qui regroupe des formateurs partout dans le monde — former les personnes clés vaut l’investissement.

Ben Aston :

Ce que tu dis rend le premier pas (visualiser le processus, identifier les douleurs) accessible. Souvent, chaque membre d’une équipe a une vision différente du processus actuel. Visualiser permet d’aligner, de détecter les points faibles et d’amorcer l’amélioration. Merci Dimitar, c'était très instructif. Pour découvrir Kanbanize : kanbanize.com (lien dans les notes). Merci d’avoir été avec nous !

Dimitar Karaivanov :

Merci, Ben. J’ai pris plaisir à échanger. Au plaisir !

Ben Aston :

Pour progresser, rejoignez notre communauté DPM : thedigitalprojectmanager.com/membership pour des templates, ateliers, sessions A.M.A., heures de bureau, e-books, etc. Abonnez-vous sur thedigitalprojectmanager.com. À bientôt et merci pour votre écoute.