Laurent Morisseau's Blog, page 13

Apportez votre Kanban en vacances

Les vacances arrivent, le travail se calme un peu. C’est le bon moment pour recharger les batteries et prendre le temps de faire un peu de veille.

Alors voici un bestof des dernières ressources Kanban que vous avez peut être loupé en ce début d’année.

D’abord une vidéo sur Kanban, pour avoir un tour d’horizon de la démarche

Ensuite une vidéo sur Scrumban, pour découvrir comment Kanban peut aider Scrum à sortir de sa zone de confort

Pas le temps de regarder la vidéo ? Voici une série de podcast à écouter sur la plage :

Episode #1 : une story = 1 developpeur (ouch!)
Episode #2 : gérer des tâches émergentes
Episode #3 : travailler avec des bgoulets (d’étranglement)
Episode #4 : un PO dépassé par son Product Backlog
Episode #5 : gérer les dépendances externes
Episode #6 : faire la course à la feature
Episode #7: les bénéfices du ScrumBan

ou sur  iTunes 

Vous voulez commencer doucement avec  du management visuel ? Peut-être que la suite vous donnera quelques idées :

Et pour ceux qui veulent faire une pause numérique et revenir au simple plaisir de tourner les pages d’un livre :

Bonnes vacances à tous !

Vos dates de formations Agile / Kanban pour la rentrée

Pour la rentrée, nous vous proposons une sélection de formations événementielles :

Kanban

Formation Kanban accréditée, 2 jours, 9/10 Septembre, Paris
Formation Kanban accréditée, 2 jours, 16/17 Septembre, Lyon
Formation introduction Kanban, 1 jour, 9 Octobre, Toulouse, en binôme avec Claude Aubry, la veille d’Agile Tour Toulouse
Formation introduction Kanban, 1 jour, le 23 Octobre, Genève, en binôme avec Jacques Couvreur, la veille de Soft Shake
Formation Kanban pour manager, 2 jours, 12/13 Novembre, Paris,  en binôme avec Alexis Nicolas, après la conférence Lean Kanban France - Programme en ligne à la rentrée
Formation Kanban, 2 jours, 18 /19 Novembre, Paris
Formation introduction Kanban, 1 jour, le 20 Novembre, Grenoble, en binôme avec Alexandre Boutin, la veille d’Agile Grenoble

Scrum

Formation Scrum, 2 jours, 30 Septembre / 1er octobre, Nantes
Formation Scrum, 2 jours, 9/10 Décembre, Rennes

Innovation Games

Innovation Games avec l’expert Français du monde agile : Alexandre Boutin, 1 jour, le 18 Octobre, le lendemain d’Agile Tour Rennes

Management Visuel

Formation Management visuel, 1 jour, 15 Novembre, Paris, en binôme avec Thomas Lissajoux

Réservez vos dates !

Kanban Digest #26

Le meilleur du #Kanban lu cette semaine sur le Web :

Lu sur Twitter

@alshalloway managing WIP (queues) is a proxy for managing delays. Other half is implementing feedback loops-provides ideas for better workflow-eg ATDD


@maukoquiroga It’s not about deliverything before, but on time. Allocate capacity by risk, cost of delay and opportunity cost of delay.


@maukoquiroga The first change drove by #kanban isn’t a despicable one: become aware of where we are.


@cyetain Flow… and continuous delivery allows us to « sample » reality more frequently @hakanforss


@pawelbrodzinski Portfolio Kanban isn’t about choosing the work you do; it is about choosing the work you don’t do. The conclusion from my #lkna13 session


@hakanforss A kanban system is the MVP of a process control system #klrat


@hemppah Why focusing on the system should be attractive for managers? Because about 85% to 95% of variation in performance is due to the system!


@ojuncu #accit13 #kanban Demand is higher than capacity:we don’t 2 load servers & network beyond 80% capacity, still we do that w/ ppl #LimitWIP


@hemppah « An organization organized around ‘pull’ and flow needs a very different kind of leadership from the traditional C&C. » -John Seddon


@hemppah Flow of work indicates how organization’s parts interact together. Thus, greater economy can be achieved through flow rather than scale.


