Note de lecture : Scrumban, par Corey Ladas

Note : 8 ; Réflexions sur la transition de Scrum à Kanban, la vraie nature d’un processus agile et les moyens de l’adapter.

J’entends beaucoup de personnes parler du Scrumban, mais bien peu ont lu les essais de Corey Ladas compris dans ce volume, car il ne s’agit pas de ce dont ils pensent. Car avant tout, Scrumban est une compilation d’essais (souvent des reprises de posts de blog) sous la forme d’un livre au format très court, moins de 175 pages, celles-ci étant par elle-même assez courte, du fait de la mise en page. Mais court ne signifie pas sans valeur, car le texte de ce praticien très chevronné de l’agilité nous propose des réflexions très profonde sur le passage de Scrum à Kanban et la vrai nature des processus que nous utilisons !

Il n’y a pas vraiment de chapitres au livre, mais plutôt des espèces de thèmes qui sont au nombre de 7. Le premier d’entre-eux concerne Kanban lui-même. L’auteur y explore les mécanismes fondamentaux : le WIP et le flow, bien sûr, mais aussi la synchronisation et les buffers. On termine avec une réflexion sur la notion d’itération : pourquoi son avènement était inévitable, tout comme maintenant … sa disparition !

Le workflow est le second thème. C’est l’occasion de réfléchir sur la vrai nature d’un processus, en commençant par souligner qu’un workflow n’est pas une planification (les 2 concepts sont orthogonaux). L’auteur va plus loin en étudiant le PSP du SEI par rapport à Kanban et en mettant en relief les … similitudes ! Enfin l’auteur termine cette partie en dénaturant le kanban en le transformant en un processus à un ticket : c’est un cycle en « V » !

Lire la suite

Parlons outils pour Kanban !

Eh oui, malgré que le manifeste nous assène que « les hommes sont plus importants que les outils », cela ne nous empêche pas de faire le plein à une soirée exclusivement consacrée aux outils ! D’ailleurs j’en étais, mais je suis arrivé un peu en retard… Essayons de rattraper celui-ci !

Thomas Declercq, ou comment étendre TFS

Thomas est manager chez AXA, à Lille plus exactement. Ici, on utilise les outils Microsoft, donc TFS pour faire du développement en .NET ; rien que de très logique. Les grands comptes sont rarement sur les dernières versions des outils, on vient donc tout juste de passer de TFS 2010 à TFS 2013. Et l’outil montre ses limites pour suivre des métriques. Alors si l’on a pu fort logiquement commencer avec des exports de données puis du bricolage sous Excel, l’équipe a fini par se lasser de ce travail et a envisagé des outils se branchant sur les API de TFS. On parle ici de 3 outils internes.

Outil #1 : Le Kanban board

Il n’est pas beau, il a été développé entre la poire et le fromage, car l’équipe en avait besoin mais personne ne voulait payer pour … et il est très utilisé ! Ils en avaient besoin, car la solution initiale, c’était des extracts CSV de TFS injectés ensuite dans Excel. Un travail à la longue très fastidieux.

Donc, cette application faisant grand usage d’AngularJS s’adosse directement à TFS sans même posséder son propre modèle de données. Elle montre simplement les données de TFS sous forme Kanban (chaque équipe a son Kanban) et permet de calculer les temps de cycle, d’afficher le CFD, etc…

Un outil beaucoup utilisé par les Scrum Masters et les PO (les PO sont à Paris alors que l’équipe est à Lille).

Outil #2 : Project Report

Oui, malgré que l’on soit en mode agile, le management continue à demander des reports comme au bon vieux temps. Là aussi la motivation est de permettre de générer cela en économisant l’énergie à produire ces rapports, car tout comme dans l’outil précédent, les données sont directement issues de TFS.

Pour l’essentiel il s’agit de données agrégées des projets pour permettre d’avoir un indicateur global du projet en un coup d’oeil. Cet appréciation va même jusqu’à l’aspect budgétaire !

Outil #3 : Quality Report

Comme pour le second outil, il s’agit là d’avoir des vues synthétiques d’information. Mais cette fois ce sont des informations sur le code et les builds ! Cet outil semble moins pertinent avec la dernière mouture de TFS, mais son architecture lui permettrait d’être frontal d’autres outils comme Jira, car il est agnostique par rapport au back-end.

Et par rapport aux boards physiques ?

La position prise dépend des équipes. Pour Thomas, la bonne position consiste à utiliser … le board physique autant que possible. Il permet un niveau d’appréhension et de personnalisation que ne permettent pas aujourd’hui les outils électroniques. La plus grande plus-value de ceux-cis se situe à deux niveaux :

  • La communication entre équipes distantes.
  • La génération automatique d’indicateurs.

Jira Agile, par Basile Le Plessis

Basile est très à l’aise avec Jira Agile, un outil qu’il déploie très régulièrement dans des équipes. A l’origine, cet outil s’appelait Greenhopper. L’outil permet d’accéder à deux types de boards (qui sont en fait des vues vers les tickets Jira) :

  • Un board Scrum
  • Un board Kanban

Ces deux boards ne présentent pas les mêmes fonctions, et c’est en fait le board Scrum qui est le plus riche des deux. Par défaut l’outil proposera un board avec 4 colonnes qui correspondent à autant d’état du workflow Jira. Mais ces colonnes sont évidemment configurables (3 grands types : A faire, en cours, terminé), chaque colonne pouvant d’ailleurs représenter une conjonction d’états ! La flexibilité de cette configuration a un revers : si on se rate, on peut créer des tickets qui ne sont pas visibles sur le board !

Il est également possible d’ajouter des swimlanes, ainsi qu’un ensemble d’ajouts tels que des « filtres rapides » des couleurs associées à des sous-requêtes, etc…

Tout est configurable dans Jira, c’est sa grande force. Mais cela demande une bonne prise en main, car l’ergonomie tourne souvent au cauchemar sur tout ce volet configuration… D’ailleurs si Jira Agile est le successeur de Greenhopper, l’ergonomie semble estimée en retrait par rapport à la première mouture !

En parlant de configuration, il y a quand même quelques contraintes, entre autre sur l’édition de workflow et la réversibilité des migrations (ok, j’en demande beaucoup).

Par contre, l’outil hérite des capacité d’extensibilité de comportements et de modules de Jira. Il est par exemple possible d’associer des comportements aux transitions d’état. Et les modules Jira sont déjà un écosystème très riche !

Agile Bee, par Laurène Vol

Bee, c’est essentiellement un tableau de bord pour les projets menés en Agile, un tableau de bord à même de montrer un portefeuille de projets et d’en donner une vue uniforme. Pourquoi ?

  • Pour le décideur, pour lui donner de la visibilité sur les livraisons en extrapolant le « quand » on livre.
  • Pour l’équipe, lui permettre de suivre les indicateurs opérationnels.

De mon point de vue, il semble s’adresser avant tout aux décideurs.

Maintenant, d’un point de vue pratique, comme cela marche-t-il ? Les données doivent être extraites de Jira ou de TFS, etc… en format CSV, puis intégrées dans Bee. C’est assez rustique. La connexion via des APIs devrait arriver dans une version ultérieure. La bête est hébergée sur Heroku, c’est donc avant tout un outil SAS, même s’il peut être déployé chez les clients (avec les difficultés de mise à jour que l’on connait).

L’outil rappelle un peu le « happy board » d’AXA, avec des indicateurs tels que :

  • Atterrissage du backlog (via des extrapolations calculées sur 3 itérations).
  • Suivi budgétaire on track / off track ; il permet également de déduire le coût moyen des stories. En pratique, ce suivi s’appuie simplement sur le nombre de stories réalisées dans l’itération et le « coût » d’une itération.
  • Les Bugs, dont le ratio de bugs et le suivi des bugs ouverts et fermés.
  • La Productivité (quand je vous disais que cela intéressait avant tout les managers…). Son suivi se base sur le flux et la cadence et son évolution au fil du temps.
  • Feature matrix : une fonctionnalité permettant l’agrégation de stories par MMF.
  • Calcul de la prédictibilité, en se basant sur une vision flux.

