VENEZ A L'AGILE TOUR A VALENCE

Venez nombreux à Valence assister aux conférences et participer aux ateliers de l'Agile Tour 2009.

L'évènement aura lieu le Jeudi 22 Octobre 2009 dans les locaux de l'IUT de Valence, de 13h à 18h.
Comme l'année précédente, l'évènement est gratuit et sera suivi d'un apéritif.

Cet évènement est la deuxième édition de la conférence itinérante sur les méthodes Agiles (eXtremeProgramming, Scrum, Lean ...). En 2008, l'évènement a rassemblé à Valence 120 participants, professionnels, enseignants et étudiants représentant les principaux industriels, sociétés de services en informatique et écoles de la région.

En particulier cette année, si vous êtes intéressés par le Lean, l'eXtreme Programming, le pilotage par les tests (TDD), la contractualisation des forfaits agiles, le management agile ou le CMMi, venez nous rejoindre le Jeudi 22 Octobre après-midi.

Pour faciliter l'organisation, l'inscription est obligatoire en remplissant le formulaire ici. Pour toute question, n'hésitez pas à nous contacter par mail.
A très bientôt!

LEAN, LA CULTURE

A travers 5 billets, nous avons balayé un jeu de pratiques de développement logiciel permettant d'implémenter les 5 piliers du Lean:

• la définition de la valeur,
• la cartographie du flux de création de valeur,
• le flux continu de création de valeur,
• le flux tiré de création de valeur et
• le perfectionnement.

A travers d'autres billets nous avons vu encore d'autres pratiques toujours relatives au Lean contribuant:

• au jidoka,
• au Stop The Line,
• au poka-yoke et
• aux 5S.

Une pratique quotidienne de ces outils et une attitude d'amélioration continue de tous les les jours ne suffit malheureusement pas pour devenir une organisation Lean. Au mieux, cela développe des îlots Lean.

Attention, c'est déjà beaucoup! Mais il est possible d'aller beaucoup plus loin si on relie ces îlots, si on leur donne du sens et si on assure une continuité par une culture d'entreprise appropriée.

Pour assurer la continuité des pratiques et réellement promouvoir l'amélioration continue, il faut une culture d'entreprise qui exige la prise de décision en se basant sur des objectifs à long terme. Le pilotage au jour le jour et au gré des tempêtes ne donne pas le temps de progresser par la pratique.

Pour donner du sens à ces pratiques et pour justifier leur adoption, il faut une culture d'entreprise connue des équipes. Les pratiques et l'attitude qui va avec sont d'autant plus facilement adoptées si les équipes comprennent en quoi cela sert leurs clients, leur entreprise et leur développement personnel.

Pour qu'une telle culture d'entreprise soit connue des équipes, il faut qu'elle soit enseignée. Il est de la responsabilité des managers d'être des leaders qui pratiquent et enseignent la culture à leurs équipes. Pour cela, ces leaders doivent être sur le terrain, connaître le métier et enseigner le métier par l'exemple en se référant à la culture d'entreprise qui justifie la manière de le pratiquer. Dans une telle dynamique, les leaders deviennent des praticiens de la résolution systématique des problèmes pour aider leurs équipes à devenir plus productives et les aider à tenir leurs objectifs.

Alors, avec des pratiques solidement enracinées dans une culture d'entreprise, elle-même enseignée par des leaders praticiens, il devient envisageable de relier les îlots Lean pour développer une organisation Lean.

ET MAINTENANT?

Au boulot!

LEAN, LA PERFECTION

Après la définition de la valeur, la cartographie du flux de création de valeur, le flux continu de création de valeur, et le flux tiré de création de valeur, le dernier pilier du Lean est la perfection.

DE QUOI S'AGIT-IL?

Il s'agit de l'amélioration continue des pratiques de travail par la résolution systématique des problèmes.
Utiliser le mot perfection pour nommer ce dernier pilier est maladroit. En effet, la perfection n'est jamais atteinte et il est toujours possible d'améliorer. Plutôt que perfection, il vaudrait peut être mieux parler de perfectionnement.

QUELLES PRATIQUES?

Je trouve qu'il s'agit du principe le plus difficile à transformer en pratiques de travail. La lecture de The Toyota Way m'a fait réaliser que j'avais largement sous estimé l'implémentation de ce principe. Voici où nous en sommes:

Les rétrospectives

Chaque itération d'un mois se termine par une réunion en équipe complète appelée rétrospective. En se basant sur des métriques, des faits marquants et des impressions, les équipiers identifient les principaux problèmes rencontrées dans l'itération et cherchent des contre mesures à expérimenter dans la prochaine itération pour les résoudre. Ce travail périodique permet de régulièrement prendre du recul sur notre manière de travailler pour s'améliorer.