@djaa_dja « Should we use #scrumban or #kanban? » is an illogical question. Scrumban = Kanban where the starting condition is Scrum. Scrumban is Kanban!



Lu sur les blogs

A lire l’article « Il était un fois un projet IT en Kanban (Episode 1 : Du Story Mapping au Kanban) » de Couthaïer Farfra. Au menu :

Story Mapping
Kanban pour PO
Kanban pour l’équipe de réalisation
Kanban des actions/obstacles

Kanban Digest #24

Le meilleur du #Kanban lu cette semaine sur le Web :

Lu sur Twitter

@hemppah  »The first step in any organization is to draw a flow diagram to show how each component depends on each other. » -W. Edwards Deming


@hemppah  »A flow diagram displays a process. The problem is how to improve it. The PDSA cycle will help. » -W. Edwards Deming


@asplake  »Let the flow manage the processes, and not let management manage the flow » ~ Taiichi Ohno #kanban #values


@ourfounder Stop obsessing over task sizes and pay attention to interruptions to flow. #pkflow #kanban #agile #scrum #gtd


@neil_killick It might not be a good idea to make your #Kanban #Scrum wall too awesome & professional looking because you’ll be reluctant to change it.


@cyetain Estimating is an economic decision. What is the tradeoff between the cost and value of the information you buy?


@hemppah  »If you design a system where the people who do the work have control of the work, the people change. » -John Seddon



Lu sur les blogs

 Et une autre citation tirée d’une présentation de Yuval ici :Non fixed Date work is slack that buffers variability

Annonces

Rappel : conférence Lean Kanban France

APPRENDRE  - VISER LA PERFECTION - ÉLARGIR SA VISION 

Les 3/4 Octobre à Paris, à noter dans votre calendrier !

Appel à orateur jusqu’au 30 Juin : J-15 !

Toutes les informations à lire sur LeanKanban.fr

GetKanban vs Kanbanzine, le challenge !

La semaine dernière, c’était atelier Kanbanzine avec Agile Rennes !

 

 

C’est la 5ème fois que j’anime cet atelier en conférences et formations Kanban (notamment avec mon ami Claude).

 

Nous avons principalement deux Serious Games à notre disposition comme support pédagogique du Kanban. Les deux fonctionnent bien. Je vous propose d’explorer les quelques différences pour les utiliser dans le bon contexte et avec la bonne intention.

 

D’abord une présentation des jeux
GetKanban, la référence
Le pitch
C’est le jeu historique qui se déroule dans un contexte de start up avec une équipe de concepteurs, développeurs et testeurs. L’objectif est de gagner de l’argent en déployant le plus de bonnes fonctionnalités rapidement, pour un site web basé sur un modèle d’abonnement.

 

Les plus
Cet atelier permet d’expérimenter la mécanique du flux tiré dans un contexte IT. Très utile donc et très abouti.
Je le propose depuis des années dans mes formations car il permet de vivre, en accéléré et de manière caricaturale, des comportements que j’ai pu constater lors de mes missions Kanban.

Les moins
Il est en anglais, cela en freine quelques-uns; et il est très orienté IT. Or le Kanban a pour vocation d’être mis en place sur toute la chaîne, de la demande à l’utilisation. Embarquer les commerciaux, le marketing, les managers est important et pas toujours facile avec ce jeu à cause du vocabulaire utilisé.

 

Kanbanzine, l’outsider

 

 

C’est pourquoi ce jeu a été créé, sur la base du précédent, mais en Français et dans un contexte non IT.

 

Le pitch
Vous êtes une équipe de journalistes dont l’objectif est de créer un hebdomadaire faisant le plus d’audience possible.
La difficulté consiste à créer un hebdomadaire équilibré en termes d’articles, mélangeant des reportages, des petites annonces, des actualités et des suppléments. Y arriver permet de gagner un bonus d’audience.
Généralement, les équipes réussissent à peine à sortir l’équivalent d’un flyer la première semaine, avant d’arriver à sortir un hebdo complet, au fur et à mesure de l’avancement du jeu.

 

