Étiquette : kanban

Retours sur l’agile tour Bruxelles 2012

Le par addinquydans Compte-renduLaisser un commentaire

Je m’étais fixé dans mes objectifs sur ce second semestre, de me joindre à la communauté agile Belge à l’occasion de l’agile tour Bruxelles. je n’ai pas hésité longtemps à répondre à l’appel à orateurs de Bruno Sbille. Plusieurs raisons à cela:

  • L’opportunité de faire une présentation en Anglais. Il faut bien garder la forme !
  • L’occasion de rendre la politesse à Bruno qui nous avait fait le plaisir de venir faire une présentation dur la Programmation Neuro Linguistique lors d’une soirée du Scrum User Group.

J’espérais donc bien être retenu. Je l’ai été : merci au comité d’organisation !

L’aller-retour dans la journée, ça fait une grosse journée, mais ça valait le coup.

Pascal Van Cauwenberghe : 11 steps to perfect code

Pascal s’est présenté comme un “recovery bug writter”. Il nous a présenté son processus destiné à éliminer les bugs. Il compte 11 étapes, pas moins.

La qualité dépend-t-elle des testeurs ? La réponse est non. En fait, elle est souvent inversement proportionnel au nombre de testeurs. Cela peut paraitre provocateur, voir choquant. mais réflechissez à l’impact psychologique sur les développeurs d’‘une très importante équipe de testeurs.

1 – Mettre en évidence le bug. Jusqu’ici tout va bien.

2 – Votre réaction : et meeeerde ! Non, justement. Il faut remercier le rapporteur. Pascal nous fera faire l’exercice plusieurs fois durant cette heure: remercier à haute voix: Thank you !

3 – Reproduire le problème. Identifier les conditions sous lesquelles ce bug se manifeste est une simple question de bon sens.

4 – Ajouter (au moins) un test qui échouera suivant ces conditions.

5 – Corriger le problème. Vous suivez toujours ?

Bon ça y est, on a fini. Comment ça “non” ?

6 – Rejouer la totalité des tests unitaires. La correction d’un bug peut introduire une régression. Nous le savons tous. Mais prenons-nous tous la peine de rejouer la totalité des tests ? Bien sûr le but n’est simplement de les rejouer, mais de les rejouer jusqu’à ce qu’ils passent tous !

7 – Faire une analyse causale : pourquoi ce bug n’a pas été intercepté précédemment ? Il faut toujours faire attention aux objectifs que l’on fixe : on risque de les atteindre. Si le but est la couverture du code, est-on certain qu’elle est synonyme de tests associés ? Le véritable objectif n’est pas la couverture du code, mais la qualité de celui-ci.

8 – Améliorer les tests.

Là, ça devrait être terminé. Non, toujours pas ?

9 – Améliorer la façon dont les tests sont écrits. Mais ceci est autre chose, n’est-ce pas plutôt un point qui devrait être remonté en rétrospective ? La rétrospective ce n’est pas pour la fin de sprint. La démo ce devrait être tout le temps.

10 – “Un bug ne voyage jamais seul” : à la recherche des bugs similaires !

11 – Faites que ce bug soit impossible à reproduire !

Traquer les bugs ainsi peut sembler coûteux. En fait, ça l’est au début. Pascal s’appuie sur la théorie des contraintes pour expliquer que cette approche permet finalement de livrer plus vite ! En l’occurrence sur un projet, au bout de 5 mois au lieu de 8 !

Jan De Baere : Kaban at different levels

Jan a choisi de nous présenter Kanban tel qu’il est utilisé réellement dans les projets auxquels il a participé, avec les leçons qui ont accompagné sa mise en oeuvre.

La règle de conduite que nous propose Jan repose sur 3 axes:

  • Visualiser le workflow.
  • Limiter le “work in progress”, en s’appuyant sur l’expérimentation.
  • Mesurer et gérer le workflow.

L’exemple d’une circulation sur une autoroute illustre assez bien ces 3 points, même si les paramètres conduisant à la formation des bouchons sortent des fondements théoriques de Kanban (eh oui, il n’y a pas que la théorie des contraintes…).

Cette session avait pour but de nous exposer cette mise en oeuvre dans différents contextes:

  • Un projet classique.
  • Un projet distribué
  • Le Kanban au niveau individuel
  • la gestion d’un portefeuille de projets.

