Agile Gardener

Une carte bloquée dans le tableau Kanban, c'est du gaspillage

« Cette carte est bloquée car il nous manque un contenu, un fichier sans lequel le site ne peut être mis en ligne. On sait que ça va prendre plusieurs jours. En fait, on ne sait même pas quand est-ce que ce fichier sera disponible. En plus, cette carte n’est vraiment plus prioritaire ».

Voilà ce que j’ai entendu il y a quelques jours. L’équipe a déjà travaillé sur cette carte, le site est bien avancé. En fait, il ne manque qu’un fichier, mais cela bloque sa livraison et, par effet de bord, une case dans le tableau Kanban, réduisant la capacité à réaliser d’autre demandes.

La première réaction est de dire « le Kanban ne fonctionne pas, ce n’est pas assez flexible ». Il suffit de pousser la carte sur le bord et de laisser la place aux autres items à réaliser.

Holà! Doucement, doucement! Un des objectifs de la mise en place d’un système Kanban, est de rendre visible les gaspillages et de permettre ainsi de prendre des actions pour les endiguer et améliorer le processus.

Donc nous avons un succès, un beau succès, Kanban fonctionne bien! Maintenant qu’est-ce qu’on fait?

Nous pouvons identifier plusieurs gaspillages dont les suivants :

• Surproduction : l’équipe à passer du temps à produire un site qui ne sortira peut-être jamais
• Coordination inutile : pendant plusieurs jours, l’équipe a passé du temps à se synchroniser pour cette tâche.
• Changement de tâche : l’équipe doit laisser une tâche de côté et devra peut-être y revenir, cela nécessitera alors du temps pour se concentrer et reprendre la connaissance.
• Délai : la carte bloquée empêche d’autres demandes de renter dans le flux, retardant leur livraison.

Ces constatations m’amènent à poser les questions suivantes :

1. Pourquoi commencer la réalisation d’une carte que l’on ne pourra terminer?
2. Pourquoi une carte se retrouve-t-elle prioritaire un jour et ne l’est plus, deux jours plus tard, une fois en cours de réalisation?
3. Pourquoi commencer une carte alors qu’il y en a d’autres bloquées dans le tableau?
4. Pourquoi commencer une carte alors qu’il y en a en cours de réalisation dans le tableau?

Dans les jours et semaines à venir, je vais aider l’équipe à trouver ses réponses à ces questions et réduire les gaspillages.

Astuces d'équipe pour améliorer la mêlée quotidienne

Il y a quelques jours j’ai publié « Odeurs de mêlée quotidienne », article dans lequel j’évoquais des symptômes observés lors de mêlées quotidiennes.

Depuis, l’équipe a fait des progrès très intéressants que je souhaite partager.

Les symptômes présentés dans le premier billet sont répétés ci-dessous accompagnés des solutions ou bien des étapes des solutions mises en œuvre.

L’équipe ne répond pas aux 3 questions.

Afficher les 3 questions pour que l’équipe puisse les voir facilement chaque matin. Mais, comme on pouvait s’y attendre, le fait d’afficher les 3 questions, n’a pas eu l’effet attendu. Cette solution ne venait pas de l’équipe qui n’en a donc pas tenu compte. Pour que la mêlée quotidienne s’améliore, il faut aider l’équipe à se l’approprier.

Montrer l’exemple. Dans ce deuxième essai, à la fin de la mêlée, j’ai repris un comportement observé et je l’ai rejoué pour présenter un exemple de l’intervention attendue de chacun des membres de l’équipe. Il peut être bon de répéter le processus de temps en temps pour aider l’équipe à progresser.

L’équipe ne s’approprie pas la gestion du tableau et des graphiques de progression (burndowns).

1. Éloigner le ScrumMaster pendant un jour ou deux, ou bien, profiter de son absence. Pendant ce temps là, l’équipe continue à faire sa mêlée quotidienne.
2. Au retour du ScrumMaster, attendre la fin de la mêlée et poser la question suivante : « Êtes-vous confiant en votre engagement? [...] Quand je regarde le graphique, je ne suis pas en mesure de le savoir. » La conséquence directe de cette dernière question : une belle discussion, de très bonnes interrogations sur le fonctionnement et l’utilité des graphiques visuels et une prise en charge des graphiques par plusieurs membres de l’équipe.
3. Reposer  ensuite la question de l’engagement à plusieurs reprises. L’équipe se la pose toute seule très rapidement.

L’équipe rapporte son occupation de la veille au tableau ou bien au ScrumMaster, sans regarder les coéquipiers avec pour effet de bord ‘d’autoriser’ des conversations parallèles.

