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.

Lire la suite

Publicités

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

Lire la suite

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

Lire la suite

FKUG #3 avec Laurent Morisseau

Laurent n’est pas un inconnu pour nous, car il a fait partie du French SUG avant de s’orienter nettement vers le Kanban, en créant tout d’abord l’association Lean Kanban France qui organise la conférence du même nom et dont il est président, et en écrivant un livre sur le Kanban, le seul en Français à ce jour si l’on excepte la traduction du livre de David J. Anderson.

D’ailleurs la seconde édition de ce livre vient de sortir, elle évoque quelques nouveautés, des avancées dans la communauté Kanban. C’est pour les évoquer que Laurent est venu au FKUG la veille du ScrumDay.

C’est aussi hélas parce que c’était la veille du ScrumDay et que j’avais quelques petites choses à terminer pour l’atelier que j’animais que je n’ai pu venir de nouveau.

Fort heureusement cette soirée a été entièrement filmée (la vidéo est donc très longue) et nous pouvons profiter de cette soirée en différé comme si nous y avions été.

Enjoy !

Un meetup sur les jeux Kanban avec le FKUG

Retenu à Caen par le printemps agile, je n’étais hélas pas là pour ce second meetup du FKUG consacré aux jeux Kanban, et hébergé chez Criteo. Cette vidéo vous donnera un bref apperçu de ce qui s’est passé durant ce meetup. Grand merci à Gwenael Bonhommeau pour son excellent travail !

Mon CR du premier meetup est ici.

Agile Game France 2014 en images (3/4)

Poursuite de notre périple Agile Game France 2014. Les épisodes précédents sont disponibles ici et ici.

Se lever et descendre prendre son petit déjeuner avec la horde des agile gamers, cela vous a des allures de colonies de vacances, croyez-moi !

image

Ice breaking, le retour

On se remet rapidement dans le bain, on regagne notre terrain de jeu.

image

Plutôt qu’une longue description, je vous laisse apprécier (une partie) de l’exercice auquel nous nous sommes livrés ! Désolé, j’ai un peu manqué de réflexe pour en saisir l’intégralité…

Casser la glace, Olivier Soudieux nous a partagé son expérience en la matière photos à l’appuie. Ou comment dégager des centaines de tonnes de glace d’un cargo Turque qui a vogué dans le cercle polaire…

image

getkanban

J’avais eu le plaisir d’en faire une partie lors d’une édition précédente des Valtech Days. C’était avec Laurent Morrisseau. Bien qu’il reste l’une de mes références en la matière, j’ai plus apprécié la partie qui fut dirigé cette fois par Dimitri, probablement parce que faite en milieu moins “stréssé”.

image

Il existe plusieurs jeux kanban, comme Kanbanzine ou le Kanban Pizza Game. Celui-ci est probablement le moins ludique, mais il est très bon pour appréhender tous les aspects de la mécanique Kanban. Il n’est pas facile non plus, car il nécessite que l’on tienne une multitude de comptes et courbes (d’où la nécessité d’être plusieurs).

image

Il faut compter 2 heures pour une partie, bien que je trouve l’aspect “temps contraint” un peu inutile. Par contre jouer à deux équipes, donc deux plateaux ajoute réellement au fun !

Bref, on peut dire que c’est adopté en ce qui me concerne !

En attendant l’heure du déjeuner…

Bien qu’il nous reste encore une demie-journée, on sent l’energie se tarir (on a aussi une semaine de boulot dans les jambes, non ?). Pendant que certains s’acharnent sur des jeux que je n’identifie pas…

image

… de mon côté j’opte pour un “Agile oops !”. Je ne pense pas qu’il ait de vertus pédagogique, mais ça détend bien ! Je ne pense pas qu’il ait de vertus pédagogique, mais ça détend bien. Il s’agit d’une adaptation du “Tabou” où l’on peut mimer, décrire (mais sans utiliser une liste de mots précise) ou dessiner des mots liés à l’agilité … ou à l’anti-agilité.

image

Et le déjeuner enfin

C’est la pause. Ce moment de détente vous est offert par Software Freethinker !

image

Il ne reste que la dernière ligne droite devant nous. En l’attendant, vous pouvez vous nourrir des autres posts produits sur l’évènement.

Les autres billets

Je complète ici la liste des liens vers les différents posts sur cet évènement.

Venez comme vous êtes au FKUG !

“venez comme vous êtes”, c’était le thème de cette première rencontre des affiionados de Kanban ! Au programme : 2 présentations chez “un grand de l’assurance dont le nom commence par A” et “l’acteur majeur des paris hyppiques en France”. Couthaïere Farfra, à l’origine de ce groupe, assurera la première présentation, ainsi qu’une rapide et efficace présentation du groupe, de ses objectifs et de son organisation.