Le point réellement fort de cet outil est son ergonomie et la qualité de son rendu visuel. Tout est très bien fait jusque dans les moindres détails.

Kantree

C’est l’invité surprise de ce meetup ! Kantree est un  produit est développé par une petite société, le démarrage de ce projet étant surtout guidé par la passion ! L’outil s’inspire profondément de Trello, l’ergonomie respire de cette inspiration (si je puis dire). La grande différence est que Kantree permet une gestion de boards multi-niveaux : chaque carte peut elle-même devenir un board ! Chaque niveau de board peut par ailleurs avoir son propre workflow.

Au-delà des boards multi-niveaux, l’équipe travaille activement à des fonctions se différenciant de Trello : association d’une date à une tâche, synchronisation avec Github et personnalisation des attributs.

Cette sympathique équipe investit beaucoup sur le développement de cet outil dans le but de développer une activité d’éditeur autour. Cela me laisse dubitatif, car même s’il présente des particularités intéressantes, le marché est déjà bien occupé par des éditeurs avec une forte présence. De plus ce type d’outil est exposé à terme à une « comoditisation » et est destiné à perdre de la valeur. Du moins à mon avis.

Autour d’un verre

L’agenda de la soirée était plutôt riche et chargé, un style auquel le FKUG commence à être coutumier. Il est maintenant temps de tailler dans le saucisson et la canette de bière. J’en profite pour échanger avec Thomas Declercq à propos de la question « tableau physique versus tableau électronique ».

Thomas est un fervent du tableau physique : il permet une vue globale, d’embrasser l’ensemble du projet ou de se focaliser sur un point en particulier. On peut adapter l’affichage contextuellement pour attirer l’attention sur des points particuliers, etc. Le tout avec une souplesse que ne permettent pas les boards électroniques. Mais les boards électroniques sont pratiquement indispensables pour des équipes géographiquement dispersées et permettent la tenue à jour d’indicateurs, chose trop pénible en mode manuel. Des points de vue envers lesquels j’abonde.

Agile Playground #19 : austèrement Kanban !

Je ne sais si ce début d’année est synonyme de démarrage en douceur, mais j’ai tendance à trouver nos premiers meetups doucement fréquentés…
Deux jeux au programme de cette 19ème édition et un ice-breaker !

image

Pendant que la glace fond…

L’ice-breaker, c’est en passe de devenir une tradition à l’Agile Playground ! Aujourd’hui, c’est au pied levé que Franck Beulé nous propose une petit activité pour mieux mémoriser le nom des autres participants. C’est là que je m’aperçois que je connais effectivement trois-quart de l’assemblée. Dois-je m’en inquiéter ou m’en réjouir ? Cela reste à déterminer…

image

Arrive le moment du choix : 2 jeux nous sont proposés :

  • Un « business value game » d’un côté.
  • Un « FeatureBan » de l’autre.

Le choix est plus cornélien qu’il n’y parait. En effet, si je connais le Business Value Game, j’ai du mal à apprécier celui-ci. Mais c’est peut-être que mon animation n’est pas au point. Aussi aimerais-je un de ces jours voir comment d’autres l’animent.

Mais ce ne sera pas pour aujourd’hui. Christophe Keromen nous propose un Featureban, qu’il nous présente comme une version austère des jeux Kanban. La tentation est trop grande pour moi !

image

Expérimenter Kanban avec Featureban

Le jeu que nous propose Christophe est une adaptation de celui de Mike Burrows. On peut trouver toutes informations nécessaires et les liens utiles sur le blog de Christophe.

Le principe est simple, simplifié à l’extrême même: Un Kanban avec 4 états et des pièces à passer à « terminé ». Tout est anonymisé : les étapes et les pièces (de simples pièces de Lego). Des tirages au sort déterminent si la pièce peut avancer (ou se débloquer selon le cas) ou se bloquer. Nous jouerons plusieurs expérimentations et comparerons celles-ci sur la base du nombre de pièces terminées et de l’en-cours. Nous formons deux tables, la première, animée par Christophe génèrera de nouvelles séries de tirages à chaque tour, tandis que la seconde (celle où je vais jouer) réutilisera la même série de tirages à chaque expérimentation. C’est Olivier qui animera cette table.

image

Premier tour

Sur ce premier tour, chacun joue pour soi (nous avons de pièces de couleur différente pour nous différencier), il n’y a pas de limite de WIP.

image

Le résultat obtenu n’est pas à la hauteur de nos espérances :

  • Nous sommes frustrés de ne pouvoir agir sur les autres pièces lorsque des opportunités s’offrent à nous.
  • La « double peine » nous obligeant à faire deux tirages « face » consécutifs biaisent un peu le jeu à mon avis.

Bref, pas beaucoup de pièces finies et un gros en-cours à la fin de ce round !

image

Second tour

Lors de ce tour, nous voulons observer l’impact d’une limite de WIP (limite de 3 dans les 2 étapes d’en-cours). Toutefois, les joueurs continuent à ne traiter que leurs pièces !

image

Résultat pas très convainquant sur ce round : le nombre de pièces terminées reste le même ! Par contre notre en-cours baisse sensiblement. Nous apprenons quelque chose au passage : grâce à la limite de WIP, quand on atteint les limites d’en-cours, un mauvais tirage peut avoir un effet neutre au lieu d’avoir un effet négatif !

Mais nous restons frustrés de ne pouvoir fluidifier le système en jouant n’importe quelle pièce !

image

Troisième tour !

Nous décidons (comme la fois précédente) de ne changer qu’un seul paramètre pour mieux observer l’influence de celui-ci ! Ici, nous ouvrons à tous les joueurs la possibilité de jouer n’importe quelle pièce. Enfin ! Par contre, nous gardons les limites de WIP du tour précédent.

Cette fois le nombre de pièces terminées augmente très sensiblement. Et non seulement nous jouons les pièces des autres, mais nous collaborons beaucoup plus afin de nous aligner sur une stratégie commune ! Bref c’est bien plus fun. Nous avons hacké le jeu qui devait être austère !

image

Notre capacité est plus grande, une fois que nous avons élargi notre capacité d’action. Mais cette foi, c’est notre limite qui nous parait trop basse !

Quatrième tour…

Pour ce dernier round, nous avons augmenté notre limite de WIP de manière très importante (nous l’avons doublé sur les 2 steps). Notre jeu gagne en fluidité, car nous sommes déjà très bien alignés sur la stratégie. Nous augmentons un peu notre réalisé, mais pas autant que nous l’avions imaginé. En effet la neutralisation des mauvais tirages joue moins lorsque nous augmentons notre limite de WIP !

image

Nous arrêtons là, en envisageant toutefois une expérimentation supplémentaire dans laquelle nous abaisserions la limite sur le step 2, afin de saturer plus facilement le premier step (si, si) et d’avantage neutraliser les mauvais tirages. Vous n’avez probablement rien compris à ma dernière phrase ? Vous n’aviez qu’à être avec nous !

Debrief

La première table a effectué de nouveaux tirages à chaque round. Cela a beaucoup handicapé leur capacité à tirer des enseignements de chaque changement. Ainsi nous pensons que conserver les mêmes tirages est un facteur important de ce jeu.

Par contre, ils ont rapidement hacké la règles des mauvais tirages, une liberté que nous ne nous sommes pas accordé. Il aurait été intéressant de tester cela. Peut-être faut-il clarifier la latitude des changements possibles ?

image

En bref, sur le jeu nous avons pensé que :

  • Il n’est pas adapté à ceux qui découvrent complètement Kanban. Il est trop abstrait pour cela. Kanbanzine ou Getkanban feront mieux l’affaire.
  • Les petites expérimentations très courtes qu’il permet sont excellentes pour découvrir et comprendre l’influence de chaque paramètre.
  • Ces mêmes itérations courtes donnent du fun, car une complicité s’établit entre les joueurs !