Plutôt que d’asséner les différents éléments de la présentation je préfère mettre en avant les éléments principaux:

  • Les “expedites”: lorsqu’ils sont trop nombreux, il ya un problème à régler !
  • Mettre en évidence les éléments qui sont attendus. Là encore, ils peuvent stigmatiser des problèmes à régler au niveau organisationnel.
  • Les “buffers”: ils peuvent apparaitre utiles dans le workflow, mais sont à utiliser avec parcimonie. Ce sont des sources de gâchis, au sens Lean.
  • Il y a un lien direct entre le “work in progress” et le “lead time”. Ils croissent de concert.

L’un des grands moments fut certainement la présentation du “kanban portable” (et pliable) réalisé par Jan !

atbru2012-JanDeBaere

Pour ma part, je garderais dans mes notes l’usage du “personnal kanban” avec ses limites de WIP adaptatives:

  • Les tâches “high energy” : la limite de WIP est de … 1 ! Ce sont les tâches qui demandent un haut niveau de concentration.
  • Les tâches “medium”, c’est le travail ordinaire. La limite de WIP est de 2.
  • Les autres tâches, celles qui ne nous donnent pas vraiment de faire un travail correspondant à notre niveau de qualification. Il n’y a pas de limites de WIP pour celles-ci.

Ce peut être du bon sens, mais c’est sans aucun doute un point à garder !

Alan Holtz : Lessons learned from the Scrum Master

J’espère qu’Alan me pardeonnera de ne pas avoir pris de note lors de sa session. J’étais en fait en train de faire l’ultime préparation de la mienne ! Si une photo vaux mieux que de grands discours, en voici donc une !

atbru2012-SMLessonsLearned

Yves Hanoulles : How 146 people made 13 projects

Yves a acquis une grande notoriété dans la communauté agile, par son implication dans de nombreux projets. J’avoue que j’avais du mal à comprendre comment il pouvait mener à bien cette activité débordante. Cette session répond à ces questions.

atbru2012-YvesHanoulles

Comment nait un projet ?

Yves débute simplement un projet par un problème qu’il rencontre et sur lequel il ne trouve pas sur le net de ressources pouvant l’aider.

Comment construire une communauté de contributeur ?

Simplement en demandant autour de lui, mais en s’adressant de manière directe aux intéressés, s’ils peuvent et souhaitent l’aider sur son projet. C’est une question franche et directe qui n’appelle pas obligatoirement de réponse positive : on peut ne pas avoir le temps, ne pas être intéressé par ce projet, etc… Yves accueille de manière factuelle et simple cette réponse.

A partir de là, Yves accorde une complète confiance aux collaborateurs dès le départ, avec complet accès en lecture et écriture aux ressources du projet : la confiance n’est devrait pas être “gagnée”, mais donnée !

Surtout Yves nous rappelle qu’il faut toujours penser à remercier une personne qui se propose de contribuer.

Collaboration et outillage

Tous ces projets se déroulent sans aucune rencontre face à face : tout est mené et coordonné à distance, l’outillage permettant cela est donc important. Les principaux que j’ai noté :

  • Skype
  • email: Oui, bien qu’Yves soit un fervent défenseur de la limitation de l’usage de l’email en entreprise, il reste un média essentiel pour ces projets collaboratifs.
  • Google doc.

Si les projets agiles défendent la co-location, Yves nous rappelle que selon Jim McCarthy, celle-ci n’est pas une nécessité : ce qui est nécessaire, c’est une communication avec une large bande passante.

Who is agile ?

Yves a terminé sa session sur quelques reflexions sur la rédaction d’un livre en mode agile, tel que “who is agile ?” a été rédigé.

  • La rédaction d’un livre en mode agile est possible, intégrant des itérations et du feedback. C’est non seulement possible et même souhaitable. Une plateforme comme Leanpub est un grand facilitateur en ce sens.
  • La lecture d’un livre réalisé en mode agile est pr contre moins sympathique.

Jeff Cumps : How to solve your thoughthests impediments

Jeff nous invitait à une session-atelier sur le A3 problem solving. Un réel challenge d’ailleurs car il ne disposait que d’une heure pour nous exposer les principes et nous permettre de les mettre en oeuvre sur une problématique de notre choix.

Je ne vais pas détailler l’atelier ici. Le timing était un peu serré, mais nous avons pu avoir la satisfaction de bien avancer sur nos exemples. Disons que 1h30 aurait probablement été un créneau plus confortable. Mais peut-être pas plus, non plus !

En fait le point positif du temps limité était d’aller droit à l’essentiel sur l’exercice pour en comprendre les points principaux. Ce que Jeff a fait avec clarté. Une très bonne session pour conclure cette journée !

Ambiance, boissons et rencontres

