Présentation Scrum & Kanban - conclusions

Suite et fin de cette série de posts sur la première version du support de mes prochaines conférences.

Après avoir fait une introduction de différents concepts (Méthodes empiriques, CAS, TOC) permettant de comprendre le socle commun des méthodes agiles telles que Scrum ou Kanban, je parcours trois retours d'expérience significatifs hors coeur de cible agile de manière à donner des axes de réflexions pour contextualiser le choix de ces approches.

Ce dernier volet donne des éléments de conclusion et une première version d'un radar de décision qui s'appuie sur les questions que j’ai pu me poser au fil de ces retours d’expérience et qui m’ont amené à faire des choix ou à expérimenter ces approches. Je les ai regroupés par thèmes:

• Sur la nature du système
• Ou est le goulot d’étranglement? Plutôt client, plutôt équipe?
• A-t-on besoin de gérer des stocks/files d'attente? A-t-on des équipes spécialisées travaillant à des vélocités différentes?
• Sur la nature du travail
• Quelle est l’unité fonctionnelle minimum recettable? Sa fréquence?
• Un incrément time boxé a-t-il un sens?
• Le takt time a-t-il plus de sens sur une tache unitaire? Un incrément fonctionnel? Une version?
• Sur le pilotage et ses contraintes
• Doit-on faire un pilotage plutôt par le nombre de tâches (forte volumétrie)? Par leur estimation?
• A-t-on un besoin de priorisation métier plutôt au niveau de la tâche? Par domaine métier?
• Sur sa capacité à s’engager
• Plutôt par les délais avec des mesures sur des taches répétitives?
• Plutôt par la planification (priorisation & contraintes: dépendances à l’extérieur de l’équipe (sous-traitance, ressource partagée, client, ...) à gérer par exemple)?

A partir de ces thèmes, je peux construire un radar d’aide à la décision, simple: Plus on se rapproche du centre, plus le terrain est favorable à une approche type Scrum et plus on s’en éloigne plus le terrain est favorable à une approche type Kanban.

Prochaine étape : une première session à blanc avec AgileRennes afin d'avoir un feed-back au plus tôt sur le contenu suivi d'un refactoring du support.

Téléchargez la version 0.5 de la présentation.

Prochaine Date Ateliers Agiles sur Rennes: 26/27 Janvier

Ateliers Agiles

En partenariat avec le centre de formations Agiles Agilbee, nous organisons deux jours d'Ateliers Agiles les 26/27 janvier 2010.

Les ateliers sélectionnés sont des classiques de la communauté Agile et permettent d'en expérimenter chaque facette (XP, Scrum, Lean, ...).

Ces deux jours sont à destination de tous les intervenants des projets logiciels expérimentés ou débutants. Il est cependant préférable d'avoir une connaissance théorique minimum de l'agilité.

Tous ces ateliers ont été joué dans différentes conférences Agiles: Agile Open France, XP Days France, XP Days Benelux, Agile Tour, AgileRennes, AgileNantes, journée Meito, forum Grafotech de Granit. Ils sont également un support régulier de nos sessions Pensez Agile! et du cursus LP SIL de l'IUT Laval.

• Plus d'informations sur la session.
• Téléchargez la plaquette de la session.
• Pour s'inscrire.

Présentation Scrum & Kanban - troisième retour d'experience

Suite de mes posts sur mes retours d'expérience entre Scrum et Kanban hors cœur de cible Agile:

J'ai cette fois écrit une première version de mon troisième retour d'expérience sur un projet de Recette Usine automatisée avec une approche Kanban. Il s'agissait de livrer 4000 scénarios et 4000 scripts automatisés en trois mois: un projet de 1800 j.h, 35 personnes en pic de charge distribuées sur 5 sites.

Téléchargez la version 0.4 de la présentation.

Feed back XP Days Benelux

De retour des XP Days Benelux pour un petit interlude du côté de Mechelen avec 150 agilistes européens.

Ma rétrospective

Ce qui a bien marché
On peut organiser un évènement important avec beaucoup de chaleur et d'interactions. Que l'équipe d'organisation a créé l'environnement pour que cela se fasse naturellement, le rythme, les échanges. J'ai pu avoir de nombreuses conversations très intéressantes avec plein de monde.

Les sessions: Le pitch des sessions a tourné au spectacle, particulièrement le deuxième jour, avec un Peter bien en forme!


Se déplacer jusqu'en Belgique vaut la peine pour voir d'autres orateurs, d'autres sessions, d'autres sujets! En plus, j'ai pu retrouvé des participants d'Agile Open France avec plaisir (Agile Open France 2010 c'est bientôt d'ailleurs), notamment Patrick Debois qui est à l'origine de ma session avec Xavier qui a été une réussite : première session en anglais, première rencontre avec Xavier, tout à fait charmant, 35 personnes, des idées intéressantes, bien time-boxée. Nous aurions pu faire mieux bien sur. Les ateliers sont un bon moyen de commencer les conférences dans un environnement ou on n'est pas tout à fait à l'aise.
--Update : Feed back des participants à ma session

Pour les autres sessions, j'ai eu une vision claire du Lean et de Toyota, un retour d'expérience de Coding Dojo par Emmanuel à l'origine de cette pratique avec Laurent Bossavit, un atelier (Open Source) pate à modeler sur la conception évolutive et la révision des objectifs - tests d'acceptances chaque fois que l'environnement change,

une session Product Owner avec une métaphore intéressante de garçon de café :o), un atelier de résolution de conflits sans compromis avec Pascal & Jeff, un atelier de peer coaching avec Portia et un coding Dojo en Haskell.

Ce qui a moins bien marché

• Comme toujours un peu de frustration de ne pas avoir vu toutes les sessions: certaines d'entres elles ont eu un très bon feed-back
• Une session qui est une erreur de casting (pour moi), pourtant je la connais la loi des deux pieds!
• Je n'ai pas pu aller à la session d'Aikido pour cause de douleurs au cou, vraiment dommage
• Haskell, ce n'est pas (encore?) mon langage préféré
• Moins d'apprentissage que d'habitude
• Pas pu participer aux sessions de clôture

Les questions que je me pose
* L'idée de partager des expériences avec d'autres coachs par le biais d'ateliers me plait (Atelier Rétrospective avec Philippe, Jeu de la valeur métier avec Pascal et Portia, Atelier Management visuel avec Xavier). Quel sera le prochain atelier partagé? Et avec qui? Et ou?

* Je vais à ces conférences, plus pour vivre une expérience (au travers les échanges, les ateliers, les jeux). Quelle part d'apprentissage cela m'apporte?

Ce que j'ai appris

* Qu'il faut être disponible:

L'intérêt de ces conférences est aussi dans ce qui se passe à côté: les coding dojo du soir, les jeux au bar, les discussions ouvertes. Deux jours "loin de tout" est un bon format pour cela. Arriver en étant disponible est un atout.

* Qu'il faut expérimenter:

Pour cela, il faut un peu de temps, un environnement qui le permette.

Pour que ce soit parfait

• Rejouer les sessions plébiscitées la veille dans le dernier slot de la seconde journée

Autres news:

• Feed back Agile Open Coffee de Rennes
• P'tit Dej' IUT Laval sur les méthodes agiles le 14 décembre...à 18h00!