A force de trainer mes guêtres dans diverses réunions agiles, on fini par connaitre du monde. C’est mon cas, et débarquer en connaissant déjà une bonne moitié de l’audience est plutôt agréable, on se sent en famille. Cela a aussi son petit côté jubilatoire quand ceux que vous ne connaissez pas vous voient aborder tout le monde comme s’il s’agissait de vieux amis (c’est d’ailleurs le cas pour certains). On s’amuse comme on peut, n’est-ce pas ?

Kanban à grande échelle chez un grand de l’assurance.

Couthaïer nous fait ici un retour sur la mise en place, les pratiques et les impacts d’une mise en place sur un grand plateau de développement impliquant un grand nombre d’équipes, en mode distribué qui plus est : les product owner étant sur un autre site. Cette transition vers Kanban s’est opéré à partir d’un processus “Scrum”. Je mets des guillemets car à la description, il me semble qu’il s’agissait là d’un Scrum “Canada Dry”, customisé pour les besoins du client comme on dit. Chaque fois que j’entends cela, je sais que je ne dois pas m’attendre au meilleurs…

image

Quoi qu’il en soit, cette mise en place a commencé par un pilote : 2 équipes totalisant 30 personnes (tout compris). L’accompagnement a pris une allure standardisée : 8 semaines à temps plein par coach et par équipe. Chaque coach ne s’occupe que d’une équipe ! Au niveau de a portée du suivi, sont exclus :

  • La partie amont : identification et spécification du besoin
  • La partie aval, dévolue à la partie “devops” !

Les objectifs sont également clairs :

  • La satisfaction du client
  • Améliorer la qualité
  • Tenir les promesses (!)

La mise en place du Kanban reflète le backlog, avec des passages d’état : MMF >> Acceptée >> Critère d’acceptante >> BDD >> INVEST >> Dévelopment >> Tests

A cela se rajoutent bien sûr la mise en place de limites, qui doivent à terme nous permettre de connaitre la véritable capacité de notre système. La maitrise de cette capacité est en bonne partie subordonnée au fait que les stories entrant dans le système sont relativement homogènes en terme de taille. Dans la pratique, elles sont estimées au stade “INVEST”.

Au Kanban lui-même s’ajoute la mise en place de KPI : ici c’est le “cockpit”. Tout cela est bien beau, mais prends beaucoup de place. En fait, le plus gros problème est là : trouver des murs pour afficher ces Kanbans !

Supprimer les gaspillages

Ils sont subordonnés aux obstacles. Et les obstacles, il faut les surmonter. Ils sont de deux types: les petits obstacles et les gros obstacles.

Pour les petits obstacles, on passe par des fiches Kaisen. La revue des obstacles s’effectue lors du stand-up sur le tableau de suivi des obstacles.
Pour les gros obstacles, on passe par des A3 et des Kata.

Réduire les anomalies

Le pair testing est une activité clé ici, dans le cas présente entre un développeur et un testeur. Les anomalies sont considérées comme critiques : on les traitent sans attendre. Au bout du compte, un ratio d’anomalies très réduit, de l’ordre de 0,7 anomalies par User Stories.

La délocalisation : c’est tellement mieux de se compliquer la vie…

Comme je l’ai évoqué, le “avant”, c’était du Scrum pas vraiment “by the book”. En fait, un mixte qui me semble un peu contre nature entre Scrum (au moins le vocable), CMMi et le near shore. C’est une des difficultés de la chose.

La réponse mise en oeuvre est un Kanban miroir sur le site délocalisé, synchronisé au début du stand-up commun aux différents sites. Cet aspect de synchronisation est un des aspects difficiles. Les outils électroniques n’ont pas ce problème mais leur lacune en terme de visualisation limitée pose d’autres questions…

Tenir les promesses

Le CFD (cumulated flow diagram) est l’outil utilisé à priori pour suivre la machine Kanban. Il donne des indications sur :

  • Le débit
  • Les goulots d’étranglement
  • Les en cours

Cela dit, il n’est pas facile à lire… Le CFD montre verticalement le débit, il peut permettre d’extrapoler une date d’atterrissage et montre aussi les perturbations, là où la monotonie de la courbe est rompue. L’axe horizontal montre les temps de cycle, du moins une approximation de ceux-ci. On peut comparer les deux approches, mais c’est un poil compliqué.

Le suivi du Kanban, c’est aual le suivi d’indicateurs issus de son évolution. Ici ils sont mis à jour hebdomadairement. Un point crucial est que la pertinence des informations reste très subordonnée à l’homogénéité des items qui figurent sur ce Kanban !