Chaque conférence agile est l’occasion de croiser ou recroiser des passionnés. L’évènement a été ciblé petit par les organisateurs : 70 personnes, donc volontairement peu de buzz autour de ce premier Agile Tour Bruxelles. Un grand “up” pour les organisateurs à propos de la convivialité et de l’ambiance sur cet Agile Tour Belge. Ca donne vraiment l’envie d’y revenir.

Couleur locale oblige, nous avons conclu la journée autour d’une bière.

Un geste sympathique pour les orateurs : un assortiment très couleur locale une fois encore. Que je vous laisse découvrir.

atbru2012-orateursgifts
Publicité

Note de lecture : Kanban pour l’IT, par Laurent Morisseau

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Pas là pour rigoler !

Le livre de Laurent Morisseau, référence en France sur Kanban était grandement attendu. Notre attente n’a pas été vaine, car nous avons hérité d’un ouvrage fort complet sur la question. Mais revenons d’abord au livre en lui-même.

Celui-ci est plus court que ce à quoi je m’étais attendu : 215 pages. Qui plus est, Laurent a fait le choix de le découper en de nombreux chapitres : pas moins de 20 ! Je ne peux qu’approuver cette approche, qui aide grandement à rythmer la lecture. Mais j’ai aussi eu la surprise de constater qu’il résiste bien plus à la lecture que ce à quoi je m’attendais. Je reviendrais sur ce point un peu plus tard.

La première partie du livre sert à camper le décor. Au début de chaque partie, Laurent fait un zoom sur la mind-map qui lui a servi à structurer ce livre. C’est original et intéressant, mais bien que pratiquant régulier de la chose je ne m’y attarde pas, préférant lire le texte linéairement et découvrir les choses au fur et à mesure.

Les 3 chapitres de cette première partie sont une introduction en douceur, ce que je considère toujours comme une bonne chose. On y définit les termes, les concepts, ainsi que la place de Kanban au sein des différentes méthodes (Kanban n’étant pas une méthode). Le 3ème chapitre est une introduction directe au reste de l’ouvrage car il introduit le cycle « PDSA », les 5 pratiques et les 3 piliers fondamentaux qui forment la charpente de la présentation de Kanban par l’auteur.

La seconde partie débute par une présentation générale de Kanban, qui est un peu à cheval avec l’objectif de la première partie et une présentation de l’étude de cas qui servira de fil rouge à l’étude de Kanban tout au long du livre. Le principe de l’étude de cas est généralement excellent, et c’est le cas ici : il donne un aspect concret au descriptif et sert de liant entre les chapitres. Pour une raison que j’ai du mal à expliquer, j’ai eu du mal à rentrer dans cette étude de cas et j’ai dû faire pas mal d’effort pour me rappeler du point où l’on s’était arrêté précédemment. Il est temps d’aborder le cycle PDSA qui couvre les chapitres 5 à 19, donc la quasi-totalité du texte !

Concevoir. A elle seule, cette partie courre du chapitre 5 au chapitre 9 ! Cela débute par la découverte de l’élément de travail qui figurera dans le Kanban, quelles sont sa nature et sa granularité. Cela nous guidera vers la découverte du flux de travail. Cela fait, il faut établir les règles du système, celles s’appliquant aux interfaces d’entrée/sortie (sous quelles condition un élément peut-il transiter) et celles inhérentes au système (changement de priorité, escalade, purge, etc…). On souffle un peu au chapitre 7 (tout en apprenant des choses) en nous intéressant à l’aspect visualisation, au niveau du tableau et des cartes Kanban.

L’une des choses qui différencie un Kanban et un simple tableau de tâches est la fameuse limite de travail en cours ou limite de « WIP ». C’est l’objectif du chapitre 8. Il se poursuit au chapitre suivant par son complément naturel, la gestion des cadences et de capacité du système.

Mettre en œuvre. Deux chapitres sont consacrés à cette étape. On s’intéresse d’abord au travail au quotidien : qu’est-ce qui guide la prise en charge des tâches, l’affectation. Comment traite-t-on les cas de blocage. Le suivi de la vie du Kanban est le second volet, on y parle débit et temps de cycle.

Etudier. C’est une partie très lourde, aussi bien sur la couverture du livre, car elle s’étend du chapitre au chapitre 16, que sur la teneur très technique et même mathématique du contenu !

