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 ?

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 ?

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 ?

• New tweetup, Agile Tour 2009 Montreal. Tweet "yes #ev1-at09mtl" to RSVP #at09mtl http://twubs.com/ev1-at09mtl #
• I just became a member of the Twub for #at09mtl at http://twubs.com/at09mtl #
• #at09mtl will be the hashtag for #agiletour #montreal #
• #agiletour #montreal more and more people on the waiting list. If you decide to cancel send me a DM, I'll make someone else happy #
• #agiletour #montreal 200 emails send to confirm registration , and 20 emails send to people on waiting list #
• #agiletour #montreal sold out See you on Tuesday 27th lucky attendees #
• RT @tbalbous: #agiletour #montreal who'll get the last seat. #
• #agiletour #montreal 2 padsas #
• RT @pyxistech: Vous êtes Agile quand : Vous classez systématiquement votre liste d’épicerie par ordre de priorité… http://bit.ly/1Okzdt #
• @pyxistech bravo pour la publication dans Les Affaires http://ping.fm/2QBnN #agile #montreal #
• #agile #scrum #agiletour #montreal 27th october! last 10 tickets to buy! Hurry up! #

Powered by Twitter Tools

J’ai réalisé ce soir ma première présentation publique sur l’agilité : c’est une très bonne expérience pour moi.

1er constat : près de 25 personnes se sont déplacées.
C’est un bon indicateur de l’intérêt que suscite les méthodes Agiles. La moitié de ces personnes est intéressée à participer à d’autres rendez-vous.

2 ème constat : la gestion du temps c’est compliqué
J’ai très mal géré mon temps sur la présentation et surtout ma présentation était beaucoup, beaucoup trop longue.
A l’avenir, il faudra que je travaille en amont sur des répétitions pour mieux évaluer la durée et utiliser un réveil le jour J pour me situer.

3 ème constat : Le stress c’est avant, pas trop pendant.
J’ai bien stressé lorsque j’ai appris qu’il y aurait une vingtaine de personnes là ou je m’attendais à une petite dizaine.
Paradoxalement, je n’ai pas trop ressenti ce stress une fois dans la salle, au cours de la session.

Pour résumer cette soirée est pour moi très positive. Je dois encore progresser sur la forme et surtout le fond, mais je suis vraiment ravi de voir qu’à Nantes il y a beaucoup d’autres personnes qui veulent travailler dans de meilleures conditions et que certaines le font déjà

Agile Tour à Nantes l’an prochain ?

Vos commentaires sont les bienvenus pour m’aider à progresser.