Notre pratique de la rétrospective d'itération contribue au perfectionnement des pratiques de travail, mais je ne pense pas qu'elle suffise. En effet, les problèmes identifiés tout au long de l'itération attendent la rétrospective pour être sérieusement évoqués en équipe. Ainsi, en attendant la rétrospective, l'équipe aura contourné ces problèmes en perdant en efficacité. Pire, certains des problèmes identifiés tôt dans l'itération auront empiré en attendant la rétrospective en fin d'itération. Les contre mesures demanderont alors plus d'effort. Pire encore, certains problèmes ne sont même pas traités en rétrospective car l'équipe fatigue en fin d'itération (ne me parlez pas de rythme soutenable) ou certains problèmes semblent trop petits pour être traités à 20 équipiers. Dans ce cas, on ne peut réellement parler d'amélioration continue. Nous cherchons donc à compléter la rétrospective d'itération par une autre pratique, plus régulière.

La résolution systématique des problèmes

La lecture de The Toyota Way nous a conduit à expérimenter une approche systématique et structurée de résolution de problème. Nous parions que cette démarche nous permettra d'optimiser nos pratiques au quotidien et en continue en résolvant les problèmes de manière systématique dès qu'ils sont identifiés.
Nous sommes actuellement en train de construire notre pratique de travail. Pour le moment, les équipiers rédigent une fiche dès qu'ils identifient un problème. Cette fiche datée synthétise:

• la description du problème constaté;
• le résultat de la recherche de la cause racine du problème;
• autant de cycles Plan, Do, Check, Act qu'il en faut pour faire disparaitre ce problème et l'empêcher de se présenter à nouveau.

Lorsqu'un problème est résolu par cette approche structurée, sa fiche cartonnée est conservée car elle sera réutilisée et enrichie si jamais le problème revient malgré les contre mesures mis en place. Certaines fiches ressortiront plusieurs fois et révèleront les problèmes récurrents.
Puisque le management visuel sert à ne pas cacher les problèmes, les fiches cartonnées sont affichées sur un tableau baptisé "Problem Solving" (voir photo). Ainsi, n'importe quel équipier peut présenter les problèmes actuels à un manager.
En quelque sorte, cette pratique est au défaut de processus ce que le Stop The Line est au défaut de produit.

Cette démarche présente de nombreux avantages:

• elle contribue à entretenir une amélioration continue des pratiques de travail;
• elle contribue à créer un état d'esprit où les équipiers identifient les problèmes et arrêtent leur travail en cours pour les résoudre afin d'optimiser la création de valeur;
• elle donne des faits pour comprendre les difficultés rencontrées par l'équipe;
• elle rend visibles les problèmes de l'équipe;
  
• elle permet d'identifier les problèmes récurrents dont la résolution est stratégique pour la réussite du projet;
• elle implique les managers de manière constructive dans le travail de l'équipe puisque la résolution de certains problèmes est hors de portée de celle-ci;
  
• elle aide l'équipe à devenir une organisation qui apprend à mieux travailler.

Cette pratique est aussi très difficile à mettre en place. En effet, il faut développer l'état d'esprit de l'identification et de la résolution systématique de problèmes chez les équipiers (à commencer par soi-même!). Il s'agit d'une attention de tous les jours. Il faut aussi et surtout convaincre les managers qu'il est important d'arrêter le travail en cours pour résoudre les problèmes qui freinent la productivité ou réduisent la qualité. Cela peut s'avérer très difficile si les décisions n'ont pas l'habitude d'être prises en se basant sur des objectifs à long terme.

ET MAINTENANT?

Cette petite série de billets sur notre implémentation des 5 piliers du Lean est désormais close. Néanmoins, la pratique quotidienne des outils présentés dans ces 5 billets m'amène à en rédiger bientôt un 6ème. Il sera dédié à un atout qui me semble primordial pour devenir une organisation Lean: la culture d'entreprise.

LEAN ET 5S

Nous sommes nombreux dans l'équipe. Suffisamment pour nous être organisé en plusieurs sous-équipes, chacune avec son tableau "kanban" et son Daily Stand-Up Meeting.

Avec la croissance des l'équipe et la multiplication des sous-équipes, il est alors devenu difficile d'assister au Daily Stand-Up Meeting d'une sous-équipe. Où et quand a lieu la réunion de telle ou telle sous-équipe?

Nous avons résolu ce petit problème de la manière suivante. Sachant que chaque sous-équipe mène son Daily Stand-Up Meeting devant son tableau "kanban", nous avons étiqueté chacun d'eux.
Sur chaque tableau, des étiquettes indiquent le nom de la sous équipe, l'horaire de son Daily Stand-Up Meeting et les prénoms des équipiers devant intervenir lors de cette réunion.

Cette petite solution toute simple rentre parfaitement dans le cadre de la pratique des 5S.

INTEGRATION CONTINUE + ANDON = JIDOKA

Nous avons configuré notre outil d'intégration continue pour qu'il envoie un mail d'alerte à chaque équipier lorsqu'un build automatisé (compilation et tests) échoue. Notre priorité est alors de revenir au plus tôt à une situation nominale caractérisée par un build réussi.