Pause éclair

Guère beaucoup de temps pour se dégourdir les jambes, on a à peine 5 minutes pour cela. J’aimerais bien échanger avec certaines personnes. Ce sera pour après, peut-être…

image

Renaud Chevalier : La conception d’un Kanban en suivant la méthode Morrisseau

Laurent serait fier de son disciple : Renaud va nous faire suivre la mise en place de son Kanban en suivant sa méthode. Il l’apprécie et elle marche. Démonstration.

Cette mise en place a été effectuée chez “l’acteur national majeur des paris hippiques”. Si vous n’avez pas compris,cherchez encore. Il nous faut remonter à Septembre 2012 pour comprendre l’origine de cette mise en place. A l’époque, le projet fait face à deux inquiétudes majeures :

  • Un problème de “qualité” de backlog, qui ne donne que 2 sprints de visibilité. En tout cas, c’est rangé dans les problèmes par le management.
  • Un risque technologique lié aux choix opérés : Du Java en back-end exposant des services ReST, un front-end en backbone.js et une gestion de contenu accédée en ReST ; c’est du Drupal. Ce n’est pas la mort, mais bon on est chez … af ! C’est vrai… on ne peut pas le dire !

La dessus, la vision macro de ce qui reste à réaliser annonce 1 an de retard ! Branle-bas de combat ! Audit !!

image

Les propositions issues de l’audit proposent entre autre la mise en place d’un grand Kanban transverse, voilà qui est intéressant ! En plus, ça ne parait pas si difficile, un Kanban. Il est rapidement mis sur pied.

Hélas, trois fois hélas : au bout de 2 semaines seulement, ce Kanban ne vit plus ! Que s’est-il passé ? Renaud décide de reprendre les choses à la base, donc de suivre la démarche de Laurent Morrisseau.

image

La portée et les objectifs

Justement, on met directement le doigt là où ça a pêché : une portée trop importante de ce Kanban initial ! La portée du Kanban doit être celle où l’équipe est propriétaire du processus. Ce n’était pas le cas du Kanban précédent, remontant trop en amont (dans l’élaboration du besoin) et en aval (dans la partie production / exploitation).

De plus, inutile également de produire un Kanban correspondant à un processus cible. Il faut commencer là où l’on est, avec le processus courant.

Pour matérialiser les objectifs, il faut identifier ceux-ci ainsi que les insatisfactions actuelles. Cela s’est fait sous forme d’interviews.

La nature de la demande

Pour la connaitre, il faut identifier ce qui arrive à l’équipe, ce qui l’alimente. Dans le cas présent, on a :

  • Les anomalies en provenance de la QA
  • Les demandes du marketing
  • Les “stories techniques”
  • La dette technique

La question subsidiaire est celle de la taille de ces demandes. Comme on l’a vu précédemment, la qualité du Kanban est subordonné à l’homogéneité des items. Ici, Renaud va utiliser les tailles T-Shirt pour évaluer ces items (S, M, L, XL).

Enfin, pour se faire une idée de la situation actuelle, on procède à 3 analyses:

  • Débit par Sprint et par type de demandes
  • Débit par sprint et par taille T-Shirt
  • Débit par catégorie d’anomalies

Le flux de travail et carte Kanban

Au départ, il faut identifier le workflow spécifique à chaque type de demande. En l’occurrence, chacune des 4 catégories a son propre cycle, seules les demandes marketing rentrant dans les sprints !

4 catégories de demandes, cela veut dire 4 cartes Kanban. Elles diffèrent légèrement en contenu en fonction de leur type, mais les éléments de même nature se retrouvent au même endroit : la rigueur d’organisation est un facteur clé d’efficacité. On affectera aussi une couleur spécifique à chaque type de demande. Nous verrons que cela s’avère très important au niveau du tableau.

Le tableau

Justement, le tableau nous y sommes ! Et l’on commence par déterminer les règles de priorités des demandes, quel que soit leur type. C’est intéressant, car on a coutume de subordonner la priorité au type. Or ici on va utiliser l’évaluation du “cout du délais”. C’est une bonne façon d’éviter de se faire hacker le système en transformant une demande en anomalie, par exemple !

Donc, sur ce tableau, on commence par alimenter le système par type de demande, et le premier triage consiste à réalimenter la suite du tableau par classe de service en utilisant ce facteur de cout du délais. Comme chaque classe de service peut théoriquement contenir n’importe quel type de demande, il est opportun de pouvoir facilement distinguer facilement ces différents types : d’où les couleurs !