End of #19

Au playground, une soirée ça se termine par un buffet. On siffle une bière, malgré l’absence récurrente de décapsuleur et on partage nos expériences !

image

J’ai oublié d’évoquer le l’Agile Playcamp à venir. Un agile Playground sur une journée avec la participation exceptionnelle de Luke Hohman. C’est Greg Hutchings qui a rendu cet évènement possible. Cet évènement sera précédé la veille par une formation certifiante aux innovation games, toujours par Luke Hohman !

Focus

Chap 1 : Où l’on parle de flux

Le focus, au niveau de l’entreprise, qu’est-ce que cela signifie ? En premier lieu, de se concentrer sur la chaine de valeur. Et sur le flux, plutôt que l’utilisation des ressources. Le Value Stream Mapping est un des outils permettant de mettre en évidence les possibilités d’amélioration de ce flux.

Le corollaire est de se concentrer sur un petit nombre de features plutôt que sur des gros batches qui mettent du temps à passer dans le rétroviseur. Donc du Focus !

Chap 2 : Se faciliter la vie

Nous avons vu le problème du « trop de choses à faire ». Et le temps pour le faire est limité. Bien entendu, nous avons moins de temps disponible que de choses à faire. Mais en réalité celles qui sont indispensables n’en sont qu’une fraction. On pourrait appeler le reste des « options » ! Nous sommes maitres de nos choix, n’en devenons pas les esclaves.

Chap 3 : Tel un hamster dans sa roue

Les sollicitations nous viennent de toute part ! Elles créent un bruit qui nous empêche de faire ce qui est important. S’isoler de ces perturbations et se concentrer sur une seule chose jusqu’à ce qu’elle soit terminée, il n’y a rien de nouveau là. Quelques techniques peuvent nous aider comme le « zéro inbox » ou le Pomodoro.

Chap 4 : « non, merci »

Nous avons du mal à dire « non ». En tout cas, moi j’ai cette difficulté. Quand, comment et pourquoi dire « non », afin de se focaliser sur ce qui a vraiment de la valeur, c’est le sujet de cette partie. C’est ce que Henrik Kniberg appelle le « value filter ».

Chap 5 : s’échapper de la roue du hamster

Une seule règle : se ménager du mou. Mais du mou qui nous remettre dans une boucle vertueuse … pour enfin sortir du cercle vicieux !

Chap 6 : Ce que nous faisons définit là où nous sommes

Cela signifie (en clair), que pour être maître de notre destin, nous devons nous efforcer de donner la priorité aux tâches nous conduisant à ce que nous voulons faire. C’est un peu un raccourcis, mais c’est un peu l’idée ! Donc travaillons notre répartion de ccharge de travail, non pas en fonction des nécessités du moment (en tout cas pas seulement), mais en fonction de ce que l’on veut qu’elle soit !

Chap 7 : Une histoire (très) personnelle

Où Henrik Kniberg nous parle de son voyage autour du monde avec sa famille. Une approche qui me rapelle en de nombreux points le « solution focus » : plutôt que de lister ce qui nous empêche de le faire, se focaliser sur ce qui est nécessaire pour rendre cela possible. Et planifier ensuite ce qu’il y a à faire ou les expérimentations à mener qui vont valider les hypothèses.

Plus amusant, ce que les enfants ont appris sur la rationalisation de leurs affaires, qu’ils ont ensuite appliqué en rentrant à la maison !
Cet épisode a été largement exposé dans agile@home !

Chap 8 : World WIP Waste

La réutilisation n’est probablement pas du gâchis, car Henrik Kniberg se ressert à tour de bras du matériel de agile@home !

Le gâchis, c’est ce qui nous empêche d’aller vite, donc d’être agile. Dit autrement : on cours moins vite avec des bottes en plomb !

Formons-nous à Kanban avec le FKUG

Zenika accueillait cette nouvelle réunion mensuelle dans le zLocalHost. Une foule très nombreuse s’y était donné rendez-vous pour cet opus dédié à la formation au Kanban et aux techniques associées.

image

Un programme très chargé. Peut-être un peu trop, c’est vraiment tout ce que l’on pourrait reprocher à cette remarquable soirée !

Après le mot d’accueil du Sponsor soirée, Couthaier nous donne quelques nouvelles de l’association. Elle est très active il faut bien le dire. D’ailleurs la soirée suivante aura déjà eu lieu quand vous lirez ces lignes. Mais place à l’action.

Et l’action pour commencer, c’est avec Pascal Poussard et les essentiels de Kanban !

Initiation au Kanban avec Pascal Poussard

C’est toujours un plaisir pour moi d’entendre Pascal. Cette fois encore, il nous gratifie d’une session d’initation au Kanban clair et énergique, se concentrant sur les aspect importants de l’approche. On pourra juste lui reprocher de faire des infidélités au Scrum User Group (dont il est l’un des membres éminents du bureau) pour faire une pige au FKUG !

image

4 objectifs et 2 notions clé

La Kanban, c’est surtout 4 objectifs :

  • La qualité
  • Equilibrer le rapport demande / débit
  • Livrer souvent
  • Réduire la variabilité

Deux notions clé font de Kanban une approche radicalement différente.

  • La chaine de valeur : Ici, elle part de l’aval. C’est la demande qui contrôle la mise à disposition, d’où la fameuse notion de « flux tiré ».
  • Le temps de cycle : On ne parle plus de vélocité ou de capacité. Kanban se focalise sur le délai entre la demande et la mise à disposition au-delà de toute chose. Si cette notion n’est pas importante pour vous, sans doute n’êtes-vous pas un bon candidat au Kanban. Mais réfléchissez bien…

6 principes

Visualiser la chaine de valeur. C’est la première pierre du Kanban. Car visualiser cette chaine de valeur, c’est rendre compte de manière claire de ce qui se passe, créer une adhésion autour de celle-ci et permettre de « casser les silos ».

Limiter le travail encours (WIP limit). Ce principe est à la fois le moteur du flux tiré et de la réduction du temps de cycle.

Gérer le flux. Dans un système, le flux est limité par son goulot d’étranglement (théorie des contraintes). Cette dernière nous dit aussi qu’il y a nécessairement un goulot d’étranglement dans le système, qu’il faut décider (et non subir) où celle-ci se positionne et subordonner le système à cette contrainte.

Rendre les processus explicites. Comme les approches agiles, Kanaban est une école de rigueur : les règles de passages sont clairement définies, ainsi que les procédures exceptionnelles.

Amélioration continue. L’observation et la mesure de ce qui se passe nous permettent de déterminer ce qui peut faire l’objet d’amélioration.

Feedback : Celui-ci vient des mesures et de la voix du client.

Pour quel contexte ?

  • Si notre flux de travail n’est pas équilibré.
  • Si notre chaine de travail est surchargée.

Comment commencer ? Avec ce que l’on a, simplement en rendant notre processus explicite. Puis en enclenchant des cycles d’amélioration.

Retrouvez ici la prestation de Pascal.

Ainsi que le support de sa présentation.

Le management visuel et l’Obeya, par Christophe Keromen

Au commencement

On commence fort avec Christophe en se posant la question suivante : pourquoi faire un management visuel ? Pour nous pousser à l’action ! Si celui-ci n’atteint pas ce but, il faut le jeter !

Pourquoi doit-il être visuel ? La Programmation Neuro-Linguistique nous dit que des 5 sens, le VAKOG de la PNL, c’est le sens visuel qui est dominant, car notre cerveau est efficace pour reconnaitre les motifs.

La question suivante sera donc : qu’en fait-on ? On va s’en servir pour rendre visible les problèmes, et rendre aussi visible le lien entre le problème (que l’on refuse souvent de voir) et l’action.

image

Commençons avec un tableau Scrum…

Celui-ci nous permet de rendre visible la progression. Mais rend-t-il visible le challenge ? Permet-il de voir les « impediments », les boulets qui nous freinent ?

