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à.