Les plus
Reposant sur l’actualité, l’animateur peut rebondir sur les faits marquants du moment, ou l’actu locale, pour scénariser l’atelier et embarquer les participants dans le jeu.
Ne pas avoir la barrière du vocabulaire IT, et un contexte qui peut parler à tout le monde, est un vrai plus pour partager cet atelier avec des personnes de profils complètement différents, notamment des Product ou Business Owners.

 

Les moins
Première version du jeu, il est moins abouti que le précédent, défaut de jeunesse qui se comble facilement avec la scénarisation de l’actualité.

 

Les deux jeux se déroulent globalement de la même manière, les indicateurs à suivre sont les mêmes. Dans les deux cas, n’hésitez pas à construire un scénario pour raconter une histoire plus que de dérouler un jeu.

 

Les concepts Kanban différentiant

Les deux jeux remplissent leur rôle quant à l’expérimentation d’un flux tiré et l’utilisation de limites kanban. Alors qu’est-ce qui change ?

GetKanban
Cet atelier permet de démontrer assez visuellement la notion de classes de service et l’intérêt d’un système kanban à plusieurs vitesses. On voit assez nettement se dégager deux à trois niveaux de service (temps de cycle) avec le système mis en place. Le flux et la variabilité sont également très visibles.
En faisant des points réguliers sur les stratégies de priorisation et d’injection utilisées par les équipes, il se dégage des patterns permettant d’introduire plus facilement la théorie des contraintes et celle des files d’attente. C’est idéal dans le cadre d’une formation.
Ce jeu, avec sa cadence liée à celle des abonnements, permet également de souligner les différences entre stratégie et tactique, en essayant de jouer sur les opportunités lorsque le jour de l’abonnement arrive.
Le concept qui ne ressort pas bien avec ce jeu est celui du coût du délai.

 

Kanbanzine
Le coût du délai est, avec Kanbanzine, au coeur du sujet car un hebdomadaire a besoin d’informations fraîches pour capter une meilleure audience. Ainsi, l’audience des actualités de plus d’une semaine sont dépréciées. La priorisation prend donc en compte cette information. La preuve est que je n’ai pas à rappeler sans cesse de valoriser la date d’entrée et de sortie avec Kanbanzine (alors qu’avec GetKanban, c’est une de mes activités principales dans l’animation du jeu…).

 

La seconde notion est celle liée à la construction de l’hebdomadaire avec la bonne répartition d’articles. Le mécanisme Kanban permettant de dé risquer cette répartition est l’allocation de capacité par type de demande.
Si les participants ont plus un profil marketing, il est également possible de faire un pont avec des approches du type modèle de Kano ou d’autres modèles de gestion de risques.

 

Les concepts différentiant, en résumé

 

GetKanban
Kanbanzine




Classes de service
Théorie des contraintes
Théorie des files d’attente




Coût du délai
Allocation de capacité
Modèles de gestion de risques

 

Les stratégies gagnantes qui émergent

Il est intéressant de noter que les deux jeux, reposant sur des concepts différents, naturellement les stratégies gagnantes diffèrent. Cela montre bien que c’est très contextuel et qu’il faut faire attention à toute généralisation abusive.
Sans chercher à dévoiler tous les coups gagnants, voilà les grandes lignes des stratégies gagnantes qui émergent pour chaque jeu.

GetKanban

Théorie des contraintes

 

Par construction du jeu, il y a une contrainte dans le système : l’équipe de Tests (c’est également vrai pour Kanbanzine, mais l’effet est ressenti moins longtemps). Le choix des fonctionnalités à réaliser va s’appuyer sur le meilleur rapport entre le nombre de nouveaux inscrits liés à cette fonction (la valeur) et le coût. Mais pas le coût de toutes les activités, seulement celui de la contrainte, c’est à dire le coût des tests. Un ROI sur le coût de la contrainte, donc.

 

Théorie des files d’attente

 

Mais puisque le développement en flux n’est pas un long fleuve tranquille, il faut pouvoir avoir le choix jusqu’au dernier moment de pouvoir travailler sur des développements légers ou lourds.
Pourquoi les développements ?
Simplement car ils sont juste avant les tests, bloqués. Et donc, selon la capacité du développement (le lancer de dé), il faut, pour ne pas perdre de capacité, avoir assez de gros travaux.
La stratégie est donc d’injecter alternativement des fonctionnalités légères et lourdes pour se créer des options pour plus tard.
Kanbanzine
Diminuer les files d’attente

 