Présentation Scrum & Kanban - second retour d'experience

Dans cet incrément, j'affine encore l'éclairage que la Théorie des Contraintes peut apporter pour mieux comprendre les différences entre les approches avec la perspective XP:

Ou est placé le goulot d'étranglement sur une approche XP?
L'excellence technique! Le goulot d'étranglement est placé sur la qualité de la production de l'équipe de développement mettant ainsi le focus naturellement sur les pratiques d'ingénierie logicielle. On subordonne l'équipe sur cette contrainte forte de qualité qui n'est plus négociable : le développeur se met au service de ce qu'il réalise.
Il y a plusieurs raisons qui poussent à mettre la contrainte sur la qualité: à court terme pour des logiciels ou la tolérance aux anomalies est critique et à plus long terme par exemple pour la maintenabilité de l'application en maitrisant la dette technique du système.

Alors ou est le goulot d'étranglement du cycle en V?

J'ai également affiné les termes de contraintes que l'on va mettre sur les systèmes pour les définir: les contraintes sont de deux types: Délai de production (Lead Time si c'est vue du client ou cycle time si c'est vue de la production) et stock de travail en cours (Work in Process : WIP) limité.
Avec une approche itérative & incrémentale, la contrainte est mise sur le délai de production avec des itérations time-boxées. On a une contrainte indirecte sur le stock de travail en cours limité par la capacité à faire de l'équipe : le sprint backlog.
Avec une approche en flux tiré, la contrainte est mise sur le stock de travail en cours par une limite kanban sur chaque état. Le délai de production devient la variable à gérer.

J'ai également revu le premier retour d'expérience sur une cellule transverse avec la vision TOC et fait une première version de second retour d'expérience sur une migration outillée avec une approche Scrum-ban.

Téléchargez la version 0.3 de la présentation.

Atelier Management Visuel - 2ème édition

J'avais fait un premier retour sur l'atelier Management Visuel que je prépare pour les XP Days Benelux avec Xavier Quesada.

A l'occasion d'un forum Grafotech Agile et suite aux retours d'Agile Tour Rennes, j'ai pu refaire un atelier avec une quinzaine de participants répartis en trois équipes. 1/3 avait participé à ma session sur le management visuel avant de venir ce qui a peut être influencé le rendu final.
Cette fois, j'ai pu dérouler les slides qui introduisent la session. La session a été très riche et très dynamique.

Mais donnons un peu de contexte à cet atelier: les équipes doivent construire un tableau de taches contenant 4 user stories, chacune contenant 5 taches et avec des contraintes opérationnelles. On se place en milieu de sprint pour représenter l'avancement des taches. La construction du tableau se fait en deux itérations avec une revue croisée par les équipes entre les itérations.

La revue peut se faire à l'aide de radars avec comme axes les objectifs de simplicité, lisibilité, créativité et compréhensibilité que doit avoir tout bon outil de management visuel. Ce radar sert d'axe d'amélioration pour la seconde itération.

Et voici les retours de la session:



Première équipe

L'équipe a, dès la première itération, choisie d'avoir une première ligne mettant en évidence les obstacles et les taches prioritaires à traiter, avec un signal visuel fort marqué par un encadrement bleu.
Les trois équipes ont créé une colonne pour mettre les taches réalisées dans la journée. C'est une option de l'atelier.

Certaines lignes fonctionnelles ont des post-its jaunes d'autres verts. Il n'y a pas de raison de différencier les couleurs à ce niveau, cela nuit à la compréhension du tableau. Par contre, les taches de la ligne prioritaire sont en rouge de manière rendre l'urgence de traitement de ces taches.

Equipe 2
Cette équipe a été relativement créative mais le résultat est un tableau qui va évoluer difficilement: La colonne En cours a été divisée par autant de membres de l'équipe: si l'équipe change, il faut refaire le tableau. Le travail collectif comme le binomage va être difficile a traiter. Pour autant cela peut avoir du sens dans une équipe stable et très spécialisée.
Tous les post-its de taches sont jaunes, les anomalies bleues et les obstacles rouges: Le code couleur est simple et facile à comprendre.

Equipe 3

Mis à part le scotch électrique qui donne rien sur du papier kraft (cela rend mieux sur un tableau blanc), le rendu de ce tableau est assez bon. C'est dommage encore d'avoir utilisé des postits de différentes couleurs pour les taches fonctionnelles. A part cela, le tableau comporte un certain nombre d'informations supplémentaires qui ne surchargent pas le tableau et sont compréhensibles: ce sont les petits post-its de couleurs qui portent des états: en continuant ce principe, la colonne "ToDay" aurait pu être simplifiée par un post-it "Done".

C'est aussi la seule équipe ayant eu l'idée de faire une liste d'obstacle mais par manque de temps il n'y a pas eu de rendu.

Conclusion collective
On se rend compte avec cet atelier d'une certaine difficulté à rendre visuel les informations pertinentes d'un contexte projet tout en restant simple, lisible et compréhensible. Lorsque l'on évoque les outils de management visuel, on parle d'outils simples à base de post-it. Pour arriver à cette simplicité, il faut d'abord se débarrasser de tout le superficiel et n'afficher que ce qui apporte de la valeur: la valeur du management visuel est de provoquer un feed-back immédiat.
On prend également conscience de l'intérêt évidant de concevoir collectivement ces outils que toute l'équipe va utiliser. C'est un atelier de construction d'équipe qui la plupart du temps n'est pas réalisé, le scrummaster réalisant seul cette tache.

Différences entre Scrum et Kanban : l'éclairage TOC

Je reviens sur la différence entre Scrum et Kanban. Réfléchir sur leurs différences m'a finalement amené à réfléchir sur les fondamentaux qu'ils partageaient.
J'avais déjà évoqué l'approche empirique des processus, support de mon introduction à l'agilité lors de l'étape Nantaise d'Agile Tour.
Dans la présentation sur laquelle je travaille, je parle également des systèmes complexes adaptifs en introduction. Mais il manquait un élément fondamental sur lequel je reviens aujourd'hui: La Théorie des Contraintes (TOC):

La Théorie des Contraintes a pour principe fondamental que le flux généré par une organisation est limité par au moins un processus (i.e. un goulet d’étranglement). La production de valeur ne peut donc être augmentée qu’en augmentant la capacité de production au niveau du goulet d’étranglement.

Concevoir un processus c'est savoir ou placer son goulot d'étranglement:


Scrum
Pour Scrum, le goulot d'étranglement est placé, par conception, au niveau de l'équipe de développement.


* Exploiter ce goulot:

• Veiller à garder l'équipe concentrée sur son travail et qu'elle ne soit pas bloquée, c'est le rôle du Scrummaster.
• Prioriser son travail sur ce qui apporte de la valeur et veiller à ce qu'elle est toujours du travail, c'est le rôle du Product Owner
• Ne pas surcharger le goulot, qui tire son travail (le Sprint Backlog lors du Sprint Planning Meeting) de la file d'attente (le Product Backlog).

* Subordonner le reste du système au goulot:

Le flux de production est nivelé par la vélocité de l'équipe au rythme des itérations. Le travail du Product Owner doit s'adapter à cette vélocité, le travail de réception du client s'adapte au rythme des itérations. En amont et en aval, le reste du système s'adapte bien à la vitesse de l'équipe.

