Note de lecture : Real-World Kanban, par Mattias Skarin

Note : 4 ; Une matière finalement un peu légère issue de retours d’expérience

Voici un livre qui ne sera pas un trop gros investissement en temps : écrit par l’un des collègues (et occasionnel co-auteur) de Henrik Kniberg chez Crisp, ce texte ne compte que 110 pages !

Le cœur du texte est composé de 4 chapitres qui sont autant d’études de cas, qui couvrent les 95 pages de la partie principale de l’opuscule ! En plus de ces 4 chapitres, les 20 premières pages constituent une introduction aux nouveaux-venus. Le titre « you hold the keys of your future » est assez significatif du contenu. Les principes du Kanban y sont présentées très clairement, mais l’essentiel de ce chapitre tourne autour des mécanismes d’amélioration continue qui sont au cœur de la pensée Kanban (et de la pensée Lean par extension). Malgré l’avertissement de l’auteur signifiant que ce chapitre peut être sauté, je pense au contraire qu’il vaut le détour !

La première étude de cas occupe donc le chapitre 2. Avec plus de 30 pages, c’est le plus long chapitre du livre. Le thème de cette étude de cas « Enterprise Kanban : improve the full value chain » est un Kanban produit, partant de l’idée jusqu’à la mise en production. Mais ce n’est pas tant le Kanban lui-même que les changements de processus qu’il engendre qui sont le thème de cette partie, avec plus spécialement un focus sur le lead time et comment une organisation différente permet de réduire celui-ci de manière drastique. La lecture de ce chapitre présente quelque intérêt, mais pas autant que je m’y attendais.

Lire la suite

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.

Lire la suite

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.

Lire la suite

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