Ce qui est assez marquant dans ce jeu, c’est que, très rapidement, les joueurs travaillent très en dessous des limites Kanban; voire n’utilisent plus du tout la colonne d’entrée « Mission », une fois celle-ci vidée.
Pourquoi ?
Car l’équipe a besoin de fluidité dans le système pour gérer à la fois la fraîcheur des actualités et des exclusivités qui arrivent un peu tardivement.
C’est moins vrai avec GetKanban car le coût du délai est moins présent et que l’on propose une ligne spécifique pour gérer les urgences.

 

Un des apprentissages de ce jeu est qu’un système Kanban nominal travaille en dessous de ses limites (sauf pour la contrainte qui, elle, travaille aux limites).

 

Allocation de capacité

 

Pour avoir plus de chance de pouvoir créer un bon hebdomadaire, il faut faire le lien entre le pourcentage des types d’articles attendus (10% de petites annonces par exemple) et le nombre de cartes que cela représente sur le plateau, quel que soit leur état (pour l’exemple, les 10% représentent 2 petites annonces en court de réalisation). C’est le principe d’allocation de capacité.

 

En résumé

 

GetKanban
Kanbanzine




Alterner petit/gros
ROI sur le coût des tests




Travailler en dessous des limites
Ne pas utiliser la colonne Mission
Allocation de capacité sur le type d’annonces.






Vous avez trouvé d’autres stratégies gagnantes pour ces jeux ? Partagez-les avec nous.

 

Conclusion

Je trouve ces deux jeux utiles pour expliquer le Kanban, complémentaires pour le formateur pour adapter le jeu à son audience et aux concepts principaux qu’il veut mettre en avant.

Kanban Digest #23

Le meilleur du #Kanban lu cette semaine sur le Web :

Lu sur Twitter

@alshalloway the problem w/ focusing on WIP &constraints is that it may have you not realize the root cause is not too much work, but the workflow itself


@jfallet  »Comment j’ai expliqué le fût tiré à mon père » wp.me/p2A3c9-2L ou le #kanban vu de ma cave.


@zenagilist an N/2 WIP constraint where N=# resources is a great way to provoke systemic story swarming and skill generalization #kanban


@hemppah It’s no surpise the people who don’t treat companies as systems have trouble understanding that the work itself should be treated a system.


@streser On of the bigest mistakes in many orgs is: choosing #Kanban cause it’s more simple than #Scrum. It is not!


@rodrigoy In fact, the must important variable that supports #noestimates and economic decision-making framework is the Cost-of-Delay. #flow #Kanban



Lu sur les blogs

A lire sur mon blog, un article sur la notion de vélocité pour une équipe passant de Scrum à Kanban, et le lien avec la notion de débit.

Annonces

Appel à orateur Lean Kanban France

Nous vous annonçons la seconde édition de la conférence Lean Kanban France à Paris, les 3 et 4 Octobre à Paris, pour :

  Amplifier l’apprentissage

amélioration continue selon une approche scientifique et collaborative
gestion du changement incrémentale, respect les rôles et responsabilités
vision, courage et émergence de leaders

Poursuivre la perfection

gouvernance, predictabilité, innovation et gestion des risques
management visuel pour expliciter les process et les flux et diminuer les temps de cycles
contrôle de la variabilité, élimination du surmenage et chasse aux activités sans valeur ajoutée

Voir l’ensemble

évolution du système de management
lean startup pour entreprendre et découvrir son marché
design thinking et lean UX pour résoudre les bons problèmes


Revivez l’édition 2012 avec cette courte vidéo.



Appel à orateur J-24 !


 
Devenez orateur lkfr (Français ou anglais) et partagez votre expérience et vos idées avec un public de managers, leaders, entrepreneurs, responsables produit et de personnes qui transforment leur manière de travailler au quotidien. Une adresse pour cela : http://www.leankanban.fr


Suivez également @LeanKanbanFr pour plus d’informations.



Et réservez vos dates tout de suite !

Quid de la vélocité en Kanban ?