* Elever le goulot:

Ce sont les rôles de coach d'équipe du ScrumMaster et de leadership du management.

Mais puisque par conception on place le goulot sur l'équipe, le Scrummaster doit travailler sur les goulots d'étranglements potentiels. Entre autre, le Product Owner peut rapidement devenir le goulot d'étranglement d'une équipe Scrum. C'est d'ailleurs le cas explicite des équipes Scrum de type A.

Cette vue par la théorie des contraintes donne un éclairage sur les rôles d'une équipe Scrum intéressante.

Passons maintenant au Kanban

Par conception, le goulot est placé sur le client. La capacité du système doit donc s'adapter au rythme du client, nivelée par le Heijunka au rythme du takt time.

* Exploiter ce goulot:

Cela passe par son implication: Pour une entreprise Lean, cela passe par une réorganisation de l'entreprise par familles de produits et chaines de valeur, puis de persuader les fournisseurs et clients de suivre la même voie. L'entreprise Lean est une entreprise transverse qui dépasse ses propres frontières avec une approche plus globale.

* Subordonner le reste du système au goulot:

Cela se fait en positionnant des limites sur les états du processus pour mettre en place le flux tiré par le client.

On comprend mieux qu'il n'y ait pas de rôle à part entière dans le Kanban si ce n'est le responsable de la chaine de valeur (value stream) et que la difficulté va être d'impliquer le client dans cette démarche et d'établir la bonne cadence, ce qui passera par de l'expérimentation sur les limites des états.

Dans les deux approches, on repose bien sur la théorie des contraintes en positionnant le goulot d'étranglement dans notre système (équipe de développement ou client) puis en exploitant ce goulot.

Présentation de Scrum au Kanban

En embarquant la TOC en tant qu'élément fondamental pour définir ou comprendre les différentes approches agiles, cela m'a amené à reprendre une partie de l'introduction et de mon premier retour d'expérience, vive le refactoring!

Donc une version V0.2 pour la présentation ici.

Supports Agile Tour Rennes 2009

Les supports des présentations d'Agile Tour Rennes 2009 sont en ligne sur le site AgileRennes:

• Les exigences exécutables, Philippe ENSARGUET : présentation & support


• Management visuel, des principes Lean aux implémentations Agiles, Laurent MORISSEAU : présentation & support


• Agilité et facteurs humains, Yvan GALISSON : présentation & support


• Organisation, rôles et techniques de la MOA, Pierrick LOUAPRE : présentation & support


• l’Agilité : quel apport pour le back-office , Anne DUBEDOUT : présentation & support Xavier Warzee et JCS consultants


• Retour d'expérience Teamlog, Thierry ROGER: présentation & support


• Scrum, XP et Getting Real : une combinaison gagnante, Pascal LE MERRER: présentation & support


• Initiation aux méthodes Agiles, Chris Ozanne: présentation et support


• Outils d'agilité : la forge logicielle, Philippe ENSARGUET & Stéphane LORCY: présentation & support


• Mise en oeuvre de SCRUM / XP dans un contexte d'évaluation CMMI niveau 2, Yann COSTE - Olivier CHOTIN: présentation et support


• Passage à l'agilité chez FT R&D / Déploiement de processus agiles, Michel TRAIN : présentation & support


• Retour d'expérience Sodifrance, Emmanuel FOUQUAY : présentation et support
• L’Agilité, la réponse aux attentes de nos clients, Jean-Yves Le Bleu : présentation et support

Ainsi que les entretiens des orateurs réalisées par Anne Dubedout et Pierrick Louapre.
Et enfin les photos de la journée!


Merci à tous pour vos différentes contributions à cet évènement.

Présentation Scrum & Kanban - premier retour d'experience

J'ai fini la première version de mon premier retour d'expérience pour cette prochaine présentation:

• Premier incrément : Le pitch
• Second incrément : L'introduction
• Troisième incrément : Retour d'expérience d'une cellule transverse en Scrum

Le prochain incrément portera sur un autre retour d'expérience de migration outillée d'un SI avec une première approche Scrum puis Scrum-Ban.

Feed back Agile Tour Bordeaux

Dernière étape de mon Agile Tour: Bordeaux qui conclue une série de conférences à Rennes, Bordeaux, Nantes et Paris.
J'ai pu assister à deux conférences, un kata en Java sur le TDD et la seconde sur la contractualisation des méthodes agiles par Frédéric Faure dont on peut voir le support ici.

L'organisation était très bien, l'équipe parfaite. J'attends les vidéos des sessions.

J'ai pu rejouer ma session sur le Management Visuel avec un créneau de 2h10 pour une session d'1h30. J'en ai profité pour être un peu plus bavard que d'habitude et faire une séance de questions/réponses d'1/2 heure sur n'importe quel sujet agile: Difficile comme exercice!

Il y avait autour d'une cinquantaine de personnes à la session avec un bon retour: Un ROTI de la session de 4.5 (4.6 à Rennes) et un ROTI d'apprentissage de 4.2 (4.5 à Rennes).
Le support (V2.0) de la session est en ligne ainsi que le résumé de la session. La vidéo de la session devrait arriver bientôt.
J'ai eu une quarantaine de feed-back: le retour est différent de celui de Rennes, ce qui me semble normal puisque j'avais pris en compte les remontées que l'on peut lire ici.

Vocabulaire et notions de bases

Les problèmes remontés portent principalement sur le vocabulaire et les notions de base de Scrum, Lean et Kanban. Effectivement, le public était plus débutant sur les méthodes agiles qu'à Rennes. Ajouter une introduction sur toutes ces notions semble difficile car cela ferait une session trop longue. J'ai ajouté un pré-requis sur une connaissance minimum des méthodes agiles pour les prochaines sessions ainsi que quelques pointeurs:

• Visual Management par Xavier Quesada
• Visu-Wall par Patrick Debois
• Scrum vs Kanban par Henrik Kniberg
• Scrum et XP depuis lestranchées par Henrik Kniberg

Exemples concrets et retours d'expérience

Pour les exemples plus concrets ou plus compliqués de tableaux Kanban et surtout pour les contextes dans lesquels cette approche est efficace ou pertinente, il va falloir suivre la prochaine présentation sur mes retours d'expériences ou commencer ici. Une partie des réponses y sera présentée.

Pour expérimenter, j'anime un atelier, le prochain se déroule à Rennes jeudi prochain puis aux XP Days Benelux le 23 novembre. N'hésitez pas à me contacter pour une demi-journée Management visuel (session & atelier).

Rôles et individus

