Emmanuel CHENU

A VOS MARQUES, PRETS, PARTEZ!

2011-10-06T13:26:00.000-07:00

Nous démarrons une itération (nous ne les comptons plus!). Nous avons 2 types d'activités à réaliser en 16 jours, donc 2 value-stream-maps différents, donc 2 Kanbans différents (à gauche). Les tâches priorisées et estimées sont sur les colonnes de départ (TODO). Les jetons de ressources sont regroupés au milieu (en jaune). Nos 5 indicateurs de performance vierges sont affichés (à droite). Le standard décrivant l'utilisation du Kanban et des indicateurs de performance est également affiché (à l'extrême droite).
C'est parti!

ETRE BON

2011-09-18T02:17:00.000-07:00

A l'occasion du précédent billet, j'ai evoqué que mener son équipe impliquait (entre autres) de mettre les équipiers en difficulté pour qu'ils se développent.

Deux soirées passées avec mon coach officieux m'ont permis de travailler cet aspect du leadership.

Il est intéressant de demander à l'équipe ce que "être bon" signifie dans le cadre de leur activité: "Pour vous, qu'est ce que cela signifie d'être bon?" (petite mise en difficulté :o)

La première étape de cette réflexion amène à se rappeler de la raison d'être de l'équipe. Quelle est sa mission, quels sont ses objectifs? En quoi est-ce que l'équipe contribue à l'organisation? A cette étape, nous connaissons le but à atteindre.
Ensuite, il s'agit d'identifier les critères de réussite de l'équipe. Quels faits, quelles métriques, quels indicateurs permettent objectivement d'affirmer que les objectifs sont tenus? A cette étape, nous savons identifier si nous avons atteint le but.
Puis, il s'agit d'identifier où nous en sommes dans la poursuite des objectifs. Pour cela, il faut mesurer les résultats actuels et les comparer aux résultats cibles. A cette étape, nous savons identifier où nous en sommes par rapport au but.
Enfin, il "reste" à mesurer l'historique des résultats pour révéler la performance et la comparer à la performance cible. Cette étape permet à l'équipe de mesurer l'effet de l'amélioration continue de ses pratiques. A ce stade, nous savons estimer le moment où nous atteindrons le but.
A la question "qu'est ce cela signifie d'être bon?", on peut répondre objectivement en connaissance de cause, en s'appuyant sur des faits collectés par la démarche ci-dessus. C'est pour cela que les résultats de la démarche ci-dessus sont visuels, affichés, à jour et commentés. Ainsi, à l'aide d'un affichage visuel, on peut synthétiquement désigner et chiffrer l'objectif, montrer le résultat actuel, la tendance, l'estimation d'atteinte de l'objectif et présenter les actions en cours pour améliorer la performance.

Si l'équipe est en mesure de répondre ainsi à la question "qu'est ce cela signifie d'être bon?", c'est qu'elle pilote son activité. Cela révèle aussi qu'il faut la remettre en difficulté pour qu'elle se développe encore! En attendant, il reste du travail: la mise en pratique n'est pas encore au point :o)

MENER SON EQUIPE

2011-07-10T05:59:00.000-07:00

Après plus de 5 ans de pratique des démarches agiles et lean, ma pratique du rôle de scrummaster a largement évoluée pour s'éloigner de sa définition initiale.

A une phase tournante de mon engagement sur mon projet actuel, j'en profite pour faire un point sur le rôle initial de scrummaster et ce qu'il est devenu après plus d'une vingtaine d'itérations mensuelles. Cette évolution me semble si significative que le rôle strict de scrummaster me parait désormais sous-optimal.

SCRUMMASTER

Selon les fondateurs de Scrum, le scrummaster se doit de

retirer les obstacles qui gênent l'équipe dans sa poursuite des objectifs d'itération;
agir comme un tampon entre l'équipe et les influences perturbatrices;
se mobiliser pour que la démarche Scrum soit mise en pratique conformément à sa définition;
garder l'équipe concentrée sur les objectifs d'itération et les tâches en cours;

GESTIONNAIRE

Le rôle de scrummaster est bien loin du gestionnaire d'équipe (alias manager) qui pratique souvent un pilotage solitaire et analytique sur la base de métriques et d'indicateurs. Le manager gère des ressources sans forcement avoir recours à la pratique du leadership.

MENEUR

