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 ?

• Can you answer these 7 questions? http://mw22s.th8.us #
• @mathieuberube enjoy:-) in reply to mathieuberube #

Powered by Twitter Tools

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.

• RT @pyxistech: Formation certifiante ScrumMaster: 15-16 mars.Il reste quelques places! Donne14 PDU. http://tr.im/PuuI #scrum #montreal #PMI #

Powered by Twitter Tools

Animer une rétrospective d'équipe est une belle opportunité d'intégration

Comme je l’ai déjà mentionné dans un billet récent, il y a quelques mois j’ai eu l’opportunité de me joindre à une équipe Scrum, répartie entre la France et le Canada, qui travaillait sur un beau projet de web TV.

En 15 mois, l’équipe a vécu des réussites et fait faces à des échecs, comme toute équipe de développement logiciel. Cependant à mon arrivée, force était de constater que le propriétaire de produit¹ était anxieux. Il était de plus irrité par la très faible vélocité de l’équipe.

Au moment de mon arrivée, pour la seconde fois en quinze mois, toute l’équipe se retrouvait pour plusieurs jours.

La fin du sprint courant est alors l’occasion de programmer une rétrospective d’envergure. Les trois ScrumMasters, y voient une opportunité de laisser l’équipe prendre les rênes pour préparer l’agenda de la journée de rétrospective comme elle l’entend. Ils proposent seulement un sujet qu’ils souhaitent voir abordé.

En tant que membre de l’équipe, présent depuis trois jours seulement, je perçois une bonne occasion d’apprendre à collaborer avec mes nouveaux coéquipiers. Je propose de participer à la préparation de la journée et je me porte volontaire pour animer cette journée. L’équipe accepte mon aide pour la préparation et ma proposition d’être l’animateur de la rétrospective.

Nous nous sommes donc atteler à préparer un horaire pour la journée, bousculant un peu le programme initialement prévu par les ScrumMasters. Mais comme nous sommes agiles, nous accueillons le changement avec plaisir .

Sur le plan de la forme, la journée de rétrospective se passe bien, nous parvenons à tenir l’horaire établi et en dépit du peu de temps que nous avons eu pour préparer la logistique, nous ne rencontrons pas de difficultés.

Sur le plan du contenu, l’équipe a choisi de bons sujets, notamment le sujet sur « les décisions lourdes et politiques», qui s’est déroulé sous forme de jeu de questions-réponses entre le propriétaire du produit et les développeurs sur les mécanismes de décisions dans le projet et les enjeux parfois politiques. Les discussions ont été riches, pertinentes et constructives.

Ce que j’ai beaucoup aimé, c’est que j’en ai vraiment appris beaucoup en peu de temps. J’étais actif sans être engagé dans les débats; ce que j’ai trouvé motivant. Sans cela j’aurai simplement été ‘poulet’².

Au delà de me donner une expérience supplémentaire de la facilitation sur une journée complète, j’ai vraiment beaucoup appris sur l’historique du projet, l’équipe, le fonctionnement, les choses qui vont bien et les problèmes à régler. Je remercie beaucoup l’équipe de m’avoir offert cette chance, mon intégration n’en a été que plus rapide.

Avez-vous des expériences semblables à partager ?

Pensez-vous que ce type d’intégration peu avoir des inconvénients majeurs tels que générer un a priori ou un jugement sur le projet trop tôt dans la période d’intégration ?

• RT @tweetmeme Forrester Reports “Agile Development: Mainstream Adoption Has Changed Agility” http://is.gd/7VHvl #

Powered by Twitter Tools