Mais voilà, notre attention n'est pas concentrée sur notre messagerie. Nous avons beau être nombreux dans l'équipe, certains builds échoués restent non détectés plusieurs heures. Il arrive également qu'un build échoué soit détecté, mais qu'il ne soit pas corrigé dans l'heure. Alors les équipiers s'inquiètent car ils ne sont pas certains que quelqu'un soit en train de résoudre le problème.

De sa propre initiative, l'équipe a décidé de se mettre la pression. Elle a réfléchi à la solution la plus simple pour mettre en place un andon. Il s'agit d'un signal lumineux visible de tous qui signale une anomalie.

Un équipier a alors acheté un i-buddy pour le poste d'intégration continue. Lorsque le build incrémental et le build complet sont tous deux réussis, la tête de l' i-buddy est verte. Si un de ces deux builds échoue, la tête de l' i-buddy est rouge. Lorsqu'un build échoué est en réparation, le tête de l'i-buddy est bleue.
La loupiote est posée sur l'écran du poste d'intégration continue. Une légende explicative attachée à l'i-buddy rend l'interprétation de son signal lumineux évidente pour tous (application du 5S) .

Cette petite initiative a plusieurs avantages:

• un signal lumineux visible de tous signale clairement les problèmes de build;
• le signal lumineux rouge, visible de tous, motive les équipiers à rapidement corriger le problème détecté;
• le signae lumineux bleu rassure l'équipe sur le fait que des équipiers se chargent du problème détecté;
  
• c'est une petite pratique sympa dont l'équipe est fière. Elle soude ses membres en contribuant à son folklore.
  

Bref, intégration continue + i-buddy = jidoka

PS: Il est de bon ton se caser quelques mots en japonais comme andon et jidoka dans son billet ;o)

LEAN, LE FLUX TIRE DE CREATION DE VALEUR

Après les billets sur une pratique de la valeur, de la cartographie du flux de création de valeur, du flux continu de création de valeur, voici la suite qui porte sur le flux tiré de création de valeur (ou "pull").

Alors que le flux continu de création de valeur est en place, il s'agit désormais de laisser le client tirer la création de valeur selon son besoin.

A ce jour, nous pratiquons le flux tiré de création de valeur à 3 niveaux.

DÉVELOPPEMENT TIRE PAR PRIORITÉ

D'abord, au plus près du client final, les exigences à implémenter sont priorisées par le Product Owner dans le Product Backlog. La succession des itérations tire les exigences par ordre de priorité hors du Product Backlog pour les transformer en logiciel opérationnel. Ainsi, en accordant une priorité à ses exigences et en laissant l'équipe de développement mener un développement itératif et incrémental piloté par les priorités, le client final est en fait en train de tirer le développement de son produit.

Nous pouvons affirmer que le développement itératif et incrémental piloté par les priorités du client final est en fait un système "pull" pour le développement de produit.

IMPLÉMENTATION TIRÉE PAR KANBAN

A un niveau plus bas, lorsqu'une itération tire une exigence prioritaire hors du Product Backlog pour l'implémenter, toutes les activités à mener pour la transformer en logiciel opérationnel sont identifiées par la Value Stream Map et tirées par un Kanban. Une étiquette du Kanban représente une exigence à implémenter. Les colonnes du Kanban sont les activités sérialisées de la Value Stream Map. Les cases à cocher dessinées sur les étiquettes sont les activités parallèlisées de la Value Stream Map. La traversée du Kanban par les étiquettes existantes est prioritaire à l'entrée de nouvelles étiquettes sur le Kanban. Le Kanban est actualisé une fois par jour, en équipe et en temps limité, lors du Daily Stand-Up Meeting. (voir la pratique en vidéo)

CODAGE TIRE PAR TEST

A un niveau encore plus bas, la pratique des tests de recette et des tests développeur conformément au développement piloté par les tests (ou TDD) est un système "pull" pour l'activité de codage. En effet, des tests qui échouent sont implémentés en premier lieu. Puis, juste assez de codage est tiré pour faire passer ces tests avec succès. Nous pouvons afirmer que le Développement Piloté par les Tests (ou TDD) est en fait un système "pull" pour l'activité de codage.

Ainsi, le flux tiré de création de valeur est pratiqué à plusieurs niveaux. Cette manière d'organiser la chronologie des développements et des activités évite les gaspillages de la surproduction, des défauts cachés dans l'inventaire et du développement d'exigences non prioritaires.

Le prochain billet consacré au Lean portera sur la recherche de la Perfection. Nous aurons alors survolé une certaine implémentation des 5 piliers du Lean.

AGILITE AU SALON DU BOURGET

Nous avons eu la chance d'être invités au Salon du Bourget. Nous avons eu le plaisir d'y voir deux porteurs pour lesquels nous avons développé des logiciels de vol en appliquant les méthodes agiles.

Ces deux logiciels ont été livrés à temps et avec la qualité attendue. Très discrètement et pour certains initiés, les méthodes agiles étaient à l'honneur au Salon du Bourget!