Les chapitres 12 à 14 traitent des différentes typologies de système : on commence par les systèmes globalement saturés, ce qui nous amène sur la théorie des files d’attentes, puis sur la loi de Little. Sachez-le par avance : vous n’allez pas vous marrer ! Les systèmes localement saturés nous font aborder la théorie des contraintes et Laurent Morisseau fait très justement un parallèle avec le problème des bouchons de circulation. Le système Kanban variable nous fait aborder une approche statistique du système concernant les temps de cycle des éléments qui y circulent (motivation du lecteur nécessaire).

Kanban n’est jamais très loin du Lean, le chapitre 15 dédié au problème des limites top hautes nous permet d’aborder la notion de Muda. Enfin le chapitre 16 nous guide vers l’étude de l’impact des changements des limites sur le comportement du système ; capacité et temps de cycle. Beaucoup de diagrammes émaillent ce chapitre qui est toutefois ardu.

Améliorer. Cette phase est couverte par les chapitres 17 à 19. Tout d’abord la découverte des comportements émergents nous permet d’aborder deux notions importantes : les classes de services et les différents modèles de collaboration de l’équipe.

Est-il possible d’arriver à un contrat de service avec Kanban ? L’auteur réponds oui, mais cela repose sur certains préalables de référence, de contrat de service et de standardisation. Ce qui requiert un niveau de maturité élevé.

L’auteur conclut l’ouvrage d’abord par un bilan de l’approche Kanban en le positionnant dans le modèle Cynefin, puis en abordant l’extension du modèle Kanban en abordant l’Obeya Lean.

A titre de synthèse, il y a 3 aspects qui m’apparaissent proéminents dans ce livre :

  • Le contenu est très riche. C’est une surprise, une excellente surprise. Le livre en main pour la première fois, on ne s’attend certainement pas à un tel contenu, eut égard à sa taille réduite et à son contenu apparemment aéré.
  • Il est très abondamment et bien illustré. L’auteur a de toute évidence fait de grands efforts en ce sens. Et si certains diagrammes sont complexes, cela aide beaucoup.
  • Le texte est difficile. L’auteur ne fait pas de concession à la fluidité de lecture. C’est en quelque sorte une lecture qui se mérite. Si cela est justifié en partie par la richesse du contenu, je pense néanmoins qu’il aurait été possible faire mieux de ce côté.

Je suis habitué aux livres en français qui sont, sinon des textes de seconde zone (mais il y en a), du moins des ouvrages qui sont les petits frères des titres de référence de la littérature anglo-saxonne. Il n’en est rien ici. Même si je ne suis pas le mieux placé pour l’affirmer, Laurent Morisseau hisse son livre au niveau des textes de référence du domaine ! C’est inattendu et cela seul devrait vous convaincre de vous y attaquer.

En parlant d’attaquer, l’expression me paraît adaptée à cette lecture. Je l’ai déjà dit, elle est difficile. Une des raisons, je pense, est que Laurent a dû beaucoup s’appuyer sur son mind-map lors de l’écriture et cela transparait par un style très « structuré » qui nuit à la linéarité de la lecture. En lissant un peu plus son texte, Laurent aurait gagné un point supplémentaire à la note que j’ai donnée.

Je ne voudrais pas terminée cette note de lecture par une impression mitigée. Il est temps d’aller supplier votre libraire de vous céder une copie de livre à prix d’or !

kanban-it

Référence complète : Kanban pour l’IT, une nouvelle méthode pour améliorer les processus de développement – Laurent Morisseau – Dunod 2012 – ISBN : 9782100578672

Kanban pour l'IT


http://www.goodreads.com/book/add_to_books_widget_frame/2100578677?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

1ère conférence Lean Kanban France

Le par addinquydans ArticlesLaisser un commentaire

Cette première édition se déroulera les 18 et 19 Octobres dans les locaux de Valtech au 103 rue de Grenelle.

Cette conférence associera des sessions en Anglais proposées par des grands noms du domaine, à côté de sessions en Français proposant cas d’utilisation et retours d’expérience. Le positionnement de cette conférence, ainsi probablement que la capacité d’accueil limitée des locaux met le ticket d’entrée à un tarif assez élevé : de 450 € (early bird) à 800 € (last minute).

Je n’y serais pas, ayant déjà un agenda chargé et aussi, je dois l’avouer, du fait du tarif du ticket d’entrée. Mais une personne de mon équipe y sera. J’espère luis soutirer quelques informations.

1ère conférence Lean Kanban France

Note de lecture : Kanban and Scrum, making the most of both – Henrik Kniberg & Mathias Skarin

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; L’une des meilleures références pour comprendre le Kanban, pour les praticiens de Scrum

La lecture de ce bref ouvrage avait deux objectifs pour moi : étrenner mon Kindle DX (mais je n’en parlerais pas ici) et rédiger une note de lecture sur la version française pour le French SUG.