1. Éloigner l’équipe du tableau. La première fois l’équipe est déstabilisée, mais les coéquipiers comprennent vite qu’il est préférable de se préparer avant la mêlée et forment un cercle pour se parler.
2. Proposer au ScrumMaster de sortir du cercle pendant quelques temps. En se positionnant en arrière il bénéficie d’un poste d’observation privilégié. N’étant plus visible  des membres de l’équipe, ceux-ci ne peuvent plus lui parler directement et lui rapporter l’activité de la veille. Inviter le ScrumMaster à intervenir à la fin pour donner de l’information au besoin.
3. Le respect de la parole est régulé par l’utilisation d’un objet de parole que l’équipe s’approprie et se passe de main en main.

Les effets de ces petites astuces se sont très vite fait sentir dans l’équipe avec pour conséquences immédiates de ramener la mêlée à 10 minutes et à son utilité première, c’est-à-dire, un moment de synchronisation de l’équipe. Il reste alors 5 minutes pour des informations complémentaires, mettre à jour les graphiques d’avancement, ou bien retourner travailler plus vite sur les tâches de l’itération en cours.

Ces astuces ont permis de progresser rapidement vers une mêlée quotidienne beaucoup plus efficace, menée dans un temps plus court.

Un grand bravo à l’équipe pour ses apprentissages.

Et vous, quels sont vos ‘trucs’?

Les simulations comme outil de perfectionnement du coach

Depuis environ trois mois, nous réalisons des simulations dans le but d’améliorer nos compétences en tant que coach, lors de nos rencontres caddy¹ bimensuelles.

Ces rencontres, dans ce nouveau format, sont maintenant pour moi d’une richesse incroyable. Il y a environ deux mois, j’étais acteur de l’une de ces simulations avec Dominic qui jouait le rôle de golfeur, jouant pour ma part le rôle de caddy.

Cette expérience a été difficile pour moi, mais elle a aussi été une grande leçon. Au cours de la simulation, alors que je pratiquais la posture de coach, j’ai « bloqué »,   cherchant  à tout prix un problème là où il n’y en avait pas. Dominic me présentait une situation qui ne correspondait pas schéma mental que je me faisais du déroulement et du contenu d’une rencontre caddy. Après m’être rendu compte que j’insistais inutilement, j’ai laissé Dominic continuer la rencontre, mais je n’étais plus dans l’écoute, j’étais contrarié. Non seulement je n’étais plus à son écoute, mais de surcroît, je n’étais pas capable de répondre au besoin simple qu’il avait ce jour-là (dans la simulation) qui faisait appel à des compétences techniques que je maîtrise sans difficultés.

Cela demande du courage de se confronter à des simulations même lorsqu’elles sont jouées dans un environnement sécurisant et sécurisé, mais la rétroaction des vingt paires d’yeux et d’oreilles sur ce qui s’est passé est très enrichissante, instructive et finalement réconfortante.

Depuis, je fais très attention à ce ‘piège’ dans chacune des rencontres que j’ai avec mes golfeurs en essayant de le détecter et de le désamorcer. À ce piège, mais aussi à tous ceux que nous identifions lors des autres simulations. J’essaie aussi de mettre en œuvre tous les ‘bons comportements’ que nous relevons et que nous valorisons lors des séances de feed-back.

Une simulation ne garantira jamais que je ne reproduise pas cette erreur ou que je n’en ferai pas d’autres, mais à chaque leçon apprise, un nouveau détecteur s’allume dans la case « situation de coaching» auquel je suis maintenant attentif. Rien ne remplace la réalité des rencontres et je ferai encore et toujours beaucoup d’erreurs, et ça n’est pas grave, mais il y a des chances pour que je fasse celles-là moins souvent.

Dans votre expérience et votre formation de coach, quelle est la place des simulations ? Qu’en retirez-vous ?

Photo de mêlée attribuée à http://www.flickr.com/photos/cdm/

Il y a quelques semaines de cela, après plusieurs jours sans intervenir auprès de l’équipe, j’ai pu observer, lors de mon retour, une mêlée quotidienne¹ avec quelques dysfonctionnements.

Avertissement :

Ce que vous lirez n’est pas un jugement, ce que j’ai observé ne constitue pas à mes yeux des erreurs, mais démontre plutôt un apprentissage naissant de la mêlée quotidienne.

Contexte :