Christophe nous résume ainsi ce que le management visuel rend possible :

  • Voir ensemble
  • Agir ensemble
  • Apprendre ensemble

Pour permettre cela, il faut non seulement faire attention à l’information que l’on montre (et qui conditionnera tout le reste), mais faire en sorte que l’information représentée sur ce tableau soit :

  • Univoque
  • Visible
  • Interactive

Un tableau soigné

Cela commence en soignant ce tableau au niveau du contenu. Ce sont les « 3 U » :

  • Utile (ce qui n’est pas utile constitue une pollution)
  • Utilisable
  • Utilisé (quelle est la dernière chose que vous avez apprise avec le tableau ?)

Cela signifie aussi un tableau soigné du point de vue esthétique. Eh oui je confirme : personne ne va aller voir un tableau moche !

Du manangement visuel à l’Obeya

Que doit montrer d’autre notre management visuel ?

  • Les objectifs (le challenge)
  • Les règles
  • La vision

C’est de tout cela dont on parle quand on évoque l’Obeya. Mais l’Obeya, c’est aussi un espace, l’Obeya Room, à l’agencement très spécifique. Le but ? Se mettre en position de faire du Kaizen !

Retrouvez ici la présentation de Christophe Keromen en vidéo.

Ainsi que les slides de sa présentation.

La résolution de problèmes avec le A3, par Laurene Vol

Le A3, c’était probablement la présentation que j’attendais avec le plus d’impatience. Mais ce fut aussi probablement la présentation la plus faible, hélas. Non pas qu’elle fut mauvaise, mais elle est restée très « by the book ».

Un A3 pour traiter des problèmes

Et ces problèmes, comment sont-ils identifiés ?

  • De manière spontanée, durant l’itération, quand on tombe dessus !
  • En rétrospective
  • Via des indicateurs

Ces problèmes, Laurene nous propose de les collecter au sein d’un tableau, plus précisément dans une matrice de Merill-Covey. Vous connaissez déjà certainement.

image

A partir de là, des règles nous permettront de déterminer la manière dont nous traiterons ces problèmes. Pour certains d’entre-eux, ce sera le A3 !

Du contexte à l’analyse

Le A3 débute avec une partie « contexte ». Elle répond à la question : Pourquoi en est-on là ?

Vient ensuite le « current state » : un état initial quantifié et si possible illustré avec un schéma. Si des contournements sont déjà mis en oeuvre, ils sont exposés.

image

L’objectif, c’est l’état final désiré. Il est lui-même quantifié.

La partie délicate, c’est bien l’analyse. On privilégie l’analyse causale à l’aide de différentes techniques : les 5 pourquoi, les diagrammes de cause-effets ou les diagrammes en arêtes de poissons.

Vous avez trouvé mon compte-rendu trop succinct ? Regardez la vidéo de l’intervention de Laurene.

Son support de présentation est également disponible.

Kaizen & PDCA avec Julien Karoubi

Je dois avouer que Julien affronte des challenges que je n’oserai pas, même dans mes jours les plus téméraires.

Ainsi, pour illustrer le principe de l’amélioration continue, Julien a proposé un jeu !

image

Ce jeu, Julien l’a imaginé spécialement pour cette soirée. Il s’agit d’effectuer des itérations et de consacrer un peu de temps pour trouver des améliorations de fonctionnement, à l’image du Ball Point. Ici, Julien s’évertue également de perturber le système en intervenant au milieu des itérations, histoire de casser de rythme et voir comment l’équipe réagit !

image

Résultat moyennement concluant. On arrive à la même productivité avec ou sans temps consacré à l’amélioration. Mais on doit pendre en compte que du temps de travail est alors consacré aux rétrospectives. Il faut dire que les tranches de temps sont réellement très courtes, surtout pour les rétrospectives. Voyons en video ce que cela donne.

Il était aussi audacieux de la part de Julien de faire ce jeu dans une configuration de soirée « plénière » : Il y avait 80 personnes dans le showroom Zenika, probablement moins de 10 pouvaient voir et suivre réellement ce qui se passait.

Quoi qu’il en soit, cette cassure était bienvenue dans ce marathon de présentations !

Key Performance Indicators pour Kanban, par Yannick Quennec’hdu

Yannick est très, très affuté (et expérimenté) sur les mises en place de Kanban et les mesures associées dans des contextes multi-équipes. On pouvait s’attendre à une présentation de haute qualité, nous l’avons eu !

Parlons pré-requis

Toutes nos présentations s’articulent bien ensemble, car pour Yannick, un pré-requis important est … la mise en place d’un management visuel ! Bon, il n’y a pas que cela. Il faut aussi que notre Kanban soit « stabilisé » également. Nous ne devons pas non plus perdre de vue notre objectif : rendre factuel notre Kanban !

image

Les indicateurs

Ils sont classiques, mais ça ne fait pas de mal de les reprendre :

Le Lead Time : combien de temps entre une « commande » et un client servi.

Le temps de cycle : Le temps séparant deux évènements identiques. C’est donc l’inverse de la fréquence et vice-versa.

Le débit : Le nombre d’items livrés dans un laps de temps donné. Là on ne parle plus d’étape du processus, mais de ce qui sort du Kanban !

Le travail en cours : combien d’éléments sont en élaboration aux différentes étapes du processus !

Le diagramme de flux cumulé est l’outil de prédilection permettant de mesurer et voir évaluer la plupart de ces indicateurs. Ca, c’étaient les bases. Et maintenant, voici…

Le grand Mix

Ces indicateurs se combinent pour voir les corrélations entre ces indicateurs.

La loi de Little : Elle indique que le temps pour terminer est inversement proportionnel à l’en cours. Donc réduire l’en-cours augmente le débit !

La prédictibilité : Un indicateur compliqué, basé sur le débit et la taille des tickets.

L’efficience : Pour mesurer dans notre processus, le temps qui ajoute de la valeur au produit. En pratique, on isole les zones tampon et l’on mesure le temps que le ticket y passe.

La qualité : C’est le coût de la non-qualité qui est mesurée, via des « tâches rework », par exemple. Yannick utilise cela pour mesurer la valeur économique de l’accroissement d’une équipe de tests !

Variabilité : Ces variabilités peuvent être locales ou globales.
Je vous recommande la vidéo de l’intervention très riche de Yannick

Et aussi, bien sûr, le support de sa présentation.

Mesure de la maturité par Nicolas Lochet

La soirée n’est pas encore tout à fait finie ! Nicolas nous expose à la vitesse de la lumière une grille d’audit de maturité Kanban, basée sur les éléments du livre de Laurent Morrisseau.

image

Il n’y a pas de support de présentation, car Nicolas nous présentait directement sa feuille Excel (que je n’ai pas non plus). Hélas, nous n’avons pas également de captation vidéo de cette intervention.

Enfin, un petit « preview » ne fera de mal à personne : voilà !

image

On a soif !

Il est plus que temps d’aller au ravitaillement. Vider le frigo rempli de bières et les petits fours et autres provisions de bouche laissées à disposition, telle était notre dernière tâche !

image

Ce que j’en ai pensé

Ce Meetup était vraiment très riche. La mission était d’initier le plus grand nombre aux éléments de base de Kanban. Les diverses présentations ont réellement rempli ce rôle. En fait l’agenda était même trop ambitieux. Nous aurions eu de la matière pour deux soirées ici.

Second point, bien que mineur : je n’ai pas compris la nécessité de rendre cette soirée payante. D’autant qu’étant hébergée chez Zenika, tous les coûts étaient assurés par l’hôte ! Cela n’a pas freiné les ardeurs (et la contribution demandée était minime) et cela a certinement alimentée la caisse de l’association.

Le FKUG montre une fois de plus son dynamisme, non seulement à organiser une soirée par mois, mais à varier les formules de ces soirées. Un rythme et une variété que j’avais escomptée pour le Scrum User Group il n’y a pas si longtemps que cela, et qui reste à retrouver.