Ouvrir un nouveau texte signé Henrik Kniberg était forcément pour moi un moment fort attendu, tellement le livre précédent était excellent. Mon premier réflexe est de voir la taille du livre : 128 pages d’une couverture à l’autre pour la version française, contre 122 pour la version originale. Ça va. Cette fois, Henrik s’est associé à Mathias Skarin, également consultant chez Crisp. La table des matières montre une répartition remarquablement symétrique : 50 pages nous viennent d’Henrik Kniberg et traitent de la comparaison de Kanban et de Scrum sur 16 chapitres. La seconde partie, rédigée par Mathias Skarin, est une étude de cas. Elle couvre également 50 pages sur 16 chapitres. On aura bien sûr compris que ces chapitres sont très courts, chacun couvrant 3 pages en moyenne !

Kanban et Scrum, s’ils peuvent être complémentaires, se distinguent fortement l’un de l’autre. Scrum se focalise sur l’itération, lui donnant un périmètre au départ et s’organisant de façon à ce que celle-ci aboutisse positivement en suivant l’avancement des tâches et en acquièrant du fedback à la fois au cours de l’itération et à sa fin. Kanban en revanche ignore pratiquement le concept d’itération, et se focalise sur le flux des tâches, sur les limites d’accumulation de celles-ci aux différents stades d’avancement et en organisant le travail des différents membres de l’équipe en fonction des goulots d’étranglements pouvant apparaître.

Lire la suite →

Note de lecture : Lean from the Trenches, managing large-scale projets with Kanban, par Henrik Kniberg

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 10 ; Efficace, pertinent, intelligent !

J’ai acheté ce livre avec de grosses attentes. Non pas sur le contenu, car je ne me suis même pas préoccupé d’en connaître la teneur en l’achetant, mais simplement de par la connaissance des autres écrits d’Henrik Kniberg.

Henrik Kniberg aime faire court. Une tendance qui s’agrave avec l’âge : ce texte fait 150 pages. Et encore la partie principale (celle qui vient des tranchées) n’en compte que 100. A l’arnaque me direz-vous ? Il n’en est rien. L’auteur boucle en 100 pages ce qui en demande 250 à d’autres ! Ca tombe bien : notre temps est précieux, quand l’auteur va droit au but et fait que chaque ligne compte et donne de l’information, cela fait vraiment la différence. A ce jeux, Henrik Kniberg est le meilleur.

A l’image de Scrum from the trenches, l’auteur nous livre un retour d’expérience. Il nous livre ce qu’il a fait, ce qui a marché et ce qui n’a pas marché, comment son équipe en est arrivé là et qu’est-ce qui reste imparfait. Le texte est un modèle de clarté, de pertinence et d’honnêteté. Il est éclairant de par ses bonnes idées, par la démarche et l’analyse fine qui sous-tend cela. Mais que recèle donc ce texte ?

En fait les 16 (oui, 16 chapitres sur 100 pages !) tournent autour du tableau Kanban : la façon dont il est construit, comment a-t-il évolué, quelles sont les dynamiques de travail qui gravitent autour, quelles métriques en sont extraites. Bien sûr le texte est naturellement illustré par des photos (parfois auxquelles des indications sont supperposées) du Kanban ou de l’équipe. L’auteur n’a pas essayé de décrire de manière approfondie la façon de travailler de l’équipe (à la façon de ce qu’il avait fait dans « Scrum from the Trenches »), mais plutôt de se focaliser sur les dynamiques de l’équipe et du projet.

La seconde partie consacre 4 chapitres sur 50 pages pour évoquer certains aspects plus informatifs auxquels le texte principal se rapporte : ce qu’il y a dans XP, Scrum, Lean et Kanban ; l’automatisation des tests ; le planning poker et les diagrammes de cause-effets. Chaque chapitre est un modèle de pertinence et de concision.

Je ne vais pas passer du temps à décrire ce que contient le livre : il vous faut simplement le lire vous-même. Si vous êtes agiliste, débutant ou expert, il n’y a simplement aucune raison, aucune excuse pour ne pas consacrer du temps à vous plonger dedans !

lean-from-trenches-pragprog

Référence complète : Lean from the Trenches, managing large-scale projets with Kanban – Henrik Kniberg – Pragmatic Bookshelf 2011 – ISBN : 978-1-934356-85-2

Lean from the Trenches: Managing Large-Scale Projects with Kanban


http://www.goodreads.com/book/add_to_books_widget_frame/1934356859?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on