Règles, règles…

C’est là que l’on rentre dans le volet pas très “agile mind set” du Kanban. Cela couvre 3 volets :

  • Les règles aux interfaces : Quelle règle pour réalimenter le système ? Quel règle pour déclencher la sortie des items ? C’est aussi (surtout) une question diplomatique avec les équipes avec lesquelles on collabore…
  • Les règles internes. Elles sont de plusieurs types. La principale est la “definition of done” qui permet à une carte de passer à l’étape suivante. Les autres règles traitent des exceptions (escalade, changement de priorité, annulation, etc.)
  • Enfin, la grande question : qui s’occupe du respect des règles. La réponse est : le process manager ! Oui, vous avez bien lu, on a un process manager, comme il y a 20 ans !

La capacité du système

Le système en place, il s’agit maintenant de le monitorer et le “tuner”. Au départ, il faut fixer des limites hautes et basses, de manière plus ou moins empirique au départ. Un point particulier concerne la gestion de la dette technique : on en garde toujours une en cours. C’est un tâche de faible prioité qui peut être interrompue pour répondre à une classe de service de niveau le plus élevé.

Le juste à temps et la cadence

Travailler en mode Kanaban ne signifie pas abandonner complètement les rituels réguliers. En fait chaque rituel a sa propre cadence, et ce n’est pas calé de manière global sur une fin d’itération. En fonction du type de cérémonie, on trouvera des rythmes :

  • Journaliers
  • Hebdomadaires
  • Pluri-hebdomadaires

</FKUG #1>

Si j’ai trouvé la seconde session particulière instructive et bien présentée, je dois dire que globalement le contenu de ce premier rendez-vous valait largement le coup. En fait, il était même mieux que ce à quoi je m’attendais !

Expérience réussie, donc. J’ai hâte d’être au second rendez-vous !

Carnet de route : Agile Tour Rennes en Images (2/2)

Nous nous sommes quitté lors du premier post à l’heure du déjeuner. En fait cette heure du déjeuner était réservée aux lightning talks, chacun sur son créneau horaire afin de permettre de les voir tous au besoin !
Hélas cette méthode n’est pas très efficace. Seuls les derniers lightning talks rencontreront un public. Pas facile de gérer cela. Seul l’Agile Tour Nantes m’a convaincu sur ce point l’an dernier. Mais les organisateurs de l’Agile Tour Rennes restent très loin du fiasco du Scrum Day !
On en termine donc rapidement avec la pause déjeuner pour voir cela.

AT Rennes 2013 : Lunch (8)

Prélude au second mouvement : Le Podojo par Emilie Esposito et Damien Sainte

Un Ligtning Talk, c’est déjà court. J’arrive pourtant à en rater la moitié. C’est quoi le PO Dojo ? Un atelier construit collaborativement pour les PO et un groupe Google pour le faire vivre ! Ce qui semble remarquable, c’est l’aspect complètement communautaire, sans PO donc. Sans roadmap non plus, avec un catalogue d’ateliers qui évolue au fil des besoins et des idées.

AT Rennes 2013 : PO Dojo (1)

Alors que le concept de PO promeut que quelqu’un tienne la barre, ces PO ont su s’affranchir de l’idée d’avoir un chef (quelque soit la forme qu’on lui donne), une roadmap prévue à l’avance et tout et tout. Chapeau à eux !

Avant de me rendre à la session de Laurent Morisseau, je passe rapidement la tête dans la salle où officie Dov…

AT Rennes 2013 : Dov

Reprise : #OMG, mon équipe fait son haka en Kanban style ! Par Laurent Morisseau

Un petit challenge pour notre ami Laurent en ce début d’après-midi : faire bouger le public à l’heure de la digestion…

Et d’abord, c’est quoi Kanban dans un projet agile ? De l’amélioration continue + de la gestion de projets !

Commençons avec Scrum

Quand l’on part de Scrum, le point de départ, c’est le tableau des tâches : à faire, en cours, fait… MAIS on met un nom sur une tâche ! C’est un antipattern. Le stand-up devient un reporting !

AT Rennes 2013 : Scrum et Kanban (2)

Améliorer les choses

  • En utilisant les “classes de service”, pour traiter les bugs urgent, par exemple
  • En régulant le flux des stories et des tâches en cours en utilisant des limites de WIP (work in progress) à chaque niveau.

Bref, l’idée est de rendre les problèmes visibles dès qu’ils sont évoqués et de poser des limites hautes et basses.

Quand le PO est dépassé…