L’association organisait aussi en décembre une soirée jeux, je n’ai malheureusement pas pu y participer. J’attends avec impatience l’année prochaine !

Agile Playground #17 : En interlude…

Nous avons conservé ce mois-ci la formule du mois précédant : un démarrage en mode « place de marché » d’un forum ouvert ! Dans la pratique, nous n’avions pas de jeu « à expérimenter » ce mois-ci. Mais Alexis Nicolas avait amené un Kanbanzine. C’était fort à propos !

image

Finalement, deux « ice breakers » et 2 jeux furent retenus pour cette soirée. Outre le Kanbanzine et l’ice breaker dont j’ai oublié le nom, je me suis donc retrouvé mis à contribution sur un ice breaker que j’avais proposé … et un « remember the speed boat » pour satisfaire une demande de mettre en oeuvre des innovation games !

Cassons la glace des estimations agiles !

Pas tout à fait en estimations agiles, en fait. Il s’agissait plus d’expérimenter une approche d’estimation inspirée du Wide Band Delphi. Une version un peu simplifiée, en fait.

1 – On forme plusieurs groupes

2 – Je propose un sujet à estimer.

3 – Chaque groupe discute entre eux pour déterminer une estimation durant 2 minutes

4 – Les groupes partagent les éléments les ayant conduit à choisir cette valeur.

5 – On fait un nouveau tour de ré-estimation d’une minute.

Est-ce parce que nous avions un parterre d’agilistes « chevronnés » ? Aucun groupe n’a jugé nécessaire de réviser l’estimation au second tour (bien qu’avec quelques hésitations). A tord. La réévaluation les auraient fait converger vers la bonne direction !

Remember the Speed Boat

Mariage forcé entre le « Speed Boat » et le « Remember the future », il s’agit d’une combinaison qui me parait aujourd’hui naturelle. Par contre, cette animation était un peu improvisée et j’avoue ne pas avoir été excellent. Hélas. Le sujet, s’il était fun, n’était pas non plus évident à mener à bien : Organiser une visite privatisée au Taj Mahal, avec nuit sur place … mais à un prix raisonnable !

image

Nous avons pu mener notre projet fictif (plus ou moins) à bien. Nous avons terminé en discutant librement des apports de cette approche. Finalement, notre jeu aura atteint son but, car plusieurs des participants vont s’y essayer.

image

Pendant ce temps, le Kanbanzine

Nous avons terminé un peu plus tôt que le second groupe. C’était donc l’occasion pour moi d’entretenir une petite frustration réccurente : cela fait déjà un certain temsp que j’aimerai tester le Kanabanzine ! Chaque fois je rate l’occasion à pas grand chose ! Mais un jour, j’y arriverais…

image

Le FKUG offre un tour de chauffe à Lean Kanban France !

Beau programme pour cette rentrée du FKUG ! En effet, cette soirée hébergée par Wemanity proposait pas moins de 4 sessions sur 2 tracks. Nous serons donc hélas frustrés de 2 sessions !

image

Un petit mot sur le FKUG tout d’abord :

  • Les choses avancent, avec maintenant un site pour l’association.
  • La taille de la communauté augmente aussi progressivement : elle compte 330 inscrits sur meetup ! La j’en suis sûr, nous étions moins nombreux chez notre hôte…
  • On est rentré et bien rentrés : le prochain meetup se profile déjà pour le mois de novembre…

Assez bavardé, place aux présentations !

Apprendre à apprendre pour le 21ème siècle, par Yannick Grenzinger

Cette session, seul Yannick pouvait nous en gratifier ! Sur la dernière année, Yannick a suivi 30 cours en ligne, les fameux MOOCs, il est en quelque sorte un « boulimique du savoir » !

Cette présentation, que Yannick propose par ailleurs au format Brown Bag Lunch s’articule sur 3 niveaux : l’individu, le produit, l’organisation.

image

Apprendre pour les individus

Ici, Yannick nous propose quelques « hacks » :

  • Déconstruire pour mieux reconstruire : faire des tranches d’une dizaine de minutes. Cette déconstruction est déjà une étape de l’acquisition de la connaissance !
  • Des répétitions fréquentes, mais espacées (!)
  • S’appuyer sur l’utilisation de modèles mentaux et de métaphores. Tiens ? Cela ne vous rappelle-t-il pas XP ?
  • Eliminer les bloquants.
  • Utiliser une boucle de feedback rapide. Nous autres agilistes sommes en terrain connu…

Bien sûr, pour faire bonne mesure, Yannick sait aussi nous proposer quelques bonnes lectures :

L’un des points majeurs est qu’il n’est pas besoin d’avoir une « connaissance parfaite ». Les fameux 80% sont largement suffisants et s’acquièrent comparativement rapidement !

Apprendre sur les produits

Et déjà, sur la construction de produits, quel est l’inverse de l’apprentissage ? Le « cycle en V » bien sûr ! Et bien entendu, notre objectif est bien d’apprendre en permanence. Notre attirail d’agiliste possède ce qu’il faut à ce égard : Rétro, A3, Kaizen, etc…

Apprendre, c’est aussi utiliser le pouvoir de la collaboration et les techniques de co-création.

Enfin, apprendre c’est aussi accepter l’échec et penser à « aller plus vite sur l’échec ». C’est ce que nous enseigne le Lean Startup.

Apprendre en tant qu’organisation

De nouveau la même question : quel est l’inverse de l’apprentissage ? C’est le Taylorisme : un travail codifié devant être exécuté sans reflexion par des executant dont réfléchir n’est pas le rôle !

image

Apprendre au sein d’organisation, c’est d’abord savoir organiser pour la complexité, plutôt que chercher à la maîtriser ou le réduire à tout prix. Le Stoos Network a pour but de faire progresser ce mode de pensée, bien que force soit de constater qu’il peine à prendre de l’ampleur.
Le rôle du management est à repenser dans une organisation apprenante. C’est ce que nous enseigne le Management 3.0, mais aussi les militaires dans le manuel Warfighting !

Ce que j’en ai pensé

Je sors un peu frustré par cette session. De l’aveu même de Yannick, la partie « organisation » nécessite d’être renforcée. Mais c’est surtout sur la partie « individu » que l’on attendait l’orateur, et malheureusement il ne développe pas assez ses « hacks ». Nous aurions aussi aimé une reflexion sur la nature (et l’objectif) différent de l’apprentissage au 21ème siècle, à l’ère de l’information à haute valeur disponible au bout des doigts !
Toutefois, je sors aussi avec quelques pointeurs de lecture (encore). Connaissant Yannick, ils valent sans aucun doute le détour !

Continuous Delivery : A Plug-in for Kanban, par Samuel Retière

Il s’agit en fait d’une présentation qui serait fait à 3 voix au LKF, ici il n’y avait que celle de Samuel. Je ne vais pas paraphraser la présentation de Samuel, car vous pouvez y accéder ici.

Ce que Samuel nous présente ici, ce sont les « patterns de transformation » appliqués à la SGIB et organisé en 3 niveaux. Les thèmes s’articulent beaucoup autour du Kanban Thinking de Karl Scotland : valeur, flux et potentiel

image

Le niveau 1 n’a peut-être l’air de rien, mais on y parle déjà cycle TDD et flux !

Le second niveau correspond déjà à une maturité acquise par bien peu d’équipe. On y trouve pèle mêle une pensée produit épaulée par du Lean Canvas, du BDD, du Flux « end to end », donc avec du devops à la clé !

Au niveau 3, on trouve des choses bien plus rares telles que la maximisation de la valeur « infrastructure as code ».Et le seul élément que j’ignorais de la présentation : le Black Swan Coaching ! Plus curieusement, on y trouve le DDD que j’aurais mis personnellement au niveau 2 au maximum. Peut-être même au niveau 1 !

Le programme inclut un cocktail de cours, de workshops et de katas. Le tout épaulé par 3 coaches qui permettent de couvrir le spectre de compétences évoqué. Impressionnant !

