Agile Gardener

Mettre de la pression sur le système pour faire apparaître le gaspillage

Afin de faire apparaître les goulots d’étranglement dans le processus de réalisation d’une équipe fonctionnant en Kanban, j’ai proposé de réduire les limites du WIP¹

Lors de la mise en place, l’équipe a fixé des limites confortables pour le WIP. Après deux semaines d’utilisation du tableau, l’équipe n’a pas identifié de goulot d’étranglement.
Lorsque j’ai fait ce constat, j’ai proposé au coordonnateur, lorsqu’il a remodelé le tableau à la réception du nouveau tableau, de réduire la capacité de certaines colonnes en plus des modifications prévues lors de la rétrospective.

Cela va bientôt faire trois mois que le tableau Kanban est en place et deux mois que les limites ont été baissées, et nous avons observé des difficultés telles que les suivantes :

1. Des cartes sont bloquées depuis plusieurs jours et il ne reste qu’un espace disponible dans la colonne pour passer des nouvelles demandes.
2. Il y a deux cartes dans une case.
3. Une case ‘blocage spécial’ à été crée pour sortir une carte qui est bloquée et qui n’est plus prioritaire.

En discutant avec l’équipe, il apparaît que la baisse des limites a eu l’effet escompté, puisque avant cette baisse, il y avait suffisamment de place libre pour que de nouvelles cartes puissent passer même si d’autres étaient bloquées.

Content de ce résultat, je comptais proposer à l’équipe de réduire le nombre global de cartes présentes dans le tableau, car actuellement, les limites établies permettent d’avoir un nombre que « je » juge trop important d’items en cours simultanément.
En effet les limites sont établies par étapes du flux de travail, mais les mêmes personnes travaillent sur plusieurs étapes et cela ne force pas les items à sortir le plus vite possible, certains restant même plusieurs jours dans le backlog.

Mais je me suis ravisé car mes solutions ne seront jamais meilleures que celles de l’équipe.
Alors, au lieu de proposer ma solution de réduction du nombre de cartes dans le tableau, j’ai proposé à l’équipe de travailler sur la notion de gaspillage lors d’une rétrospective.

À la suite de cette rétrospective, après avoir identifié l’attente (une carte est souvent en attente dans le tableau) comme l’un des plus gros poste de gaspillage, l’équipe a commencé à mesurer le temps passé par les cartes dans les différentes phases du processus à l’aide de la méthode proposée dans l’article « Flow. Discover Problems and Waste in Kanban ».
J’espère que ces mesures permettront à l’équipe de trouver « ses » solutions pour éliminer le gaspillage, solutions qui rendront la mienne obsolète.

Quels sont les mécanismes que vous mettez en place pour contraindre le système ? Quels sont les résultats que vous obtenez ?

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 ?

Dans le cadre de la démarche “Caddy” ¹ nous avons récemment eu une discussion sur la transparence et le secret professionnel.

Cette discussion est issue de la propostion suivante : (je ne cite pas l’auteur car je ne lui ai pas encore demandé sa permession)

Est-ce qu’il serait possible d’avoir une zone accessible seulement par les “Caddys” dans Confluence afin de pouvoir partager certains cas vécus (bien sur les vrais noms ne seraient pas donné) ?

La discussion a vite porté sur le fait que cet espace pourrait être ouvert à tous (employés de Pyxis)

Voici alors ma première réponse :

Pour l’accès à tous, je suis partagé entre “tranparence” et “secret professionnel”.

La relation de confiance est basée sur le fait que cela reste entre “Caddy” et “Golfeur” et quand je vais demander un conseil à d’autre, j’en avise le “Golfeur”.
Même anonyme, si un “Caddy” pose un question sur un “Golfeur” (anonymisé) il ne faudra pas longtemps pour faire des rapprochements.

D’un autre côté la transparence apportera sans doute de l’aide précieuse de personnes extérieures à la communauté “Caddy” (soutient, idées, …)

mon point de vue partagé

Suite à cette réponse, d’autres échanges ont suivi évoquant le fait que le secret apporte crainte, doute et suspicion, et que les “Caddys” pourraient être vus comme une “élite” qui se partagent des informations auxquelles les autres n’ont pas accès.

Voici le point de vue que j’ai proposé par courriel :

Je reviens sur le point transparence.
Après rapide discussion avec un “Golfeur” (dont je ne suis pas le “Caddy”), je proposerais que l’on en parle aux “Golfeurs” avant de commencer à être full transparents.