C’est une question récurrente de la part d’équipe passant de Scrum à Kanban.

La vélocité ?

 

La vélocité, pour une équipe Scrum, est un nombre de points réalisés lors d’un sprint. C’est une forme de productivité de l’équipe par tranche de temps (le sprint), généralement quelques semaines, suivie à la granularité des user stories. Une forme de productivité car elle est repose sur un référentiel d’estimations relatives, propre à l’équipe : les story points.

Il faut préciser que la vélocité est utilisée principalement pour piloter le contenu d’une version. A ce niveau de pilotage, nous n’avons pas besoin d’une grande précision. Lorsque l’équipe et sa vélocité est stable, elle peut également servir pour piloter un Sprint, mais cela vient dans un second temps.

On suit donc le nombre de petites fonctionnalités effectivement réalisées au cours d’un sprint, pondéré par leur effort. A l’échelle d’une version, la granularité, plus que l’estimation, est importante.

Imaginez maintenant que les fonctionnalités ont toutes la même granularité. Les différences d’estimation sont alors un paramètre de second ordre pour piloter la version, et de premier ordre certes pour s’engager sur un sprint.

La vélocité, dans ce cas, serait proche du nombre de fonctionnalités réalisées par unité de temps. C’est la définition d’un débit.

Bien sûr, l’hypothèse que toutes les fonctionnalités ont la même granularité est rarement vérifiée. C’est une hypothèse permettant de mieux comprendre le lien entre vélocité et débit. Les deux notions sont très proches si l’on suit des stories, bien que la vélocité soit plus évoluée.

 

Débit et granularité

 

La notion de débit est intéressante à plusieurs points de vue. Elle suit un nombre d’éléments traversant un système, donc utile pour un système kanban dont un des principes est de justement limiter le nombre d’éléments dans le système.

Ensuite, elle simplifie le suivi d’une performance : il est plus facile de compter que d’estimer. Elle repose sur des données objectives et factuelles : le nombre d’éléments. Mais cela a un prix : avoir des éléments, parcourant le système, de même granularité.

Pour une équipe Scrum ne souhaitant pas faire des estimations, mêmes relatives, cela peut être suffisant. Et lorsque les stories ne sont pas de même granularité, il suffit de suivre le débit des différentes granularités : simple, moyen et complexe par exemple.

Il est donc plus question de granularité, lorsque l’on suit un flux, que d’estimations comme lorsque l’on suit la capacité.

 

Passer de la vélocité au débit

 

Pour passer du suivi de la vélocité au débit, il faut compter le nombre de stories plus que les points réalisés sur un Sprint. Ok mais il n’y a plus de Sprint en Kanban… Alors, on fait quoi ?

Kanban et Scrum peuvent très bien cohabiter (lire quelques articles et vidéos ici pour s’en convaincre). Il est tout à fait possible d’avoir des Sprints donc. Cependant, lorsque l’on bascule en mode flux, la question va réellement se poser.

Travailler en flux ne veut pas dire travailler sans filet. Et pour cela, Kanban utilise beaucoup la notion de cadence pour les moments importants ou l’équipe s’engage : planification et livraison.

Le débit est calculé sur la cadence de livraison des éléments finis. Une équipe basculant à Kanban, peut conserver la notion de vélocité, avec une définition basée sur le nombre de stories et la cadence de livraison.

 

Comment représenter la vélocité en Kanban ?

 

Puisque le débit est le pendant de la vélocité en Kanban, on peut suivre les deux de la même manière, à base de burnup pour le quotidien et d’histogramme pour l’historique.

Kanban Digest #22

Le meilleur du #Kanban lu cette semaine sur le Web :

Lu sur Twitter

@yuvalyeret Great tip from Commitment book – another reason to monitor WIP is that high WIP indicates hidden queues/blocks


@cyrillederuel Le #Kanban expliqué à des étudiants http://t.co/X1kqmkBZGp


@djaa_dja #kanban systems replace DBR because the bottleneck is prone to move around rapidly. Throughout accounting has no place to play


@rodrigoy « You wouldn’t use Kanban if senior management consists of impatient revolutionaries » @djaa_dja on @InfoQ #LKNA13