• L’équipe a terminé une première itération et s’apprêtait à commencer la deuxième.
• Finalement, elle stabilise pendant une semaine l’application pour une release annoncée très tard. Son passé l’a rattrapé et la date ne peut être manquée.
• De façon autonome, l’équipe a gardé les nouvelles pratiques mises en place dans la première itération et n’est pas retombée dans le mode “panique livraison” du passé.
• Je suis présent le jour de la mise en ligne et elle a lieu sans que l’équipe n’ai eu à faire de temps supplémentaire.

Symptômes observés :

• La ScrumMaster(SM) donne la parole à tour de rôle : “c’est à toi Louis”, Louis fait le tour de la table pour venir parler.
• Une personne fait du reporting face tableau ou tournée vers le ScrumMaster,  et des conversations parallèles ont lieu.
• Personne ne donne un statut sur le format des 3 questions²
• Le tableau de l’équipe n’est pas à jour. Le statut des toutes les tâches est mis à jour en direct, le tableau ne reflète l’état d’avancement qu’après l’intervention. Cela fait perdre du temps et provoque des cassures de rythme dans la prise de parole.
• Il y a par moment des personnes en retrait ce qui donne deux “épaisseurs” au groupe.
• La ScrumMaster demande plusieurs fois ce que l’on fait de certaines tâches au tableau avant d’obtenir une réponse.
• Un bureau gêne l’espace devant le tableau, personne ne le déplace.
• Une personne est occupée pour la mise en ligne, elle n’intervient pas du tout et ne donne pas de statut aux autres membres de l’équipe.
• Deux personnes sont assises.
• Finalement, la mêlée dépasse de 5 minutes le temps imparti.

Debrief et plan d’action :

À la suite de la mêlée quotidienne, je prends quelques minutes avec la ScrumMaster pour lui demander comment elle a perçu cette mêlée, comment elle se sent. Ce que je trouve formidable c’est qu’en quelques secondes elle m’a donnée la plupart des observations ci-dessus assorties de commentaires pertinents : “c’est comme s’ils n’avaient pas encore pris la mesure le l’utilité de mettre à jour le tableau” par exemple.

S’en est suivi un dialogue ressemblant à celui ci-dessous :

SM : “Mais comment je peux faire pour changer le comportement de l’équipe pendant la mêlée ?”

Moi : “Quel est le comportement qui te dérange le plus ?”

SM : “Je dois dire aux personnes de venir quand c’est leur tour”.

Moi : “Que pourrais-tu faire le plus simple pour changer cela”

SM : ” Tu m’as déjà dis de ne pas intervenir, de laisser l’équipe faire son daily”

Moi : “Oui effectivement, peut-être pourrais-tu rappeler à l’équipe ce que tu attends pendant le daily : qu’ils fassent un statut vers l’équipe, en répondant aux 3 questions puis les laisser continuer sans intervenir, en laissant des blancs, des silences s’il y en a. Je t’inviterai à le faire rapidement sans forcement attendre une rétrospective.”

SM : “C’est vrai, je pourrais faire ça, mais ils ne répondent pas aux 3 questions”

Moi : “Les connaissent-ils, peut-être ont-ils besoins que quelqu’un rappellele ces questions”

SM : “Pour qu’ils les voient les questions ont pourrait les afficher”

Moi : “C’est une très bonne idée ça, avoir les trois questions affichées ça permet de se les mettre en tête à chaque mêlée”

Et nous avons continué la conversation encore quelques minutes.

Finalement, le bureau qui gêne devant le tableau va être poussé un peu, les questions vont être affichées, la SM va répéter le comportement attendu lors du daily et laisser l’équipe aller. Les résultats dans un prochain billet

Dans vos organisations ou dans vos équipes, comment se passent vos mêlées quotidiennes, observez vous d’autres symptômes ?

Si vous êtes coach ou ScrumMaster, comment intervenez vous pour que l’équipe prenne conscience et règle ces symptômes ?

Vendredi 12 mars 2010 à 13h30

Venez participer à une session  « XP Game » lors de la conférence Confoo.ca qui se tiendra à Montréal les 10, 11 et 12 mars 2010.

Avec mon coéquipier Mathieu Bérubé nous serons vos hôtes et les maîtres du jeu! La session « XP Game » se déroulera le vendredi 12 mars 2010 à 13h30.

Vous expérimenterez, grâce à cet atelier ludique, la planification agile : priorisation par valeur d’affaire, estimation de user stories. Vous découvrirez le cycle des itérations et  les livraisons fréquentes et régulières de fonctionnalités. Vous mesurerez la vélocité et vous mettrez en existance le principe d’amélioration continue par l’inspection et l’adaptation de votre processus d’équipe.