Il y a des problématiques que j’ai eu à traiter dans les dernières semaines qu’en tant que “Golfeur” je n’apprécierais pas de voir évoquées (même de façon anonymes) en dehors d’un cercle de personnes dont c’est la responsabilité (tout pyxissien peut faire le choix d’être “Caddy”, il n’y a pas de “sélection” ou de “promotion”).
D’ailleurs lorsque j’ai parlé à d’autres “Caddys” pour de l’aide sur une problématique, j’en avais avisé le “Golfeur” avant et cela était avec son accord.
Le cadre des “Caddys” est pour moi une zone de confiance entre pairs. Je n’y mets aucun “élitisme” simplement lorsque je me place avec ma casquette de “Golfeur”, j’attends que mon “Caddy” agisse comme un coach, c’est à dire avec discrétion et qu’il aille prendre conseil auprès de pairs au besoin, mais pas de toute l’organisation. D’ailleurs, j’espère (comme “Golfeur”) qu’il échange des problématiques, et des techniques pour les traiter, avec ses pairs pour être plus efficace pour m’aider.

C’est un avis très personnel, mais ne confondons pas les processus et les humains. Les infos liées au processus doivent être visibles (pour moi il en reste encore à mettre en lumière mais c’est un autre sujet). Les infos humaines obtenues dans le cadre d’une relation “Caddy-Golfeur” sont pour moi hors de ce cadre. (il me semble que personne ne fait de rencontre “Caddy” au milieu de la cuisine)

Maintenant, si des “Caddys” sont d’avis contraire au mien, je l’accepte complètement, à titre personnel je ne souhaite pas adopter cette démarche (transparence anonymisée) et j’inviterai à demander l’avis des personnes intéressées (moi avec casquette de “Golfeur” par exemple ) avant d’aller plus loin.

D’ailleurs j’ai un gros travail personnel à faire avec ma casquette de “Caddy” pour être bien plus “discret” (pas au sens du secret suspicieux mais au sens de limiter le nombre/cercle de personnes mise au courant) lorsque je traite des situations difficiles mais aussi pour aller chercher du “brief/débrief” auprès de vous autres et limiter mon “expansion” au groupe de 20 personnes ou moins.

Une fois la période des fêtes passée et quelques jours de repos, je compte bien reprendre ma recherche de formation de coach pour approfondir mes connaissances à la fois “techniques” mais aussi approfondir les notions “d’éthiques”… Je pense que celai m’aidera aussi à mieux comprendre notre rôle, ses limites, les applications dans notre contexte, comme par exemple le sujet dont nous parlons.

Nous n’avons pas reparlé de ces échanges depuis, mais en relisant rapidement un livre sur le coaching je suis convaincu que nous devrons aborder prochainement les notions d’éthique lorsque l’on adopte la posture de coach, notamment dans le cadre d’une relation de coaching entre collègues de travail.

Avez-vous des retours d’expérience, des réflexions à partager sur le sujet de l’éthique dans la relation de coaching ? Quelles sont pour vous les limites du secret professionnel ?

Tableau Kanban de l'équipe "production" (première version)

Depuis quelques semaines j’ai le plaisir d’accompagner une équipe dans son adoption d’une gestion de projet en mode Agile. C’est un mandat passionnant sur plusieurs aspects :

• La motivation et l’envie de l’équipe, qui se traduit par un engagement de tous.
• L’utilisation en parallèle de Scrum et de Kanban qui rend mon intervention en tant que coach intense et très riche.

L’équipe est divisée en deux “sous-équipes” qui ont des rôles et des activités bien différentes : L’une s’occupe du volet production (newsletters, mini-sites, mises à jour de l’existant etc.) et l’autre du volet développement des nouvelles fonctionnalités pour le site Internet.

Suite à nos préconisations, chacune des équipes a choisi d’adopter l’outil qui lui semblait le mieux adapté à ses contraintes : Kanban pour l’équipe production et Scrum pour l’équipe de développement. (Ce n’est d’ailleurs pas le modèle que nous avions proposé en premier lieu)

Au cours de la première itération (l’équipe a choisi des itérations de 2 semaines), en regardant le tableau Scrum de ses collègues, un des membres de l’équipe de production (fonctionnant en Kanban) m’a dit : “Notre tableau ne se vide jamais, ça c’est correct, mais notre colonne “Done” n’est jamais pleine, ça me manque, ça donne l’impression qu’on travaille moins.”

En effet, le tableau Kanban reflétant un flux continu ne se vide jamais comparé au tableau Scrum qui a un cycle de vie de 2 semaines. De plus, l’équipe production vide la colonne “Done” lors  de la mêlée quotidienne après avoir passé en revue les items terminés.

Pour changer cette perception, l’équipe à décider de laisser toutes les tâches à “Done” sur le tableau entre chaque rétropective qui se déroule toutes les 2 semaine . En plus de se donner de la visibilité sur le travail accompli, l’équipe compte utiliser cette pratique pour mesurer plusieurs éléments :