<

Fin

Hélas, il n’était pas possible de tout voir. J’aurais par exemple aimé assister au retour d’expérience sur SAFE chez JC Decaux. Il s’agit d’un buzzword qui monte et il faut que j’en sache plus sur le sujet. Celui-ci au demeurant me semble complexe, trop pour être honnêtement agile et j’y perçois des reminiscences d’Unified Process… Qu’importe, il me faudra bien appréhender correctement ce dont il s’agit.

Agile at Home, par Henrik Kniberg

Changement de décors pour cette nouvelle présentation de Henrik Kniber : comment mettre en oeuvre les pratiques agile et Lean à la maison avec 4 enfants !

Kanban

D’abord le Kanban. Il y en a un peu partut chez les Kniberg ! Un Kanban commun pour les tâches partagées, sur le réfrigérateur pour les enfants ou encore pour préparer un barbequeue entre amis.
La famille Kniberg est partie durant 8 mois pour un « familly trip » autour du monde. Il y a eu un Kanban pour préparer cela aussi. Cela comprenait d’ailleurs une expérimentation du concept, avec un séjour de 4 jours à Londres.

WIP limite

Un problème récurrent avec les enfants : le bordel dans la chambre ! Un problème qui ne s’est pas posé durant leur voyage, car la quantité d’affaires à transporter était limitée. Alors on utilise le même système : on limite le nombre de vêtements à ce que peuvent contenir les tiroirs !
Un système qui s’étend ensuite à la cuisine, pour le lavage de la vaisselle, avec une pincée de « definition of done ».

Burnup chart

Junior a du mal a être dans les clous avec ses devoirs ? Son coach de père lui met au point un burnup chart a suivre lui-même au fur et à mesure qu’il fait ses devoirs.

Autres management visuel

Cartes, « dream gallery », Kaizen boards, Henrik Kniberg n’hésites pas non plus à utiliser tout l’arsenal de management visuel à sa disposition.

Ce que j’en pense

Une vraie mise en oeuvre des principes agiles dans la vie réelle. C’est même assez impressionnant, je dois dire, même si je sais que certains de mes confrères s’essaie au même genre de chose..

Et moi alors ?

Eh bien non. En ce qui me concerne, je préfère laisser mon arsenal d’agiliste hors de la famille…

En Finir avec le Planning meeting ?

Je vous avais laissé sur la remise en cause des estimations. Natrellement, le sujet suivant ce dvait être le planning meeting. Nous allons nous y attaquer aujourd’hui !

Autopsie du planning meeting

Le planning meeting de Scrum, c’est une composante importante de la démarche, du moins dans le Scrum Su (). De là découle tout ce qui sera fait durant le sprint. Aussi intéressons-nous à ce qui le constitue.
Tel que décrit initialement, le planing meeting comporte 2 parties, c’est donc en fait 2 meetings en un seul [1] :

  • Une présentation des fonctionnalités souhaitées pour le prochain sprint
  • Une planification de l’execution de ces fonctionnalités pour la durée du sprint

Les textes ultérieurs ont ajouté un peu de détail, comme la présentation de l’objectif de sprint et la détermination de la capacité de travail [2]

image

Au fait, quelle est la durée de ce meeting ? Ken Schwaber nous parle d’une durée de 8 heures pour un sprint de 30 jours ! Personnellement, un tel marathon dépasse mes forces et de très loin. Heureusement, bien que les créateurs de Scrum clament la même durée de Sprint depuis 20 ans, je ne connais personne planifiant des sprints aussi long. Mais même ramené au pro-rata à 2 semaines, une durée de 4 heures me semble excessive !

Hélas, il n’y a pas que la durée qui ne va pas. Ce serait même plutôt le moindre de nos soucis. Commençons donc notre travail de dépeçage.

A faire pour le prochain Sprint

La première partie du planning meeting est, nous dit-on consacrée à l’exposé de ce qui est attendu pour le prochain sprint [4]. C’est vrai que je préfère comprendre mon sujet avant de m’y attaquer. Je crois pouvoir dire sans trop me tromper qu’il en va de même pour la plupart d’entre-nous. Par contre, il y a autre chose que je me sens incapable de faire : c’est donner une réponse sur la manière d’entreprendre la réalisation une fois l’explication terminée !

J’ai besoin de réfléchir à ce que l’on vient de me dire, de poser des questions, ruminer à nouveau, en discuter, échanger sur les alternatives, etc. Ca ne nécessite pas des semaines et des mois, ni même beaucoup de charge, mais un peu de délai, disons quelques jours. Me trouver bloqué dans une salle pour mener le processus de bout en bout ne me convient pas. C’est pourquoi je préfère séparer les choses en deux.

image

Débarrassé de la discussion fonctionnelle, le planning meeting ne contient plus que le plan d’action du sprint, il est donc deux fois moins long (on passe de 4 heures à 2 heures pour un sprint de 2 semaines, parfois même moins). Et on n’y évoque donc que les sujets auxquels on a été initiés.

Nous reviendrons bientôt sur cette question du plan d’action. J’aimerais pour l’instant évoquer la discussion fonctionnelle que j’ai séparé du planning meeting proprement dit.

Goodbye, Product Owner…

J’ai un peu culpabilisé quand j’ai pour la première fois proposé de séparer la discussion fonctionnelle : j’avais l’impression de faire une suggestion sur la base de mon inaptitude à explorer complètement un sujet en séance ! Très vite, je me suis cependant aperçu que les membres de l’équipe avaient le même inconfort que moi. D’autres discussions avec des confrères et autres relations m’ont appris que cette gêne était bien plus répandue que je ne le pensais, pour ne pas dire généralisée.

C’est donc avec bonheur que je me suis mis à faire des points d’exploration fonctionnelle (parfois plusieurs) quelques jours avant le planning meeting. Avec quand même deux sujets d’insatisfaction :

  • Explorer tous les sujets d’un sprint, c’est quand même du boulot, surtout si on veut le faire correctement.
  • Une fois que nous avons analysé les user stories, on a parfois tendance à ne plus voir le Product Owner durant tout le sprint.

La réponse à ces deux sujets est commune. Mais je voudrais avant tout affiner le second point : Pourquoi parfois ne parle-t-on plus (ou en tout cas moins) au Product Owner durant le sprint ? Après tout, Scrum nous dit bien que l’équipe de développement et le PO doivent collaborer ! A qui est-ce la faute [5] ?

La faute n’en incombe à aucune des parties spécifiquement. Elle incombe plutôt au processus. En balayant tous les sujets en amont, on instille insidieusement l’idée que nous avons vu tout ce que nous avions à savoir sur le sujet et que nous pouvons vivre notre vie chacun de notre côté pour la durée d’une itération !

Ah oui ! Et aussi, incidemment, nous avons transformé notre sprint en un mini cycle en « V » [6] !

Voyons maintenant le sujet sous un autre angle en tentant de réponde au premier point énoncé plus haut.

La promesse d’une conversation

Quand on balaye tous les sujets d’un sprint, ça fait pas mal de boulot, disais-je. Non seulement cela, mais on discute vraiment très en amont de user stories qui seront traitées vers la fin du sprint !
Mais au fait, c’est quoi exactement une user story ?

Si l’on se réfère à ce que disait l’extrême programming où ce concept a été créé, la user story est « la promesse d’une conversation » [7]. C’était facile, c’est le titre de la section !

Et l’idée de cette promesse, c’est de parler de cette user story « juste à temps », pas de traiter un « stock de discussions ». Interagir autour de cette user story juste à temps présente plusieurs avantage, et aussi au moins un inconvénient que nous verrons plus tard :

  • L’exploration de chaque user story devient un travail plus concis. Plus la peine de programmer de grande pleinières !
  • On aborde chaque user story que préalablement à sa réalisation, le sujet reste frais dans notre esprit et les informations ne se sont pas encore estompées.
  • Puisque l’on retarde le moment où l’on explore le sujet, on bénéficie de tout ce que l’on a appris entre temps. Comme les sujets ont tendance à être traités au sein d’un même sprint, il y a une bonne chance pour que cet acquisition d’information nous bénéficie effectivement.