Le rôle de scrummaster s'apparente d'avantage à celui du meneur d'équipe (alias leader) même s'il n'en prend pas toute la force. En effet, le scrummaster est souvent présenté comme un facilitateur ou un animateur recherchant à tout prix le consensus au sein du projet. Ce rôle mou et peu engagé à mon avis n'est pas encore celui du meneur d'équipe.

Le meneur d'équipe mène son équipe (pléonasme).

S'ENGAGER

Mener son équipe c'est s'engager avec elle dans la poursuite de ses objectifs. Que cela soit bien clair: le leader échoue si l'équipe échoue. Le leader est bien dans la même barque que ses équipiers. Le leader doit donc contribuer à la poursuite des objectifs de son équipe. Il doit mettre ses compétences et son action au service de la réussite des équipiers.

Quelles sont ces compétences et cette action?

MONTRER L'EXEMPLE

Le meneur d'équipe doit montrer l'exemple. Il ne s'agit pas de dire ce qu'il faut faire, mais de montrer ce qu'il faut faire. Pour cela, il faut faire! On y revient encore: le leader est dans l'action. Il doit pratiquer pour montrer la voie à suivre. (Que penser du scrummaster facilitateur et non développeur?)

PRATIQUER

Un leader ne peut exiger de ses équipiers un comportement que lui-même n'a pas. Si le leader exige de ses équipiers que leur code soit testé, sans duplication, explicite et le plus court possible, alors lui-même se doit d'écrire du code testé, sans duplication, explicite et le plus court possible (j'en imagine certains qui sourient et d'autres qui grincent des dents). C'est à ce prix que le leader sera légitime et que ses équipiers accepteront de mettre en pratique les standards.

Ainsi, mener l'équipe c'est ouvrir la voie pour que l'équipe la prenne à sa suite.

ENSEIGNER

Il ne suffit pas au leader de pratiquer pour montrer la voie, puis d'exiger de ses équipiers qu'ils suivent cette voie. Le leader doit absolument enseigner le métier. Il doit enseigner

la pratique en expliquant comment nous travaillons dans l'équipe (quels sont les standards?).
la philosophie en expliquant pourquoi nous travaillons de cette manière dans l'équipe. L'enseignement de la philosophie est primordial car nous pratiquons de manière d'autant plus efficace que nous comprenons pourquoi nous pratiquons ainsi. L'objectif est de faire adhérer aux pratiques. Aussi (et surtout!), comprendre pourquoi est un pré-requis pour améliorer les pratiques.

Le pair-programming est une manière très pertinente d'organiser l'enseignement. Dans un tel cadre, le leader doit binômer et il doit s'assurer que les anciens binôment.

Petit rappel pour le plaisir: Pour enseigner il faut pratiquer.

FAIRE REUSSIR

L'objectif du meneur est de faire réussir ses équipiers. Une manière d'y parvenir est de mener les équipiers à l'autonomie, de les pousser à se perfectionner et à donner du sens à leur travail.

MENER A L'AUTONOMIE

L'autonomie a un impact positif sur la motivation, l'efficacité et l'engagement. Le leader se doit de pousser les équipiers à devenir autonomes.

Par exemple, il s'agit de ne pas de donner la solution à un problème posé, mais de mettre sur la voie, d'accorder du temps pour traiter le problème, puis de s'assurer que le problème est en cours de résolution.

Le meneur d'équipe doit pousser ses équipiers à le remplacer. Ainsi, les plus anciens participent à former les plus jeunes; chacun pilote un chantier de résolution de problème (et donc d'amélioration!); les daily-stand-up-meetings, planifications et rétrospectives peuvent être préparés et animés de manière tournante, etc.

Il est important d'organiser le travail pour que les équipiers puissent décider par eux-même de leurs activités. Les backlogs (priorisés par définition!), les faits techniques priorisés, les kanbans et taskboards, les standards et modes opératoires, les indicateurs visuels de pilotage, les andons sont des outils d'aide à la décision dont la bonne utilisation engendre l'autonomie.

En matière d'autonomie, les objectifs du leader peuvent être les suivants:

s'il s'absente, l'équipe assure l'intérim;
s'il quitte l'équipe, un équipier peut prendre son rôle;
les équipiers identifient les tâches à mener;
un équipier motivé peut mener une autre équipe.

CONDUIRE LE PERFECTIONNEMENT