• Les cartes sont-elles remplies correctements : date de début, date de fin, client, identifiant de la tâche, etc.
• Le nombre de cartes “urgence”  par 2 semaines.
• Le temps de sortie moyen par taille d’items.

Votre équipe Kanban a-t-elle déjà eu ce besoin de voir son accomplissement dans le temps ? Qu’avez-vous mis en oeuvre pour cela ?

Un leader désigné non consentant ne sera pas un leader ! Prendre un rôle, et la charge qui y est associée, n’est pas une chose qui se décide de façon unilatérale. Cela est un acte d’entête et de volonté réciproque qui implique de savoir dire non dans les deux camps.

Depuis mars 2009, à Pyxis, je participe à la CoMI (Communauté Marketing Internet) en tant que membre actif. Après une période de forte activité au printemps, le niveau d’énergie du groupe a baissé durant l’été .

À ce moment là j’ai proposé de changer notre mode de fonctionnement auquel je voyais les problèmes suivants : pas de cadence, pas d’engagement, pas de carnet de produit,… pour le remplacer  par une organisation du travail de type Scrum. Je pensais que livrer régulièrement des incréments dans le cadre d’un engagement mensuel limité à une part d’un carnet de produit priorisé, nous permettrait de nous concentrer  à livrer plus de valeur pour le site web de Pyxis.

Dès que nous avons parlé de cette organisation, il a été question de trouver parmi nous un ScrumMaster, la personne en charge d’animer l’équipe, et d’aider le responsable du carnet de produit, le propriétaire du produit (PO). Personne ne souhaitait prendre ce rôle (un “indice puant”, un smell). Toujours est-il qu’après avoir dit non une première fois, les membres de la communauté ont décidé, en me forçant gentillement la main , que je jouerai le rôle de ScrumMaster.

Résultat, j’en fais le constat aujourd’hui et je ne le cache pas, je n’ai pas embarqué. Certes j’ai quelques fois aidé le propriétaire du produit (PO dans la littérature anglophone) à organiser les activités et le carnet de produit (backlog), mais je n’ai jamais pris la charge qui m’incombait depuis le jour ou je n’ai pas su dire non aux autres membres.

Être sollicité et “élu” par un groupe de personnes, même si cela est très valorisant, ne signifie pas qu’on a ou qu’on aura l’énergie pour œuvrer au niveau de la responsabilité associée au rôle.

Lorsque vous travailler au sein d’une communauté, certes vous ne pouvez pas espérer coordonner cette communauté sur le long terme sans l’assentiment de ses membres, mais il est évident pour moi que le leadership de la communauté n’est pas une chose qui se décrète de façon unilatérale. Un groupe de personne, aussi bienveillant soit-il, ne peut espérer être correctement guidé par quelqu’un qui n’y est pas explicitement candidat.

J’ai appris une chose, il faut vraiment que j’apprenne à dire non, si mon oui n’est pas un oui franc et massif. Un “ouais” n’est pas un “oui” !

Depuis quelques jours maintenant, après avoir pris conscience de tout cela j’ai décidé d’agir, j’envisageais deux solutions : prendre ma place ou annoncer clairement que je ne la tenais pas.

J’ai décidé de  prendre la place et d’assumer la charge associée. Affaire à suivre …

In the post I didn’t have time to do this Martin said :

Life is as such as we accept more work and activities than we have time for, so claiming we didn’t have time for something seems like an understatement. In reality, what really happens is:

1. the individual didn’t want to do the work in the first place;

2. the person is procrastinating;

3. the person has difficulties in prioritizing their activities and cannot make a decision to determine which piece of work is more critical and should be completed first.

I used to get this excuse out of my hat too often in the past and that’s something I’m really trying to improve.

The tools I use are Getting Things Done known as GTD and popularized by David Allen and more recently the Pomodoro technique as they help me to manage my todos : to prioritize and to focus on doing.

The Pomodoro technique really helps to focus on the work that has to be done. Prioritize your tasks for the day, estimate, and do it focusing in small iterations : 25 minutes time-boxes + a 5 minutes break.

GTD is more big picture. But the most valuable impact from GTD is that all the work “to be done” is visible, and so that’s oblige me to make a decision : “Do I want to do it? Do I have to do it? Yes? No?”. If the answer is “NO”, I delegate it, or I delete it. No longer in my list, no longer in my mind! Sometimes I fold the idea in a “Someday/Maybe” place to delay it until I recover enough energy, or it becomes the things to do.

The last thing I did is to publicly communicate my occupations to my colleagues.

Learning to say “NO” is one of the hardest thing to do for me

How do you manage to eradicate the “I didn’t have time to do this” excuse from your vocabulary?