Certaines questions tournent autour de la place du Product Owner (et la MOA/AMOA)
La question n'étant pas plus détaillée, la réponse peut tomber à côté. Dans du management visuel pur, la place du Product Owner peut être de s'assurer que la priorisation des histoires utilisateurs est bien visible, comprise et que le travail s'effectue bien par rapport à cette priorisation métier, bien que ce soit plus le rôle du scrummaster. Si ce n'est pas le cas, il est temps de réexpliquer la valeur métier portée par le projet, comment les histoires sont priorisées, peut être également la vision?
Bien que l'accent est été mis sur l'équipe de développement lors de la session, le Product Owner fait partie de l'équipe Scrum, assiste donc aux cérémonies qui se déroulent autour des radiateurs d'informations. Ce qui est dit pour l'équipe de développement est également vrai pour le Product Owner.
L'assistance à maître d'ouvrage intervient plus sur la définition des besoins, donc comme support visuel, on peut utiliser les story Map (plus d'informations sur le user stories mapping) par exemple.

D'autres tournent autour de la personnalité du coach et des membres de l'équipe, de la maturité de l'organisation
Cette question est plus générale que les outils de management visuel, plus générale que la personnalité du coach: c'est de recentrage de l'agilité vers l'humain et de l'auto-organisation dont il s'agit, avec les implications que cela amène: management de type leadership, auto-organisation de Scrum, culture de l'amélioration continue du Lean, auto-éveil de Crystal, autodiscipline d'XP ...

Je renverrais pour ce genre de questions à la présentation Illusions et désillusions, de Patrice Petit, ou l'une des conclusions porte sur l'importance du rôle des RH dans les projets de demain et ou il situe le rôle du coach plus proche de celui du RH que du leader technique. Donc la personnalité du coach est importante, tout comme celui du manager ou de toute l'équipe, mais également son profil.
Quelque soit le coach ou le manager, pour favoriser l'émergence il faut créer un environnement qui le permette, le management visuel est une partie de la réponse, et il y a également des pratiques notamment pour favoriser le consensus (Cores protocoles, rétrospectives, votes, ...), et des approches plus systémiques, comme le principe de circularité déjà évoqué.

Flux tirés, flux tendus


Système Kanban et limites sur les états
Plusieurs questions autour des limites sur les états d'un système Kanban:
Ces limites sur les états (en cours, fini, à faire comme exemple simplifié d'états d'un processus type Scrum) permettent de réguler un système et de l'amener mécaniquement vers un système en flux tiré. Mécaniquement car une fois le système saturé (chaque état ayant atteint la limite fixée), pour "pousser" une tache de l'amont vers l'aval, d'un état à un autre, il faut d'abord libérer une tâche dans l'état suivant. De proche en proche, c'est le dernier état qui, lorsqu'il n'est plus saturé, permet de "tirer" les tâches en amont.

Alors pourquoi avoir une limite sur le dernier état (Fini pour revenir à l'exemple simple précédent)?
Il faut considérer le système dans son entier, du point de vue du client. Pour lui, l'état Fini, n'est pas le dernier état, sauf s'il correspond à l'état En production et dans ce cas pas besoin de limite. Sinon, il reste encore des taches à réaliser, ne serait-ce que le déploiement en production. Sans cette limite, rien (de mécanique) ne pousse à mettre en production et les taches peuvent s'accumuler.
En fait, bien que ce ne soit pas naturel, cette limite existe de manière implicite (un lot à livrer classiquement, un incrément, un patch, une Minimum Marketable Feature ou MMF). Cependant, beaucoup de tableaux Kanban n'ont pas de limite sur cet état.

Et pourquoi une limite sur les files d'attente (ou buffer)? Pourquoi ne pas laisser faire pour mieux identifier les problèmes?
Effectivement, ne pas mettre de limite sur les files d'attente est un bon moyen d'identifier les goulots d'étranglement d'un système et donc de l'exploiter et de subordonner le système au goulot d'étranglement comme le préconise la Théorie des Contraintes (TOC).
Pourtant on peut mettre une limite sur cet état pour plusieurs raisons: aller vers du flux tiré, aller vers du Juste à Temps, éliminer le gaspillage: Le Lean nous apprend que tout stock est du gaspillage si l'on regarde le système dans sa globalité.

La limite étant sur les nombres et non la capacité à réaliser (comme pour du Scrum avec la vélocité), cela nécessite d'avoir un Product Backlog complètement détaillé?
Non, on a le même principe Scrum de Product Backlog détaillé Juste à Temps (avec l'activité du Product Owner: Grooming the backlog), sauf que le Juste à Temps n'a pas la même portée en Scrum (une itération ou Sprint) qu'en Kanban (un MMF).
Cette question est légitime car si on limite le nombre, implicitement on sent qu'il faut une même granularité pour toutes les taches, un même niveau de détail. D'ailleurs un des principes d'un système Kanban est de minimiser la variabilité des éléments du système (les tâches) et de minimiser leur taille (le T-shirt sizing est suffisant pour du Kanban). Cela pose également la question des métriques utilisées pour ces approches et de l'engagement que l'on peut prendre, mais puisqu'elle n'a pas encore été posée je vais attendre pour y répondre :o).


Une question également sur la difficulté de mise en place du flux tiré
Et pourquoi ne pas essayer de mettre d'abord une limite sur le travail en cours avant de parler de flux tiré ou de Kanban? Expérimentez!
Et puis challengez votre équipe et votre processus pour réduire cette limite ou positionner d'autres limites sur d'autres états.


Une question inattendue sur le flux tiré vs le flux tendu
Le flux tiré est un des principes d'un système Kanban, le flux tendu est une conséquence du principe de Juste A Temps (JIT) ou zéro stock. Ce principe appliqué à un système Kanban consiste à réduire la limite sur les files d'attente à une valeur proche de 0.
Il se trouve que dans mon dernier projet pour lequel j'ai eu une approche Kanban, nous avons eu une période de quelques jours en flux tendu entre deux équipes spécialisées (métier - développement) qui comptaient 34 personnes au total. Nous avions 1 à 2 heures de travail d'avance en permanence, autant dire pas de marge car ce delta n'était pas réellement suffisant pour la répartition du travail dans l'équipe. C'est assez stressant comme situation pour tout le monde.
La solution pour ne pas aller dans le mur a été de basculer une petite équipe pluri disciplinaire de trois personnes d'une équipe à une autre selon les besoins. Je reviendrais plus longuement sur ce cas particulier dans ma session de retours d'expérience.

Différences entre Scrum et Kanban

Bien que cela fasse partie des bases à lire dans Scrum vs Kanban, il se trouve quand même Scrum, à l'origine, était décrit en 3 approches différentes:

Type A - Scrum typique, enchainement séquentiel des sprints et un temps d'arrêt entre pour retravailler le Product Backlog et préparer le prochain Sprint.

Type B - Scrum avec les sprints qui s'enchainent. Le Product Backlog est typiquement affiné en parallèle du Sprint. Du temps est alloué pour estimer les user stories par l'équipe pendant ce Sprint soit comme activité récurrente soit lors d'une réunion de travail positionnée quelques jours avant la fin du Sprint.

Type C - Les sprints sont de longueurs variables et non contraints par le temps. Il se trouve que le Type C est proche du Kanban. Et que l'on peut y aller de manière incrémentale par du Scrumban, approche développé par Corey Ladas dès 2004 chez Microsoft.

Inversement, un système Kanban simple cadence (une release tous les mois avec une rétrospective et une planification à la clef par exemple) se rapproche d'une itération Scrum.
La différence n'est donc pas si simple mais on peut dire que Scrum est basée sur une approche itérative et incrémentale et Kanban sur du flux tiré et de la cadence.

Management visuel, sortir du développement logiciel

La session met l'accent sur les projets de développement logiciel là ou le management visuel s'applique au monde du travail: visualisation d'informations et communication, Mindmap ou carte heuristique

Cliquer pour agrandir l'image

Et visualisation de processus comme Visual Stream Mapping, Alex en parle récemment ici.


Questions plus générales


Par ou commencer? Dans quel ordre?
Commencer là ou vous en êtes (en modélisant votre processus grâce au Visual Stream Mapping et en le visualisant par un tableau Kanban par exemple), identifier les problèmes à résoudre, les rendre visible, se concentrer sur le problème principal, identifier les causes profondes et trouver une solution d'équipe à ces causes, implémenter et mesurer les effets. Bref de l'amélioration continue.

Cela vous amènera surement à introduire les pratiques une à une en réponse à des problèmes ou des axes d’amélioration, c’est la même idée directrice que pour l’introduction du Lean proposée par Poppindieck.
Plus pragmatiquement, c’est ce que l’on constate en tant que coach agile: aborder l’agilité, non comme une fin en soi, mais pour répondre à un vrai besoin: ce qui permet de démarrer par un sous-ensemble de pratiques issues d’XP, de Crystal, ou autre peu importe.

Approfondir l'amélioration continue
Cela fera peut être parti d'un autre billet, en attendant on peut creuser l'esprit Kaizen du Lean par exemple.


L'agilité dans un contexte multi projets et ressources partagées (une équipe pour plusieurs petits projets)?
Je vais discuter d'un retour d'expérience dans un contexte similaire de cellule transverse (plusieurs petits sujets pour une équipe partagée) dans le prochain incrément de ma prochaine session. Scrum n'est pas adapté à ce contexte pour différentes raisons. Et je pense qu'une approche Kanban l'est plus sans pour autant apporter toutes les réponses. Et concrètement, le tableau Kanban va se décomposer en une matrice avec pour les colonnes des états et les lignes de la matrice les petits projets (swimlane). Cela permet d'avoir une vision globale des projets et de pouvoir réguler le processus.

Et pour tous,
Comment mesure-t-on que l'agilité a apporté quelque chose à l'entreprise? Au client?

Et pour finir ce retour, merci aux organisateurs de m'avoir invité à cette étape et hébergé également. A lire des retours sur l'étape de Bordeaux sur les blogs ici, ici ou là.

Présentation Scrum & Kanban - Introduction

J'ai fini la première version de mon introduction pour cette prochaine présentation:

* Premier incrément : le pitch
* Second incrément : l'introduction - la version pdf avec commentaires et l'animation powerpoint
* Prochain incrément : Retour d'expérience d'une cellule transverse en Scrum

Le parti pris de cette introduction est de donner les fondements, le vocabulaire pour mes retours d'expérience.

Les Ateliers Agiles

En sport s'entrainer n'est pas une option. Je repensais à cela en lisant l'article d'Octo Sir, yes Sir! sur la décentralisation et l'adaptation notamment grâce à l'entrainement et à la communication et en pensant à ma propre expérience de course au large. Je me suis mis tardivement à la voile et j'ai du m'entrainer des années avec d'autres avant de pouvoir naviguer en solitaire par gros temps.
Même avec cela, je ne pourrais pas y retourner maintenant sans un gros entrainement, cela s'entretient.



Nous faisons régulièrement le constat qu'il n'y a pas de place pour s'entrainer dans le milieu professionnel, se former quelque fois et on plonge dans l'opérationnel avec la pression sur les délais, la sanction de l'erreur et la zone de confort ou l'on cherche tous à rester, il y a peu de place pour l'expérimentation.

Les démarches empiriques sur lesquelles reposent les méthodes agiles nécessitent par définition cette expérimentation. La culture d'amélioration continue aussi. Alors il faut créer l'environnement qui la stimule et la permette. Certaines pratiques participent à cela:

les Dojos

Sous forme de randori pour les inter contrats ou de kata, le dojo est LA pratique d'entrainement pour les développeurs. Malheureusement on ne trouve pas partout ces sessions, notamment à Rennes. Alors je cherche des volontaires pour lancer cela à Rennes.


Les ateliers

Il y en a de plus en plus, comme je le notais déjà lors des XP Days de Paris. Les ateliers sont un lieu d'expérimentation, que ce soit pour les participants mais également pour le facilitateur. Les ateliers Open Source fleurissent ces derniers temps, profitons-en!

Sur la région, je développe de plus en plus ces ateliers agiles: XP Game, Jeu de la valeur métier, rétrospective, Scrum 59', Management visuel et d'autres à venir: bref, le meilleur de ce qui se fait dans la communauté Agile.

Si vous souhaitez vous entrainer à Rennes, nous organisons les 19 et 20 Novembre avec Agilbee une session d'Ateliers Agiles rassemblant tous ces ateliers.

les sessions à blanc

Avec AgileRennes, nous organisons des sessions à blanc pour créer un environnement ou les participants peuvent essayer une conférence ou un atelier dans un environnement de confiance, de critiques positives et d'échanges. Alors venez proposer votre sujet!

Une présentation itérative et incrémentale

Je fais des rétrospectives très régulièrement, je l'avoue, lors de mes missions de coaching agile. Il m'arrive même d'en faire en public. Mais j'apprécie également mes rétrospectives personnelles de fin de mois ou de fin de projet, c'est un moment d'introspection et de prise de recul très riche.

La dernière en date fait suite à la fin d'un projet important avec une approche orientée Kanban. Elle m'a permis d'avoir une vision globale de mes deux dernières années de travail ou j'ai eu l'occasion d'intervenir sur des types de projets relativement éloignés d'un coeur de cible agile pour lesquels j'ai adopté différentes approches (Scrum, XP, Kanban).

L'idée m'est venue, non de comparer Scrum au kanban, puisque c'est à la mode et malgré le titre, ni même Scrum au Lean, mais plutôt de les contextualiser dans le cadre d'un retour d'expériences.
Ce sera donc le thème de mes conférences en 2010, après le Management Visuel, des principes Lean aux implémentations agiles de cette année.

En commençant à y réfléchir, j'ai fait le point sur le processus itératif de conception adopté cette année que ce soit pour les conférences ou les ateliers:

Itération 0

• Définition de la vision
• Quels sont mes objectifs?
• Quel peut-être le bénéfice attendu par les participants?
• Quels sont mes contraintes et mes tests d'acceptance?
• Quel est le message de la session?
• A qui je souhaite m'adresser?
• Quels sont les thèmes que je veux aborder?

Le livrable de cette itération est un paquet de cartes bristols qui me sert tout au long de la réalisation, notamment qui m'aide à faire mes supports, ou simplifier le contenu par rapport à mes objectifs.

Et je me fixe une date de conférence pour me contraindre un peu.

Itération 2...n

• Je fais le contenu de manière itératif

Pour aller plus vite, je fais des dessins au tableau blanc, je prends des photos et je les colles dans mes slides.

Release 1.0: La première conférence

Je cherche à avoir du retour au plus tôt pour affiner ma présentation, mon chat étant particulièrement compréhensif quand je lui parle Agilité mais peu bavard, je dois rapidement confronter ma session à la dure réalité d'un public. Pour le faire en toute confiance, j'avais organisé une session à blanc, avec un public restreint, à AgileRennes. C'est une approche que l'on généralise car cela favorise l'émergence de nouveaux conférenciers.

Pour pouvoir m'améliorer, je demande systématiquement un feed-back sur la session en répondant à toutes les questions de ce questionnaire.

itération n+1

• Prise en compte des premiers retours

Release 1.1: Deuxième session

Pour ma deuxième session, je suis aller à Nantes recueillir une deuxième vague de retours, une douzaine très enrichissantes.

itération n+2

• Prise en compte des seconds retours
• Puisque les retours étaient positifs sur le contenu, j'ai pu passer plus de temps à fignoler le rendu visuel

Release 2.0

Session Agile Tour Rennes pour une centaine de personnes avec séance de feed back. La session évolue à chaque fois, et j'ai déjà intégré une cinquantaine de remarques sur le support, notamment pour la prochaine session 2.1 à Agile Tour Bordeaux cette semaine.

Pour ma prochaine présentation de retour d'expériences Scrum/Kanban, je vais adopter la même approche itérative qui a très bien marché: j'ai d'ailleurs déjà passé l'itération 0 et 1 (le squelette et un premier jet des slides pour avoir une vision global).

Mais pour aller un peu plus loin, je souhaite avoir également une approche incrémentale: Je vais travailler maintenant sur chaque sous chapitre et livrer les slides et le support texte sur ce blog au fur et à mesure (c'est ce que fait par exemple Jurgen avec son livre et son blog):

L'objectif est de la jouer à AgileRennes, AgileNantes puis en V2.0 pour les XP Days Paris et enfin Agile Tour. Donc si le sujet vous intéresse, laissez vos commentaires ou vos questions au fil des notes du blog.

* Premier incrément : le pitch

* Prochain incrément : l'introduction

Retour MEITO & Scrum 59

Hier, je me suis promené du côté de Vannes pour la journée de conférences organisée par la MEITO, drôle de mélange de méthodes agiles et d'outils de modélisation ou de migration de code.

La session qui a vraiment retenue mon attention est celle d'Exo Platform, par Dimitri Baeli, sur la généralisation de l'adoption Scrum sur 17 équipes réparties sur 4 pays pour des projets Open Source et leur roadmap agile pour 2010. Vous pouvez lire l'article sur le blog de Nicolas pour découvrir cette société et leur produit.

Le deuxième point est les contacts et l'idée grandissante de lancer un AgileVannes, l'équivalent d'AgileRennes et AgileNantes qui rayonnerait sur Vannes et Lorient. Je lance donc un appel à toute personne intéressée pour nous aider à lancer cette communauté.

Et enfin, je présentais un atelier Scrum 59': 15 participants répartis en 3 équipes ont présenté leur vision du tourisme martien sur Terre après un sprint planning meeting et 2 itérations pour construire leur démonstration. Cet atelier est un classique Scrum, je ne sais plus ou j'en ai trouvé les sources, en tout cas, j'ai préparé un support en français, un peu amélioré avec des cartes pour chacun des rôles, que je partage ici.

Feed back Agile Tour Nantes et Paris

Un retour de mes étapes Agile Tour, d'abord Parisienne:

Une session d'introduction par Jérôme Barrand, auteur du livre, dont j'avais fait un retour il y a un an.

La session, un peu trop courte, était très intéressante, faisant le tour des approches agiles dans d'autres domaines que le SI, en particulier:

• Les options réelles pour la finance car les Agile Coach ont un atelier Real Options Space game, déjà joué aux XP Days Paris 2008
• La performance globale pour les managers et les chefs d'entreprise, car, à ce titre, l'auteur propose une nouvelle charte managériale : la charte agilité.

La présentation sur Crystal, l'approche méthodologique d'Alistair Cockburn, m'a donné envie de creuser cette méthode de part sa vision plus large que Scrum ou XP, plus organisationnelle et philosophique, même si je trouve dommage d'en apprendre si peu au cours d'une session.

J'ai également vu la présentation d'Oana sur le profil d'un Coach Agile, intéressante sur son approche: parcourir des pratiques de développeur et les projeter au-delà pour l'équipe et le projet, par exemple qu'est-ce qu'un projet TDD, que veut dire binômer au-delà du code, ...
Cela va bien avec ma lecture du moment d'ailleurs.

J'ai également retenu sa métaphore sur les niveaux d'adoption Shu-Ha-Ri avec la musique: faire ses gammes apprendre le solfège, puis interpréter une musique voir improviser, et enfin composer soi-même. Le dernier niveau est donc celui ou l'on est en apprentissage réciproque entre le coach et l'équipe. Si votre Scrum Master ne vous laisse pas cette place, tuez-le! C'est ce que j'ai également retenu de la présentation
de Dominic Williams avec un Kill the buddha pour atteindre la libération!

Mais là, on est déjà reparti sur l'étape Nantaise:

Donc il ne faut pas rater la présentation de Dominic sur le développement Hédoniste, présentation inspirante, qui aborde les notions philosophiques de matérialisme, jardin d'Epicure, Dieu et Plaisir pour donner un éclairage un peu différend sur l'agilité. Cette session m'a rappelé que le courage est une des valeurs XP, car il en faut pour faire une présentation de philo d'1h30 à un parterre de développeurs ou managers.

Pour ma part, j'ai fait un XP Game à Nantes avec une quinzaine de participants après une introduction à l'Agilité en moins d'1/4 heure et un atelier l'Art de la rétrospective à Paris avec près d'une quarantaine de personnes.

Prochaine étape Bordeaux!

Feed back Agile Tour Rennes

Comme je l'annonçais, Agile Tour Rennes est fini, avec un bon feed back sur cette première étape Rennaise:

200 participants dont 150 professionnels et le reste d'étudiants de l'IFSIC. 60 questionnaires de satisfaction nous ont permis de dresser le bilan suivant:

à l'unanimité (-1):

• recommandent l'évènement


• ont envie de revenir l'année prochaine


• ont trouvé le niveau général adapté

Pour ce qui est de la satisfaction de 5 à 1 (oui-moyennement-non) :

• Accueil : 4,9


• Organisation générale : 4,8


• Communication : 4,6


• Date : 4,8


• Cadre universitaire : 4,8


• salles : 4,3


• pauses : 4,8


• buffet : 4,8

Les participants sont principalement venus pour approfondir leur connaissance autour de l'agilité mais également découvrir (1/3) et pour les contacts professionnels.

Vous êtes globalement prêt à participer financièrement en retour de plus de confort (repas, groupes réduits, présentations fournies, ...).

Concernant le contenu des présentations, ce qui a manqué le plus ce sont des retours clients, plus difficiles à capter; Il est à noter une légère frustration sur les 3 sessions en parallèle: il n'est effectivement pas possible de tout voir! Mais nous allons remédier à cela en proposant les sessions les plus plébiscitées au forum Grafotech Agile de Granit en début d'année 2010.

En parlant de session plébiscitée, ce sont les présentations qui sont le plus appréciées puis les retours d'expérience et enfin les ateliers: Il y a un effet de maturité sur les évènements agiles sur Rennes (par rapport à ce que je peux voir à Paris, Londres, ...).

Vous pouvez retrouver les photos de la journée sur agiletour-rennes.

Les prochaines sessions sur l'agilité

Pour ne rien rater cet automne...

Retrouvez-moi à

• Agile Tour Nantes, le 14 octobre, pour une introduction à l'Agilité et un XP Game.
• Agile Tour Paris, le 15 octobre, pour un atelier sur l'Art de la rétrospective.
• Journée Outils & Méthodologie pour le développement logiciel à Vannes, le 22 Octobre organisée par la MEITO, pour un atelier Scrum 59' et une table ronde.
• Agile Tour Bordeaux, le 29 octobre, pour une session sur le management visuel.
• Forum Grafotech Agile de Granit, pour un atelier sur le management visuel
• XP Days Benelux, le 23-24 Novembre à Mechelen en Belgique, pour un atelier sur le management visuel, Visual Management for Agile Teams, que j'anime avec Xavier Quesada Allue, un coach agile indépendant auteur du blog Visual Management.

Retrouvez également d'autres sessions sur Rennes avec

• AgileRennes, une session à blanc sur le Domain Driven Development, le 3 décembre, à suivre sur le groupe AgileRennes par Guillaume Collic
• Forum Grafotech Agile, avec Laurent Bossavit et une session inédite sur l'Agilité *Avant* le projet, le 17 décembre, inscription et informations sur le site Granit

Agile Tour Rennes & session Management Visuel

Agile Tour Rennes est fini, autour de 200 participants sur la journée, une organisation impeccable, beaucoup de retours tous très positifs.

C'est une grande satisfaction en tant qu'organisateur même si en tant que participant je suis arrivé trop fatigué pour en profiter.

J'attend le retour des questionnaires de satisfaction et la synthèse de la rétrospective faite à chaud avec les participants pour faire un retour sur la journée.

Mais Agile Tour Rennes, c'était également pour moi ma session sur le Management Visuel: près d'une centaine de participants dans le grand Amphi de l'IFSIC avec un excellent retour:

un ROTI de la session de 4.6 (sur 5) et un ROTI d'apprentissage de 4.5 (toujours sur 5). Le support de la session est en ligne ainsi que le résumé de la session. Elle dure 1h30 avec 1/4 d'heure pour les échanges et le feed-back (ROTI, matrice d'apprentissage, jeu de la perfection) qui me permet d'améliorer cette conférence à chaque session.

J'ai eu plusieurs types de remarques intéressantes auxquelles je donne un élément de réponse personnel:

Avoir des exemples concrets
J'ai pris le partie de banaliser les tableaux de tâches dans ma présentation pour être plus visuel et également faire passer le message que ce sont des outils contextuels: mais cela n'aide pas à se raccrocher à son contexte professionnel. Les participants attendent des réponses concrètes sur des problèmes concrets : granularités des tâches, gestion des anomalies, ... avec ces outils.
Pour la granularité des tâches, la réponse dépend de l'approche et je renvois plutôt aux différents livres, des user stories, aux use case et Minimum Marketable Feature (MMF):

Pour la gestion des anomalies, le principe est simple: tout ce qui est fait doit être visible, mais nous ne traitons pas les informations de la même manière s'il s'agit d'anomalies dont la correction est non planifiée (patch urgent pour anomalies bloquantes par exemple) de celles qui sont planifiées dans une release. Les premières seront traitées dans une ligne à part de mon tableau, à la manière de xavier. Les secondes doivent être priorisées comme un élément du product backlog.

Creuser les rétrospectives

Là je conseille sans hésiter le livre qui m'a énormément apporté, mais je pourrais ajouter la session de l'Alchimiste Agile que je donne à Agile Tour Paris la semaine prochaine :o)

Creuser le Lean/Kanban en tant que méthodes

Ca fera peut être l'objet d'autres sessions...

Avoir plus de contexte

Identifier les facteurs de succès, les risques, les limites, ou mieux, avoir une typologie de projet/organisation/équipe ou ces outils sont pertinents. Cette question est difficile car en soi ces outils sont simples mais impactants en ce sens qu'ils favorisent la responsabilisation et l'auto-organisation de l'équipe. Les éléments de réponse que je donne sont issus de mon propre retour d'expérience sur le sujet, donc non exhaustifs:

Facteurs de succès

• Un sponsor top management et un management de type leadership
• Un coach agile externe car il sera neutre et sans a priori (sur l'organisation, les gens, ...)
• Une équipe colocalisée

Il faut également réunir les conditions comportementales pour une équipe autonome, soit:

1. Situation maitrisée
2. Motivation
3. Compétence

Facteurs d'échecs

Un chef de projet ou un management ayant peur de perdre le contrôle ou le pouvoir car l'on favorise l'auto organisation, c'est particulièrement vrai pour le management de type directif. Si cela est identifié, du coaching individuel (par un autre intervenant que le coach agile évidement) peut être envisagé pour évoluer vers du leadership.

Une équipe avec une forte habitude de l'encadrement directif, une culture d'entreprise avec fiche de poste ou à responsabilité limitée, ou encore des individus qui viennent faire un travail alimentaire: Dans ces cas, il faut accompagner le changement.

Les risques
C'est le rejet ou l'abandon de ces outils après un premier essai: cela peut arriver si l'équipe n'a pas la culture de l'expérimentation et ne fait pas vivre l'outil pour coller à ses besoins ou contraintes de l'équipe/projet.

Cela peut également arriver après un vrai travail de sape des opposants à ces approches : en effet, c'est impliquant, la visibilité et l'engagement que cela demande peut en bloquer certains.

En conséquence, cela peut entrainer une certaine frustration de l'agent du changement. Un coach agile externe est alors mieux placer car il repart, dans ce cas, avec cet échec et l'équipe peut revenir sans tension à son approche traditionnelle.

Les limites

Les équipes distribuées géographiquement, surtout lorsque les tâches sont dépendantes ou si les équipes sont fortement spécialisées, sinon on peut se retourner vers une approche Scrum de Scrums. Bien sur il existe des outils numériques "agiles" pour piloter de tels projets, mais on perd le bénéfice du management visuel à les utiliser.

Les intervenants du management visuel

Comment convaincre les managers d'utiliser ces outils? la réponse, on l'a vue précédemment, va dépendre du type de management pratiqué. Convaincre des décideurs sera plus facile si le management visuel répond à des problèmes identifiés, visibles ou des axes d'amélioration. Cela peut donc commencer par une rétrospective.

Comment suivre ou impliquer les gens au niveau individuel? Le coach agile est un coach d'équipe. Il se concentre sur la vue équipe/projet. Rendre visuel la performance individuelle serait une erreur. Et surtout c'est le travail des RH ou des managers et non celui du Scrummaster. Et puis pour quel objectif? Une part variable, une augmentation? Il y a beaucoup de débats autour de cette question car elle créée un porte à faux entre la con,stitution d'une équipe et l'évolution individuelle, point abordé notamment par le Lean.

Malgré tout, Portia propose un exercice d'évaluation personnel à l'agilité qui peut servir de point de départ à cette réflexion.

Comment impliquer ou intégrer le client à cette approche? Pour un projet XP avec client sur site ou Scrum avec un Product Owner disponible, ils sont impliqués de fait au management visuel. En dehors de ces cas, on peut se servir de la visibilité apportée par les méthodes agiles pour impliquer le client avec un reporting quotidien en communiquant les dashboards projet par exemple.

Les outils

Eternelle question sur le management visuel : quel outil numérique pour virtualiser le management visuel? les post-it c'est pas green! Dubitatif au départ, il faut creuser la question pour y répondre: Un outil, pourquoi pas, mais pour quel besoin?

Pour une équipe mono site, le besoin pourrait être le calcul du reste à faire pour des backlogs avec un gros volume de tâches, donc peut être plus orienté Kanban que Scrum. Dans ce cas, le besoin est plutôt l'automatisation de tâches de consolidation des données d'un référentiel (couverture de code pour les tests unitaires, référentiel de code pour de la migration, référentiel de tests pour de la recette, ...). Donc des outils pour automatiser les valeurs à afficher et non le rendu.

Pour une équipe multi sites, encore une fois, les outils numériques de pilotage de projet agile, il en existe plusieurs, mais on perd l'intérêt du management visuel, ou alors avec un écran géant tactile pour manipuler les post its virtuels partagés par tous les sites, rêvons un peu... Il n'y a rien de satisfaisant dans ce contexte ni en approche agile ni en approche traditionnelle.

Faire du reporting numérique (plus que des photos du dashboard), c'est communiquer des informations projets consolidées, comme un burn down de release, ce n'est pas exactement la même granularité d'informations que les outils du quotidien, comme un burn down de sprint. Sur mes gros projets, j'ai l'aide d'un PMO pour cette activité. Je préfère un surcout pour la consolidation plutôt que de tenir une double comptabilité quotidienne (radiateur d'information- outils numérique).

Capitaliser au niveau entreprise

* les pratiques, les bons indicateurs à suivre, c'est l'objet des rétrospectives d'itération ou post-mortem. Pour capitaliser ou plutôt capter le management visuel ou la facilitation des réunions, des photos ou vidéo suffisent. La question est peut être quel outil de capitalisation ou comment capitaliser: le CMMI peut dans ce cas apporter des réponses ou des bonnes pratiques.

* les métriques, les estimations, les vélocités sont des indicateurs propres à une équipe: les estimations sont relatives, la vélocité dépend de la stabilité, la maturité de l'équipe et du projet. La fiabilité des estimations d'ailleurs doivent s'affiner avec l'avancement du projet et une pratique régulière des planning game. Si on veut ou doit aller plus loin, par exemple pour du CMMI, pour une analyse statistique avec l'estimation initiale vs le consommé réel, je pense qu'il faut dé corréler les outils: faire un suivi électronique de ces informations valorisées par chaque membre de l'équipe et rester à du reste à faire pour le visuel.

Je mettrais en ligne une version mise à jour de mon support après ma session à l'étape Bordelaise d'Agile Tour, le 29 Octobre.

Prochaines sessions de formations agiles sur Rennes et Nantes

Atelier Management Visuel

Lorsque je préparais ma session sur le management visuel [1] pour Agile Tour, le blog de Xavier Quesada m'a particulièrement inspiré. Je trouve ce qu'il fait réussi, pertinent et intéressante la manière dont il en parle.

Il propose également un atelier sur ce thème qui me semblait complémentaire au format conférence que j'avais adopté; Vous pouvez lire le compte rendu de sa dernière session à Agile 2009 à Chicago.

J'ai donc pris contact avec lui pour faire cet atelier, Visual Management for Agile Teams, ensemble lors des XP Days Benelux en novembre.

Pour préparer cet atelier, Nous avons un premier essai lors de la dernière session CSM d'Agilbee à Rennes, avec une dizaine de participants:



L'objectif de cet atelier exploratoire est de construire un Scrum board qui répond à un certain nombre d'exigences, des plus simples - le tableau doit montrer qui travail sur quoi, aux plus subtiles telles que les gestions de dépendances. Le tableau est construit par équipe en deux itérations avec des revues entre les itérations.

Normalement, quelques slides sont déroulées en guise d'introduction avec quelques photos de Scrumboard qui ont certainement une influence sur le résultat de l'atelier. J'ai décidé de ne rien montrer pour avoir un résultat brut pour cette première... La prochaine fois, je ferais l'introduction!

Equipe bleue

Le tableau ne répond pas à toutes les exigences, telles que le product backlog visible mais il est assez aéré. Les deux équipes ont fait le choix d'avoir des postits de couleurs différentes par histoire utilisateur et des gommettes de couleurs pour suivre le travail de chacun.

Pour le premier, cela fait bien ressortir les histoires utilisateurs mais apporte de la confusion sur les codes couleurs. Cela pourrait être intéressant dans le cas de Kanban board avec des lignes fonctionnelles plus macro et plus stable dans le temps.

Pour les gommettes, c'est simple, ça marche pour les petites équipes. Pour les équipes plus nombreuses, on est vite à court de couleurs et on doit plutôt utiliser les Nametags. Ceux-ci ont un autre intérêt, celui de limiter le travail en cours en limitant par exemple deux nametags par personne.

Les nouvelles exigences se sont plutôt traduites par des éléments supplémentaires, gommettes, couleurs, post-its, ce qui en complique la lecture: une légende a été nécessaire.

Equipe Rouge

Les nouvelles exigences de la seconde itération ont amené une part de refactoring du tableau avec l'ajout de deux colonnes supplémentaires: Finished Today et Test.

La seconde est classique, surtout lorsque l'on a une spécialisation dans l'équipe, développeur/testeur par exemple. La première l'est beaucoup moins: l'exigence consiste à montrer ce qui a été réalisé dans la journée. On peut se demander à quoi sert cette exigence puisque l'on a une colonne "Done" pour visualiser cela: Déplacer son post-it lorsque l'on a fini une tâche est une mini célébration, bon pour le moral, difficile d'attendre le lendemain pour le faire. Mais alors l'information se perd le lendemain lors de la mêlée et surtout il est plus délicat de mettre à jour le sprint burndown chart. Ce petit exercice anodin fait ressortir les mauvaises pratiques d'équipe telles que faire ce graph sur la base du reste à faire plutôt que sur les tâches finies.

Une idée intéressante est remontée avec la liste des obstacles: On attribue un indice à chaque obstacle. Les tâches impactées par cet obstacle ont un tag (postit ou gommette) sur lequel on reporte l'indice.

les objectifs d'un bon tableau visuel sont remplis si :

• L'équipe se sert effectivement du tableau, notamment pendant la mêlée
• Votre chef est fier de le montrer à son chef
• Une personne qui le découvre peut le comprendre sans explication
• Il change avec les besoins ou les contraintes du projet
• Les managers ou décideurs s'arrêtent pour le regarder, avec intérêt et curiosité
• Vous le trouvez beau

Pascal a fait récemment un post intéressant, sur son blog Thinking for a change, sur le sujet qui recentre la valeur qu'apporte ces outils de contrôles visuels, notamment par rapport à la nécessité d'actions qu'ils portent:

* Arrêtez de visualiser si vous ne voulez ou ne pouvez pas faire d'action.
* Avant de faire une action rendez visible le problème et ses objectifs.

Je ne serais pas si catégorique et je parlerais plutôt du besoin ou de la nécessité d'avoir un feed-back rapide, ce qui génère ensuite des actions.

---

[1] Prochaines sessions Management visuel:

• Rennes, le 1er octobre 2009
• Bordeaux, le 29 octobre 2009