Il y a bel et bien un inconvénient, cependant : Si l’on doit fourbir notre plan d’action lors du planning meeting (vous savez, la moitié du planning meeting que nous avons conservé jusqu’à présent), cette approche ne convient pas, car nous n’aurons pas évoqué les user stories avant d’avoir à en faire le découpage en tâches !

Le choix est cornélien. Rassurez-vous, nous avons un autre problème inhérent au volet « plan d’action » de notre planning meeting !

Le planning meeting, un plan d’action ?

Nous sommes parés concernant la connaissance fonctionnelle de nos user stories. Allons-y, découpons tout ça en tâches pour faire le plan de notre itération [8]. Comme nous sommes agiles, nous saurons aussi nous adapter, bien entendu. Sauf, que l’on se demande bien comment, car nous avons tous coulé dans le béton à l’instant !

En y regardant de plus près, notre problème d’adaptation se situe même à deux niveaux :

  • Pouvoir adapter le contenu du sprint (donc les stories) à l’objectif du sprint. C’est vrai, nous n’avons pas parlé d’objectif de sprint jusqu’à présent. Un peu de patience, ça va venir.
  • Permettre d’explorer et pouvoir décider de la manière dont on conçoit un pan du système pendant que l’on travaille dessus.

Arrêtons-nous un instant sur ce dernier point. Implicitement, le planning meeting induit que nous devons décider tôt, au moins dans les garndes lignes, la conception d’une fonctionnalité à réaliser. C’est ce qui sous-tend le découpage en tâches des fonctionnalités. Or parfois, même cette décision est difficile à arrêter tôt. Parfois encore, nous avons plusieurs options à notre disposition [9], pourquoi devrions-nous opter pour l’une d’entre-elle à un moment où nous n’avons pas suffisamment d’informations à notre disposition pour décider [10] ?

image

Vous l’aurez peut-être compris, en nous obligeant à fixer nos choix tôt, le planning meeting va à l’inverse de ce que le Lean nous enseigne. En fait, il va aussi à l’encontre de la notion de conception émergente inscrite dans les principes agiles !

Ce n’est hélas pas fini, il y a plus grave ! Ce qui est vrai à l’échelle d’une user story l’est aussi à l’échelle supérieure : l’objectif de sprint !

Vers une planification orientée objectifs

La version 2013 du Scrum Guide reconnait l’importance de la notion d’objectif de sprint [11]. Il n’est pas seulement évoqué au sein du planning meeting, il l’est aussi au niveau du stand-up : il est maintenant la boussole qui nous permet des réajustements ! De mon point de vue, il s’agit d’un pas important dans la bonne direction, celle de la finalité du produit construit.

Maintenant, il faut que le reste du framework Scrum soit en harmonie avec cette idée !

Le plan d’action que nous dresserons lors du planning meeting sera en accord avec l’objectif de sprint, n’en doutons pas. Mais qu’advient-il des nouvelles idées qui naissent de la réalisation des premières fonctionnalités ? Que fait-on des nouvelles options qui germent au grée de la réalisation ? C’est vrai, initialement Scrum nous assène que tout changement ne peut être pris en compte que dans le sprint suivant ; au sein du sprint courant, on va en ligne droite et on ne change rien ! Mais justement, focaliser le sprint sur la finalité plus que sur la fonctionnalité, c’est accepter l’adaptation en cours de sprint et remettre en cause la nature irrévocable de ce qui est décidé en planning meeting.

image

Maintenant que nous avons remis en cause le plan d’action du planning meeting, que nous reste-t-il ? Au moins la synchronisation entre le PO et l’équipe, certes, mais quoi d’autre ?

Il n’y a pas qu’une façon de faire notre planning meeting

Comme souvent, la réponse sera : ça dépend ! Cela dépend de la part d’inconnu que recèle intrinsèquement le projet. Par exemple, à quel point le projet est innovant, mais pas seulement.

Si l’on proclame, et je le fais, que la réalisation d’un projet en agile se justifie d’autant plus qu’un projet est innovant, n’oublions tout de même pas que l plus grande part de nos projets informatiques ne le sont que faiblement : il s’agit en très grande partie de logiciels de gestion. Les besoins d’adaptation de ce type de logiciels sont à la marge et surtout au niveau de détails (ergonomie, règles de gestion, etc..) mais rarement au niveau des grandes fonctions. Dresser un plan d’action complet du sprint lors du planning meeting a pleinement du sens dans ce contexte. C’est même confortable.

A l’autre bout du spectre se tiennent les intrépides explorateurs [12] : ils recherchent le nouveau paradigme, veulent créer l’océan bleu d’un marché à créer de toutes pièces [13] ! Construire un plan de sprint devient contre-productif. Ce dont on a besoin là, c’est d’une direction à suivre à court terme, d’hypothèses à vérifier et d’options à explorer. Le planning meeting devrait graviter autour de cela. Le Daily meeting peut alors devenir une réunion de réajustement du planning meeting, où sont éliminées les hypothèses non vérifiées, sélectionnées les options les plus intéressantes, etc..

Les variantes situées entre ces deux extrémités restent à inventer, lorsqu’elles ne l’ont pas déjà été.

Alors le planning meeting, c’est mal ?

Sortir du planning meeting avec les post-it de stories et de tâches, et pouvoir les afficher sur le Scrum Board mural, je dois avouer, j’apprécie cela ! Tout le monde peut voir durant l’itération où l’on en est, rien qu’en observant le volume de post-its déplacés à droite par rapport à ceux restant à gauche. La plupart du temps, le burndown n’est même pas nécessaire. Comme nous l’avons dit plus haut, cela signifie que le sprint est assez linéaire et plutôt sans surprise !

image

Alors oui, dans ce cas le planning meeting, plus ou moins comme prévu dans Scrum a du sens. Doit-on en conclure que cette cérémonie n’a plus de sens quand le niveau d’incertitude augmente ? Certainement pas ! Mais il faut en adapter le format.

Que penser alors du « mode Kanban » qui bascule complètement le fonctionnement de l’équipe en flux tiré, rendant toute forme de planning meeting sans objet [14] ? J’ai tendance à trouver que dans le cas du développement de produits au moins, une certaine forme de planning meeting fait défaut. Si Kanban excelle à établir le SLA d’une équipe de développement, il lui manque quelque chose pour établir le cap, synchroniser l’équipe et le demandeur à intervalle régulier autour du cap pour favoriser la collaboration entre les acteurs autour du produit. Un planning meeting orienté « roadmap produit » au sens que lui donne l’Impact Mapping [15] pourrait jouer ce rôle, par exemple.

Donc oui, j’aime bien le planning meeting, mais un planning meeting « lean » adapté à la typologie du projet et non une vision rigide, voir tayloriste, de celui-ci !

Ressources

[1] : Agile Software Development with Scrum – Ken Schwaber & Mike Beedle – Prentice Hall / series in agile software development 2001 – ISBN: 0-13-067634-9 ; p. 46

[2] : Scrum, le guide pratique de la méthode agile la plus populaire, 2nd édition – Claude Aubry – Dunod 2011 – ISBN : 978-2-10-056320-3 ; p. 94

[3] : Agile Project Management with Scrum – Ken Schwaber – Microsoft Press 2004- ISBN: 0-7356-1993-X ; p. 8

[4] : Essential Scrum, A practical guide to the most popular agile process – Kenneth S. Rubin – Addison Wesley / Signature series 2013 – ISBN : 978 0 13 704329 3 ; p. 338

[5] : Scrum, le guide pratique de la méthode agile la plus populaire, 2nd édition – Claude Aubry – Dunod 2011 – ISBN : 978-2-10-056320-3 ; p. 40

