Le livre Real World Kanban de Mattias Skarin présente quatre études de cas d'usage de Kanban pour de la visualisation, fournir des idées et améliorer le développement de produit.
Les lecteurs InfoQ peuvent télécharger un extrait du livre Real World Kanban [en].
InfoQ a échangé avec Mattias Skarin sur sa perception de l'essence du kanban et du lean, le besoin de flexibilité dans les organisations, l'utilisation des données dans l'utilisation des produits pour l'amélioration continue, l'aide apportée aux équipes par la visualisation pour comprendre les problèmes, la recherche de temps pour s'améliorer, l'usage des rétrospectives en Kanban pour l'amélioration continue et des conseils sur le démarrage.
InfoQ : Qu'est-ce qui vous a décidé à écrire un ensemble d'étude de cas sur Kanban ?
Skarin : Un bon moyen d'apprendre est par l'exemple. Je voulais donc montrer ce qui se passe en vrai en utilisant Kanban. Les choses se passent rarement comme dans la théorie.
Ensuite, je sentais qu'il était important de partager des exemples d'entreprises plus classiques et de leur amélioration par un facteur de deux ou plus. Il y a peu d'entreprises qui démarrent comme le prochain Spotify. Elles ont un historique - des rôles, fonctions, processus, dettes techniques et perception du fonctionnement du monde les ayant menés là où elles sont aujourd'hui. On parle assez peu de la manière dont ces entreprises s'améliorent, de leurs adaptations et évolutions, et il y a beaucoup à apprendre d'elles.
InfoQ : Pourriez-vous rapidement décrire ce que vous pensez être l'essence de Kanban et du Lean ?
Skarin : Améliorer en continu le flux de bout en bout (améliorer l'ensemble est plus important que l'amélioration des parties). Il faut ensuite considérer les personnes, en construisant des organisations qui utilisent et mettent à profit les forces humaines (la créativité, l'ingéniosité, le travail d'équipe, faire la différence) - plutôt que de construire des systèmes qui rendent le travail pour les individus impossible. Le leadership (diriger par l'exemple), la responsabilité et la construction d'une culture de l'expérimentation, sont les trois éléments clés qui permettent à cela d'apparaître.
InfoQ : Pourriez-vous expliquer pourquoi il ne faut pas laisser avancer les défauts dans le développement de logiciel ?
Skarin : Il y a deux sujets. L'aspect économique - le coût de résolution d'un problème est exponentiel avec le temps. Mais il est d'autant plus important de construire une culture de la responsabilité et de la qualité. Nous ne passons pas des choses de mauvaise qualité aux autres. C'est l'autre aspect.
InfoQ : Dans votre livre, vous expliquez pourquoi il faut de la flexibilité dans les organisations pour saisir des opportunités de marché. Auriez-vous des exemples ?
Skarin : Nous avons besoin de flexibilité pour explorer d'autres modèles d'affaires, pour tester des processus métier différents, pour innover. Elle est aussi importante pour la construction de produit, car elle permet de modifier l'architecture et laisse l'équipe explorer d'autres options technologiques. Enfin, elle permet de former plus vite de nouvelles personnes. En bref, la flexibilité est plus importante que l'alignement.
InfoQ : Un des cas du livre présente l'amélioration continue avec les données d'usage de produits en cours de développement. Pouvez-vous expliquer la manière dont les équipes ont fait ?
Skarin : Nous avions une solution très low-tech :) Quand le nouveau produit fut lancé, le département marketing a interrogé les utilisateurs sur leur expérience. Cette information fut renvoyée à l'équipe de développement sur deux forums différents. D'abord, nous avions une démonstration mensuelle au niveau de l'entreprise où le marketing présentait les découvertes les plus importantes des itérations précédentes. Ensuite, le responsable de cette idée participait au rendez-vous au niveau du tableau Kanban d'entreprise pour y partager ces expériences. Nous gardions aussi une trace visuelle de ces lancements réussis (clients contents d'utiliser) et des échecs. Si les clients n'étaient pas satisfaits, nous faisions une analyse causale ensemble pour comprendre ce qu'il fallait changer.
InfoQ : Auriez-vous un exemple montrant la manière dont la visualisation aide les équipes à comprendre leurs problèmes et à les résoudre ?
Skarin : La simple présentation de l'ensemble du travail en cours par l'équipe est souvent une surprise. Ceci pousse plusieurs équipes à se concentrer et prioriser, en tant qu'équipe, plutôt qu'en tant qu'individu. Un autre exemple était de montrer l'avancement d'une plateforme en cours depuis plusieurs mois. En montrant juste ce qui devrait vraiment être fait, nous avons réussi à nous concentrer dessus et les livrer en une semaine ou deux.
Un autre aspect est que la visualisation peut aussi aider à éclairer ce qui n'est pas un problème. Une fois, nous avons choisi de visualiser ce que les équipes faisaient de leur temps. Ceci nous a aidé à briser le mythe que les équipes individuelles ne travaillaient pas de manière sous-optimales sur le développement de l'idée en répartissant dans des équipes individuelles.
InfoQ : Beaucoup d'équipes sont débordées par le travail. Auriez-vous des suggestions pour dégager du temps pour s'améliorer ?
Skarin : Oui, il y a plusieurs choses à faire.
D'abord, visualisez le travail que vous faîtes. La simple vision vous donnera des perspectives.
Ensuite, apprenez à utiliser des limites de WIP. Si c'est trop compliqué, utilisez des limitateurs physiques. Ceci facilite souvent une équipe sous stress à réaliser qu'elle est en train de briser un engagement.
Troisièmement, priorisez le flux amont. Si vos fonctions antérieures ne prennent pas leur responsabilité en le faisant, alors faîtes le pour elles (et dites leur qu'elles devront en accepter les conséquences).
Quatre : en cas de débordement, vous avez des arguments de poids pour reporter les activités suivantes :
- Le travail planifié très en amont dans le futur (il est préférable de faire ceci "juste à temps" que "longtemps en avance". Une chose est sure : le plan va changer !).
- Dates fixes sans explications claires des conséquences. Il y a de vraies dates limites avec des conséquences économiques (fenêtre d'introduction) et des dates prévues ("nous avons promis").
- Qualité du flux amont faible. Petit à petit, renvoyez le travail de mauvaise qualité arrivant dans votre backlog à l'équipe productrice (plutôt que de l'améliorer pour elle).
- Répondre aux questions du type "où est mon...", "comment fais-je pour ...". Réduisez l'arrivée en créant un wiki avec des questions simples, formant les équipes environnantes à répondre aux questions basiques et en posant un tableau Kanban de statut pour répondre aux questions avec le tableau plutôt que par téléphone.
Aucun de ces choix n'est facile, mais préférez-vous continuer à gaspiller ? Nous ne pouvons probablement pas réparer toute l'organisation en une fois, mais nous pouvons décider de construire un environnement de travail acceptable pour les personnes de notre groupe.
Note : Les trois prochaines questions ont été posées à l'issu du LKFR15 par l'équipe InfoQ FR.
InfoQ FR : Pendant le LKFR15, vous avez présenté la "loi de Skarin". Pourriez-vous la partager avec nous, et nous expliquer son sens ?
Skarin : La loi de Skarin s'exprime de la manière suivante :
"Le nombre d'initiatives d'amélioration dans un système Kanban est proportionnel à la confiance que les membres ont dans l'objectif du système."
Cela signifie que lorsque vous demandez à une équipe d'utiliser un outil ou un processus (Kanban, Scrum, etc.), leur confiance dans l'objectif de ces outils est directement liée au sentiment d'appartenance et aux initiatives qu'ils essayeront. Cela est important car ce que nous cherchons est le changement tiré par les initiatives. De plus, c'est souvent une bonne idée de s'accorder sur le problème à résoudre avant d'introduire un outil. La question de fond pour tout changement est : est-ce que je facilite la délivrance de valeur avec une bonne qualité ?
InfoQ FR : Dans votre présentation, vous avez mentionné une "mission ratée". Pourriez-vous partager le contexte et ce qui s'est passé ?
Skarin : J'ai décrit ce qui se passe lorsque Skarin oublie la loi de Skarin :) Au lieu d'aider une équipe d'architecture à résoudre leur problème, j'étais trop excité par l'utilisation de Kanban et les choses se sont mal passés.
InfoQ FR : C'est assez rare d'entendre quelqu'un s'exprimer sur ses erreurs. Pourquoi un tel partage, et qu'avez-vous appris dans ce processus ?
Skarin : Nous apprenons de nos erreurs. En fait, nous devrions célébrer le fait d'en faire. Si nous n'en faisons pas, nous ne nous améliorons pas. Les erreurs apportent leur lot d'apprentissages, mais c'est notre rôle de le rendre possible. La seule erreur est de ne jamais apprendre de ses erreurs.
InfoQ FR : Pouvez-vous partager quelques exemples de l'usage des rétrospectives pour l'amélioration continue avec Kanban ?
Skarin : Une bonne rétrospective commence avec un retour au tableau. Qu'est-ce qui s'est passé, qu'est-ce qui est bloqué, qu'est-ce qui a résolu ces blocages, a-t-on produit du travail de qualité ? Après cela, regardez les graphiques : que s'est-il passé avec les temps de cycle ? Quel pourcentage de travail a été retraité ? D'où provient-il ? Enfin, on s'intéresse à l'expérience des membres de l'équipe. Un élément clé est l'inclusion du management en soulignant leur impact sur les blocages et la résolution des problèmes transverses à l'entreprise.
La clé pour la réussite des rétrospectives est de rester concentrer sur le flux avec une orientation données, et impliquer le management dans la résolution des problèmes entre équipes.
InfoQ FR : Si une organisation s'intéresse au déploiement de Kanban, auriez-vous un conseil pour le point de départ ?
Skarin : Une bonne manière de commencer est de lire un livre. Un autre moyen est d'observer d'autres équipes kanban. Puis, suivez un cours pour apprendre les principes de base et la manière dont ils apportent de la valeur (en vous aidant à vous améliorer en continu). Et enfin, jetez vous à l'eau et essayez ! Nous apprenons par l'expérience. Il est parfois utile d'avoir un coach expérimenté pour vous accompagner au début. Un tel coach peut vous aider en apportant une nouvelle perspective.
A propos de l'Auteur du Livre
"Sun Tzu disait que la responsabilité ultime du général est de diriger vers une position de succès. Comment y arriver dans le logiciel ? C'est ma quête."
Mattias Skarin (un gars de chez Crisp) accompagne et forme les équipes de management et les flux métier sur la construction et l'extension d'un avantage compétitif dans un environnement global changeant vite. Mattias est l'auteur du livre "Real world kanban" et le co-auteur de "Kanban and Scrum, making the most of both". Vous pouvez aussi lire son blog.
L'équipe InfoQ FR remercie l'auteur original de l'article, Ben Linders, pour avoir accepté l'ajout des questions autour de la loi de Skarin.