Que dire d’un backlog de 70 user stories pour 7 développeurs ?
C’est bien trop, ou bien trop détaillé ! Scrum en tant que process met la contrainte sur l’équipe de développement. En amont, le PO doit travailler en flux, donc sans faire trop de stock.
On peut remédier à cela en matérialisant ce flux tiré et en étendant le Kanban aux activités amont et un matérialisant les états des stories.
Vous pourrez en savoir plus sur le site de Laurent, où vous trouverez non seulement une video mais le matériel de cette présentation sous forme de podcast.

Entracte : Zenika à l’Agile Tour Rennes

Je vous l’ai dit, nous étions présent en force à cet Agile Tour Rennes, pour représenter Zenika. Non seulement depuis l’agence de Rennes, mais aussi de Paris et de Nantes ! Cela valait bien une petite photo de famille.

AT Rennes 2013 : Staf Zenika (4)

Pour une fois, ce n’est pas moi qui prend la photo, cela me donne l’occasion d’y avoir l’air d’un niais. Et tant que j’y suis, j’en profite pour remercier Allison qui s’est dépensée sans compter pour préparer notre présence ici.

AT Rennes 2013 : Allison (2)

Les session s’enchainent. Il est l’heure de celle de Géry

Interlude : Carpaccio Game avec Géry Derbier

Géry nous propose un grand classique : Le carpaccio game. Mais qu’il anime avec grand talent et tout autant d’énergie.

AT Rennes 2013 : Carpaccio Game (2)

C’est très studieux, car il s’agit de programmer le sujet proposé par tranches de 8 minutes et d’apporter de la valeur à chaque itération. Un exercice auquel je me suis d’ailleurs livré il y a peu.

AT Rennes 2013 : Carpaccio Game (3)

Acte 2 : Booster Scrum avec le Lean Startup par Olivier Lafontan

Là encore j’ai bel et bien raté une partie de la session, mais j’étais très curieux de la voir, car elle a eu une belle affluence au Scrum Day en Avril dernier.

Lean Startup nous apprends à mettre l’investissement là où il y a de la valeur. Scrum tend à se “débarrasser” de ces questions sur le PO qui se tape un peu tout sur cet aspect. Et celui-ci se trouve un peu démuni face à ce genre de problème avec pour seul appui le backlog… Lean startup apporte quelques outils :

  • Le Lean Canvas
  • Le Validation Board
AT Rennes 2013 : Olivier Lafontan (1)

La charnière entre Lean Startup et Scrum se trouve au niveau de ces outils. La priorisation du travail devient une priorisation des hypothèses à vérifier. Car Lean Startup ne parle pas de besoin … mais d’hypothèses. Tant que ces “besoins” n’ont pas été vérifiés ils sont en effet hypothétiques. Le cycle Scrum devient un cycle de validation des hypothèses.
A plus grande échelle, un gestion de portefeuille se traduit en portefeuille de Canvas.

Conclusion : Christophe Keromen

C’était ma dernière session de l’après-midi (même si en fait il y en avait une après).

Christophe nous offre une session rafraichissante pour nous ressourcer aux origines de l’agilité. Il remonte au manifeste agile et à l’invitation d’Alistair Cockburn. Non, en fait il remonte plus loin : à Henry Ford, Richard Denning et Taïcho Ohno…

AT Rennes 2013 : Christophe Keromen (1)

Je ne vais pas essayer de reconter la session de Christophe qui mérite plutôt d’être vue. Toutefois, je ne résiste pas au plaisir de dévoiler le Lean version Dan Brown : “Le Lean est un projet Franc-Maçon pour dominer le monde” ! Un grand moment…
Pour finir, Christophe nous propose un nouveau gourou agile : Bob l’éponge … pour absorber les pratiques qui marchent !

Tombée de rideau : A l’année prochaine !

Cet Agile Day était un peu marathonien, force est de l’avouer. Sur la durée, je dirais qu’il y avait une session de trop. Mais ce fut une excellente journée, aussi bien du point de vue de la qualité des sessions que de celle des échanges. Figurez-vous que j’y ai même rencontré l’un des fidèles lecteurs de mon blog (du coup, je le salue !).

AT Rennes 2013 : A l'accueil (1)

Il est temps de se quitter et de se donner rendez-vous à l’année prochaine. A moins qu’un coach retreat, entre-temps…

#OMG ! Mon équipe fait son haka en kanban style ! | Soat blog

Je n’ai pas pu assister à la présentation de Laurent Morisseau qui se déroulait de plus dans une salle non filmée !

Cet excellent post résume très bien cette session dans laquelle on retrouvera quelques anti-patterns qui font écho à mes posts et à ma présentation “en finir avec …

#OMG ! Mon équipe fait son haka en kanban style ! | Soat blog