Le leader doit pousser ses équipiers à se perfectionner. Des équipiers performants résolvent les problèmes et établissent des standards efficaces qui permettent de bien développer de bons produits. Le perfectionnement est également une grande source de motivation personnelle.

La mise en situation, le pair-programming et la résolution de problèmes sont des outils efficaces pour aider les équipiers à se perfectionner. Le leader peut utiliser ces moyens pour entretenir un rythme de perfectionnement.

DONNER DU SENS

Le leader doit expliquer aux équipiers quels sont les bénéfices pour l'entreprise, pour les clients, pour leurs collègues et pour eux-mêmes de leur travail et de leur manière de travailler. La conscience des bénéfices de son travail impact positivement la motivation et l'engagement.

CONDUIRE LA RESOLUTION DES PROBLEMES

Le scrummaster doit retirer les obstacles qui gênent l'équipe dans la poursuite de ses objectifs. En résolvant lui-même ces problèmes, le scrummaster ne mène pas ses équipiers à l'autonomie et il ne conduit pas leur perfectionnement. Lui seul développera ses compétences.

C'est pourquoi le meneur d'équipe doit conduire la résolution des problèmes. Il s'agit

d'enseigner une démarche structurée de résolution de problème;
d'expliquer en quoi cette pratique développe les compétences des équipiers;
d'expliquer en quoi cette pratique améliore la performance de l'entreprise; puis
d'allouer les chantiers dans l'équipe (ou de s'assurer que les équipiers s'allouent des problèmes à résoudre); et
d'animer ou suivre l'avancement des chantiers de résolution de problèmes.

Pour montrer l'exemple et pour développer ses propres compétences, le leader se doit de mener lui-même des chantiers de résolution de problèmes.

La pratique en continue de la résolution de problèmes est un outil très performant pour développer les compétences. En effet, elle exige des équipiers qu'ils comprennent en profondeur les problèmes (avec symptômes, impacts et causes racines) et qu'ils identifient et mettent en place des contremesures efficaces.

AMELIORER LES PRATIQUES

La pratique en continue de la résolution de problème est également un outil très performant pour améliorer les pratiques (ou standards) de l'entreprise. En effet, ces chantiers font évoluer les standards pour intégrer les contremesures identifées.

Donc, là encore, le leader doit conduire la résolution de problèmes. Il doit tout particulièrement s'assurer que les équipiers enrichissent les standards avec les enseignements de leur chantiers.

RECHERCHER LE CONSENSUS

Bien sur, le meneur d'équipe doit en priorité rechercher le consensus au sein de l'équipe. L'adhésion aux décisions sera d'autant plus aisée.

Par contre, par moment, le consensus ne sera pas obtenu et c'est normal. Si je finançais mon projet avec mon argent propre, je ne laisserai pas les experts et les anciens ramer pour obtenir un consensus alors que leur expérience leur révèle la solution. Le prix d'un expert et d'un ancien est le prix de son expérience. Il se doit d'utiliser son expérience pour empêcher les plus novices de commettre les mêmes erreurs. Certes, nous apprenons par nos erreurs, mais si nous pouvions éviter d'en faire trop, ce serait tout même préférable pour le projet. Dans un tel cas de figure, une solution issue de l'expérience et imposée sans consensus doit être expliquée afin de rechercher au mieux l'adhésion des équipiers.

ET RECURSIVEMENT

Tout ce qui a été dit pour le meneur d'équipe me semble également valable pour le meneur de l'équipe des meneurs d'équipes. Et ainsi de suite ...

A méditer!

RÉSOUDRE LES PROBLÈMES UN A UN POUR AMÉLIORER LES PRATIQUES

2011-01-22T04:43:00.000-08:00

Lorsque nous abordions le Lean pour le mettre en pratique sur nos projets de développement, nous l'abordions selon les axes suivants:

Cette approche, très centrée sur le process, nous a amené à reprendre des outils issus du Lean qui ont été efficaces chez d'autres et à les mettre en oeuvre chez nous: value stream mapping, kanban, just in time, autonomation, jidoka, andon, etc ...