Nous serons plusieurs pyxissiens présents pendant ces trois jours. Je vous invite à assister aux présentations et aux ateliers suivants :

• Vincent Tencé présentera deux sessions : « Introduction à l’agilité » mercredi le 10 mars à 9h30 et « Introduction au TDD » jeudi le 11 mars à 14h45.
• Jean-François Proulx et Nicholas Lemay présenteront la session « Simulation Scrum avec prototypage papier » vendredi le 12 mars dès 8h30

Il y a de nombreuses autres sessions passionnantes comme celle de Benoît Lapointe : « Expérience pratique du Kanban chez IBM Bromont ». Je vous encourage à consulter l’horaire complet de la conférence.

Une équipe peut-elle vivre sans ScrumMaster 'officiel'?

L’été dernier j’ai rejoint un projet qui avait démarré 15 mois auparavant. L’équipe chargée du développement était répartie entre 3 sites (1 à Montréal, 2 à Bordeaux). Peu après mon arrivée, il y a eu réorganisation des équipes, et dans notre équipe, nous avons proposé de ne pas avoir de ScrumMaster ‘officiel’. La question suivante se posait donc pour nous :

Une équipe Scrum peut-elle vivre sans ScrumMaster ‘officiel’?

Je dois dire tout de suite que nous n’avons pas eu le loisir de pousser très loin l’expérimentation car le projet a été interrompu environ 6 semaines après la réorganisation. Nous avons tout de même travaillé avec ce modèle pendant 2 itérations¹.

Cette équipe était composée de 3 personnes. Deux étaient présentes depuis longtemps : depuis le début pour l’un et depuis 10 mois pour l’autre. Puis il y avait moi, nouveau sur le projet. Le coéquipier leader naturel travaillait depuis plusieurs mois sur le module dont nous avions la charge. Il y avait une bonne cohésion, nous étions à l’aise avec Scrum et nous nous sentions en contrôle!

Nous tenions notre mêlée quotidienne² sans difficultés. Nous allions à tour de rôle à la mêlée des mêlées³ — cette pratique était déjà en place  bien avant la réorganisation. Nous faisions la maintenance du carnet de produit⁴ régulièrement avec le propriétaire de produit⁵. Nous aidions tous à l’organisation de l’équipe, même si une très grosse partie du travail était réalisée par le leader de l’équipe.

Voici les avantages obtenus lors de ce projet

• Nous nous sentions vraiment autonomes. Nous organisions nous même nos rencontres importantes (mêlée quotidienne, maintenance du carnet de produit, réunion avec les intervenants extérieurs).
• Nous étions beaucoup plus responsables. Lorsque quelque chose allait de travers, nous ne pouvions pas dire :  «Le ScrumMaster ne fait pas son boulot ».
• Nous avions une bonne flexibilité, mais ce point relève petut-être du fait que nous n’étions que trois.
• Contrairement à ce que j’ai vu à maintes reprises, personne dans l’équipe n’était perçu comme ’supérieur hiérarchique’.

Nous n’avons pas subi d’inconvénients, mais peut-être y en aurait-il eu à long terme.

Cependant je suis convaincu d’une chose : il y a un préalable. Cela peut fonctionner à la condition que l’équipe soit mature, tant sur le plan des personnes qui la compose que  sur le plan de la maîtrise des outils, du processus Scrum et de la communication. Je vous invite à lire, sur un thème similaire, le retour d’expérience d’Isabelle Therrien, où elle fait mention des dérives qui peuvent se produire. Dans les commentaires notamment, il est question de prendre du recul, ce qui n’est pas toujours simple quand on a la tête dans le code pour livrer de la valeur à longueur de journée.

Résumé en quelques lignes, le choix de ne pas avoir de ScrumMaster ‘officiel’ peut paraître rapide ou évident, mais tout ceci ne s’est pas décidé en un jour. De fait, même une fois en place, les questionnements suivants revenaient de façon récurrente dans nos conversations :

• S’il fait fonction de ScrumMaster, le leader doit-il prendre le titre et s’exposer?
• Ce rôle peut il être partagé, et dans ce cas, est-ce efficace?

Pour conclure, je dois dire que j’ai aimé cette expérience. Même si cela n’a pas duré bien longtemps, j’ai vu les prémices de quelque chose que je voulais vérifier depuis longtemps : « le rôle de ScrumMaster est un rôle temporaire, il a pour objectif de rendre son équipe capable de se passer de sa présence, et cela peut fonctionner ».

Avez-vous des retours d’expérience similaires à partager ?