[6] : Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today – Dave West – Forrester 2011 ; p. 9

[7] : Extreme Programming Installed – Ron Jeffries, Ann Anderson & Chet Hendrickson – Addison Wesley / XP series 2001 – ISBN: 0-201-70842-6 ; p. 28

[8] : The Scrum Field Guide, practical advice for your first year – Mitch Lacey – Addison Wesley 2012 : ISBN : 978-0-321-55415-4 ; p. 157

[9] : Commitment – Olav Maassen, Chris Matts & Chris Geary – Hathaway te Brake Publications 2013 – ISBN : 978-90-820569-0-7

[10] : Leading Lean Software Developemnt – Mary Poppendieck & Tom Poppendieck – Addison Wesley / Signature series – ISBN: 978 0 321 62070 5 ; p. 87

[11] : The Scrum Guide – Ken Schwaber & Jeff Sutherland – Scrum.org 2013 ; p.10

[12] : The People’s Scrum, Agile ideas for revolutionary transformation – Tobias Mayer – Dymaxicon 2013 – ISBN : 978 1 937 965150 ;p. 49

[13] : Blue Ocean Strategy: How To Create Uncontested Market Space And Make The Competition Irrelevant – W. Chan Kim & Renée Mauborgne – Havard Business Press 2004 – ASIN : B001E5207M

[14] : Scrumban, Essays on Kanban systems for lean software development – Corey Ladas – Modus Cooperandi Press 2008 – ISBN : 978 0578002149 ; p. 99

[15] : Impact Mapping : Making a big impact with software products and projects – Gojko Adzic – Provoking Thoughts Ltd. 2012 – ISBN : 978-0-9556836-4-0

Jouez en Kanban, re-tentez votre chance !

A mon grand dam, j’ai raté pas moins de 3 rendez-vous du FKUG, j’étais donc heureux de me rendre à celui-ci. D’autant plus heureux qu’il me permettait de m’essayer à l’un des jeux proposé lors d’un meetup précédent. J’avais d’ailleurs arrêté mon choix sur Kanbanzine que je souhaitais comparer au getKanban que je connais bien.

Dans les starting blocks

Nous étions accueillis chez Soat, dans leurs nouveaux locaux du 13ème arrondissement, à deux pas de chez moi ! Beaucoup de place pour s’ébattre, mais nettement moins de participants que prévus : j’imaginais 50 participants sur les 80 inscrits, nous étions un peu moins de 30 au final. Le foot d’un côté et les problèmes de transport de l’autre ont probablement eu raison de la pugnacité des uns et des autres !

On est agile, on s’organise, ou plutôt Gwenael nous aide à nous organiser.

image

Tout d’abord, les jeux proposés pour cette soirée :

  • Le getKanban, nous est proposé par Renaud Chevalier
  • Le Lean Lego Game va être animé par un Yannick Quenec’hdu remonté à bloc.
  • Un Kaizen game, créé par Olivier Le Lan et quelques uns de ses collègues sera orchestré par lui-même.
  • Le Kanbanzine est prévu pour se dérouler sous la houlette de Sebastien Ménétrier
  • Enfin, le Beer Game nous est proposé par Emmanuel Sciara

Pas sûr que nos effectifs nous permettent de mettre en oeuvre tout ce qui est proposé : un rapide vote le confirme. Damnation : c’est justement le Kanbanzine qui est sur la sellette. Je me rabat sur le Beer Game. Mais ce sera sans le regretter !

Le Beer Distribution Game

Ce jeu n’est pas vraiment un truc tout neuf, car il a été créé au MIT dans les années 60 ! Emmanuel, qui va être notre meneur de jeu va utiliser la version commerciale de la System Dynamics Society.

image

Le principe

Le but est d’imiter une chaine de distribution en 4 étapes, allant de la fabrication à la distribution de bières. Chaque maillon de la chaine reçoit des commandes, passe des ordres de rapprovisionnement en fonction du stock (ou du backlog) et des commandes reçues, mais n’a pas de visibilité sur ce qui se passe chez ses voisins. En fait, on n’a même pas le droit de se parler entre nous.

On fait de nombreux tours de jeux, 40 dans notre cas. Et nous voyons nos stock varier et même passer dans le négatif en tentant d’ajuster ces fluctuations à l’aide de volumes d’ordres que nous pensons adaptés.
Le meneur compte les coût de stock (0,50 € par item en stock) ou les demandes en souffrance (1 € par commande non satisfaites).

La dynamique du jeu, surtout vue de l’extérieur, est assez curieuse. Nous ressemblons à des sortes de galériens silencieux qui n’ont pas tellement l’air de s’amuser ! Parfait !

Ce qui se passe

Assez rapidement, on a l’impression de ne plus avoir la situation sous contrôle : les stocks varient et les arrivages ne sont pas du tout en ligne avec la compensation de ces variations, alors on tente de sur-compenser cela par des ordres adaptés. Mais cela semble vain.

image

En fait, nos stratégies sont effectivement vaines. Elles sont même contre-productives : chaque tentative de correction se trouve amplifiée par l’élément suivant de la chaine, accroissant le niveau de chaos des arrivages !

On se sent à la fois aigris et pour le moins dépité par « ce que nous font subir » nos voisins. C’est une sensation vraiment curieuse !

Les enseignements

Si la situation semble se stabiliser vers les tours 30 ou 40, on arrive vite à la conclusion qu’il n’y a pas de corrélation directe et simple entre nos ordres et les arrivages. Les comptes nous montrent même que mes tentatives pour « apaiser » le système ont de manière paradoxale fait de moi le maillon le plus coûteux de la chaine : incroyable !

Cet effet est connu dans les milieux autorisés sous le doux nom de Bullwhip effect.

Les facteurs favorisant cet effet sont :

  • Le manque de communication entre les maillons de la chaine, ce qui ne nous permet pas de donner un bon feedback, d’éclairer nos intentions et favorise l’interprétation erronée.
  • Le manque de vision global sur l’état du système.

On voit donc que ce que nous mettons en avant dans nos principes agiles (transparence, communication) sont une vrai réponse à un problème démontrable plutôt ancien !

Emmanuel a par ailleurs publié un post sur ce jeu.

Lego Game

Pendant que nous nous livrions à nos activités avec une austérité digne des plus grandes heures de l’Union Soviétique, il n’en allait pas de même chez nos camarades Legoistes justes à côté !

C’est un Yannick visiblement sous l’emprise de substances illicites qui animait avec dynamisme un session que je serait bien en peine de décrire, émaillée non seulement de sautillements de l’animateur, mais aussi de grands brassages de Lego…

image

On trie les l’égo, on les renverse par terre, puis bien sûr on les ramasse. Finalement, ce n’est pas si mal comme spectacle pour égayer notre boulot de galérien !

image

Kaisen Game

Olivier Le Lan avait déjà animé ce jeu lors de la journée Open-Space du ScrumDay. Déjà je l’avais raté à ce moment là (mais il s’agissait d’une version 40 minutes, pas vraiment satisfaisante aux dires d’Olivier).

image

Hélas, ce n’est pas encore ce soir que je pourrais l’expérimenter. Il fallait bien faire des choix !

getKanban

C’est un grand classique pour l’apprentissage du Kanban. S’il manque le côté décalé d’un Kanbanzine ou d’un Pizza Kanban, c’est un jeu très complet sur tous les aspects du Kanban dont le fonctionnement a été très bien mis au point. Il mérite un post à lui tout seul.

image

Renaud avait disposé 2 plateaux de jeux « fait maison ». Il est vrai que le jeu officiel est preque hors de prix !

Pizzas time !

Les activités qui étaient planifiées occupaient chacune un peu plus de 90 minutes. C’est donc pratiquement à 22 heures que nous avons pu calmer nos appétits avant de regagner nos pénates.

image

En ce qui me concerne : une soirée réellement instructive, en plus d’être une bonne détente. Un grand merci à Emmanuel pour avoir si brillamment animé ce jeu.