@ddelapava The #TOC philosophy is clear: not everything is worth improving… Focus efforts where they can have the most effect #Kanban


@ourfounder Your process assumptions are assumptions. Build an A3. Test them. Track them. #kanban #leanstartup #agile #lean


@hakanforss We can’t understand a complex system if we can’t see it and see how a small change will actual change will effect it ~ Jeffrey Liker #lean


@djaa_dja @leankitjon goal would be to raise awareness of #kanban as « alternative path to agility »

Flux de valeur ou activité individuelle ?

L’objectif d’un système kanban est de fluidifier le travail sur toute la chaîne de production, c’est à dire de la demande à la livraison.

On parle même plutôt de chaîne de valeur, c’est à dire que nous allons nous intéresser aux différentes activités permettant de transformer une demande en quelque chose de tangible (comme un logiciel)  qui apporte de la valeur à un utilisateur. Ces activités sont typiquement de la conception, du développement, du test pour le développement d’un produit logiciel, mais pas seulement.

Qui plus est, il permet de gérer un flux de demandes de natures différentes, comme c’est le cas avec un logiciel en production avec son lot de support, d’évolutions, de corrections, …

 

Chaîne de valeur vs activités individuelles

 

Une des erreurs sur l’attente du Kanban, que l’on voit en formation ou en accompagnement, est de mélanger la chaîne de valeur et les activités individuelles. Et de penser que cette approche va permettre de gérer sa propre activité.

C’est vrai si l’activité des personnes est focalisée sur un flux de valeur, puisque justement nous pourrons  mettre en place un kanban sur cette chaîne :

Mais si je travaille sur deux flux de valeurs (dont les processus sont complètement différents) alors le kanban ne va pas m’aider directement. L’approche sera de réguler chacun de ces flux séparément par deux systèmes kanban :

Mon travail au final ne va pas forcément être optimisé, voire il se peut même que ma productivité ne soit plus optimum. Ce sera le prix à payer pour que les flux, eux, le soient. Et cela doit être accepté et compris par tous, les individus et le management.

Dans ce contexte, le Kanban personnel permettra de mieux m’organiser quand même malgré tout, mais sans chercher à optimiser de flux.

Donc le Kanban focalise sur les flux de valeur et ne cherche pas à gérer l’activité des personnes directement, si ceux-ci interviennent sur plusieurs flux de valeurs.

Publication de Rupture Douce – Saison 2

Enfin !

Sortie de la deuxième saison du livre Rupture Douce.

En 2 mots
Les Grenouilles Agiles Reviennent … avec un Nouveau Cocktail de Perturbations Positives et comme Noble Ambition : Transcender l’Agilité pour Energiser le Développement du Capital Humain ET la Performance. Vous goûtez ?

50 mains, 24 histoires, 300 Pages …

et une préface de Alistair COCKBURN

Larguez les amarres

Pour cette deuxième saison, Aaprès une première histoire de transition à l’Agilité avec du Kanban dans la première saison, je m’associe cette fois à Jérôme Avoustin, pour décrire une métaphore pour mieux parler ou mieux comprendre l’agilité.

Voilà notre Teaser :

Manu est en plein questionnement. Il y a quelques jours, il a vécu un rendez-vous client un peu douloureux. Il s’est fait renvoyé dans les cordes en tentant d’expliquer à son client les bénéfices qu’il pouvait tirer d’une approche agile.
Face à ce discours, son client lui a exprimé sa vision de l’informatique et de la façon de mener des projets en employant la sempiternelle analogie avec le bâtiment : l’intérêt d’organiser le développement en phases, piloter les ouvriers, l’importance d’une définition très précise du cahier des charges, d’une conception dans les moindres détails, de fondations solides…
C’est à ce moment-là qu’il croise Fred au détour d’une conférence agile, et lui fait part de sa mésaventure. Fred est en revanche très inspiré. Son parcours d’architecte naval et de course au large lui a permis de voir beaucoup de points communs entre la navigation à la voile et la réalisation d’un projet en informatique.
Tous deux essayent alors de pousser cette métaphore le plus loin possible afin de pouvoir parler différemment d’Agilité et d’engager une discussion constructive.

Retrouvez les informations sur la saison 1 de ce livre.