Cette démarche s'est greffée sur notre déjà longue pratique du développement logiciel agile, centrée sur l'eXtreme-Programming (d'abord!) et Scrum (pour la forme). Naturellement, le terrain de rencontre de ces deux démarches a été le Lean Software Development.

Nous sommes fiers d'avoir obtenus de très bons résultats sur de gros projets, dans des domaines à priori peu réceptifs à ces pratiques et d'avoir été félicités par nos clients pour la tenue des jalons, la qualité des produits et notre transparence.

Pourtant nous traînons encore des problèmes de longue date (en terme d'années!) qui nous ralentissent, réduisent notre performance et attaquent notre moral.

Comment cela est-il possible alors que nous pratiquons un développement logiciel agile et Lean qui a lentement évolué pour s'adapter à notre domaine? Sommes-nous réellement sur la bonne voie?

Des aides extérieures et des recherches nous ont permis de prendre conscience que nous pratiquions un Lean scolaire. Cette pratique consiste à enrichir notre démarche issue de l'eXtreme-Programming et de Scrum avec des outils du Lean qui ont fait leurs preuves, sans pour autant assimiler le coeur du Lean.

Depuis, nous essayons d'aborder le Lean de la manière suivante:

visualiser le production pour révéler les problèmes,
réagir immédiatement,
puis résoudre les problèmes un à un
pour améliorer les pratiques.

Nos précédentes initiatives nous ont déjà conduit à "visualiser la production pour révéler les problèmes et réagir immédiatement". Nous continuons à peaufiner cette pratique. Par contre, nous essayons désormais de sérieusement nous attaquer au pan du Lean que nous avons trop négligé, c'est à dire résoudre les problèmes un à un pour améliorer les pratiques.

Attention, il ne s'agit pas là de la rétrospective d'itération ou de la collecte des obstacles par le ScrumMaster lors des réunions quotidiennes dans l'objectif d'aplanir la route devant l'équipe!

Il s'agit d'une discipline de tous les jours, pour tous, à tous les niveaux, qui consiste à avoir toujours un problème à résoudre. Ce problème doit être analysé, décortiqué et compris pour être éventuellement résolu si le retour sur investissement le justifie.

Pour les problèmes coriaces, la démarche est structurée. Par exemple pour nous, cela consiste à suivre les étapes suivantes:

décrire le problème tel qu'on le perçoit;
identifier et quantifier les impacts du problème pour notre client et pour notre organisation;
décrire comment les choses devraient se dérouler, puis décrire comment elles se déroulent réellement. Décrire l'écart entre les deux.
identifier les causes racines du problème et pondérer leur impact sur le problème;
pour chaque cause racine, identifier des solutions candidates qui l'élimineraient;
classifier les solutions candidates en fonction de leur coût de mise en oeuvre et de leur impact sur la résolution du problème;
mettre en oeuvre les solutions par retour sur investissement décroissant jusqu'à ce que le retour sur investissement n'en vaille plus la peine;
si elles ont été efficaces, standardiser les nouvelles pratiques mise en oeuvre;
communiquer les leçons.

Cette discipline individuelle et d'équipe nous aide en ce moment à résoudre (entre autres) un problème que nous traînons depuis un an. Pour la première fois depuis longtemps, nous constatons une réelle amélioration du phénomène et ce pour un très faible investissement. Ceci nous ouvre de belles perspectives d'amélioration!

Le plus motivant à mon avis est que cette discipline est une école d'experts. En effet, puisqu'elle exige de passer par une profonde et complète compréhension des problèmes, elle pousse les acteurs de la démarche à développer leur expertise. Même si la résolution du problème n'est pas déclenchée par manque de retour sur investissement, les acteurs sauront ne pas commettre la même erreur à la prochaine occasion. Puisque tous sont concernés par cette discipline, tous sont amenés à développer leurs compétences.

Finalement, il se s'agit pas plus d'appliquer "un bon processus qui fait un bon produit" mais plutôt "d'appliquer une démarche qui développe des experts qui sauront mettre au point un bon processus qui fait un bon produit" (vous me suivez toujours?). L'effet premier recherché est l'implication et le développement des compétences. L'effet secondaire est l'amélioration des pratiques.

Avec cette nouvelle perspective, nous essayons de passer d'une démarche d'amélioration discontinue faite d'initiatives personnelles basées sur des intuitions à une démarche collective d'amélioration continue rigoureuse et disciplinée.

Cette discipline clarifie également le rôle des "leaders". Pour eux, il s'agit d'enseigner la démarche à leur équipe et à "challenger" leurs équipiers pour qu'ils analysent et résolvent leurs problèmes. Le "leader" est lui-même "challengé" par son leader/coach/manager/mentor, et ainsi de suite ...

Un prochain billet sera d'ailleurs consacré au rôle de leader, tel que décrit par Scrum, par l'eXtreme-Programming, par le Lean et tel que nous le pratiquons.

Merci encore pour l'aide extérieure!

VISUALISER LA PRODUCTION POUR REVELER LES PROBLEMES

2010-06-16T00:50:00.000-07:00

UN RAPPEL A L'ORDRE

Il y a quelques semaines, notre équipe projet a eu la chance de recevoir la visite d'un coach Lean, pionner de l'eXtreme Programming en France. Nous avons eu la chance de travailler ensemble une journée sur nos pratiques de développement.
J'ai attaqué la journée plein d'enthousiasme et je l'ai terminé avec le moral dans les chaussettes. J'avais honte des problèmes qu'il nous a fait voir ... Ceci dit, il était bénéfique de prendre conscience de nos obstacles et d'être remis sur la bonne voie. En tout cas, je n'oublierai pas le rappel à l'ordre suivant:
Le Lean, c'est

visualiser la production pour révéler les problèmes;
réagir immédiatement;
puis résoudre les problèmes un à un;
pour améliorer les pratiques.

Ce billet est consacré au premier point:

VISUALISER LA PRODUCTION POUR RÉVÉLER LES PROBLÈMES

Prendre conscience d'un problème est la première étape de sa résolution. Voir un problème est une manière efficace d'en prendre conscience. L'afficher pour que tous le voient est une manière de s'engager dans sa résolution. Reste à organiser la production pour que les problèmes se voient.

C'est ici que les choses se compliquent pour le développement logiciel. En effet, il s'agit d'un métier dont la production ne se voit pas de manière évidente. C'est aussi ce qui rend le défi plus amusant en nous obligeant à devenir créatifs.

Voici quelques exemples de pratiques déployées par notre équipe pour visualiser la production pour révéler les problèmes.

PROBLÈME: RETARDS

L'équipe affiche ses burndown chart. Cela lui permet de voir une mesure de sa production. Si la courbe tracée est au dessus de la droite descendante à 45°, cela révèle un problème: la production est en retard par rapport à la planification.

PROBLÈME: PRODUIT NON OPÉRATIONNEL

L'équipe a connecté un iBuddy au poste d'intégration continue. Dès que l'outil d'intégration continue détecte une modification dans le dépôt de code et lance un build, l'iBuddy agite les ailes et sa tête change plusieurs fois de couleur. Cette chorégraphie, répétée plusieurs fois par jour, permet de visualiser le flux continu des contributions dans le dépôt de code. Tant que le build est réussi, la tête de l'iBuddy reste verte. Sa tête devient rouge pour révéler un problème: le build est en échec et donc le produit n'est plus opérationnel!

PROBLÈME: STOCKS, GOULETS D'ÉTRANGEMENT ET REWORK

L'équipe pilote la production en utilisant des Kanbans. Cela lui permet de voir la production en cours. Les kanbans révèlent plusieurs problèmes: la discontinuité du flux avec l'apparition de stocks et de goulets d'étranglement et le rework avec les produits défectueux collectés dans le bac rouge.

PROBLÈME: FLUX DISCONTINU

L'équipe utilise un sémaphore d'intégration pour mener l'intégration continue du produit. Chaque fois qu'un développeur se synchronise et délivre ses modifications dans le dépôt de code, il place un unique marqueur (une peluche, alias Guizmo) sur son écran. Cela permet de voir le flux continu de production qui enrichit le produit. Cette pratique révèle également deux problèmes: un sémaphore qui ne circule pas dans l'équipe signale un flux discontinu et un sémaphore bloqué sur un poste révèle une intégration douloureuse.

PROBLÈME: NON QUALITÉ

Quotidiennement, l'équipe affiche la quantité de non-qualité automatiquement détectée dans le produit. Cela permet de visualiser l'évolution de la qualité de la production. Cela permet aussi de révéler lorsque le produit n'a plus la qualité attendue.

Ces quelques exemples de pratiques permettant de visualiser la production pour révéler les problèmes. Elles sont adaptées à la nature particulière de notre projet et de notre équipe: logiciel critique et grosse équipe auto-organisée. L'étape d'après est de réagir immédiatement lorsqu'un problème est révélé. Cela sera l'objet d'un billet à venir.
A bientôt!

INTEGRATION BIG-BANG

2010-06-10T12:56:00.001-07:00