Archive

Posts Tagged ‘Agile’

Agile Coach Camp Canada – Here we go!

June 10th, 2010 No comments
agilecoach2010 300x88 Agile Coach Camp Canada   Here we go!

Click on the logo to register on Agile Coach Camp Canada website

Tomorrow morning will be the kind of easy wake up as I’ll attend Agile Coach Camp Canada in Waterloo (Ontario) with 3 colleagues of mine from Pyxis.

Looking forward to meet you there with all the others great agile coaches icon wink Agile Coach Camp Canada   Here we go!

Agile Coach Camp Canada
An Open Space Conference for Agile Coaches
Peer-to-peer Learning in a Collaborative Setting
June 11-12, 2010
Waterloo, Ontario, Canada
Free! And it’s SOLD OUT

Follow #accca on Twitter

To know more about registred people, have a look at postion papers.

La permission ou le pardon : faites votre choix!

May 27th, 2010 1 comment

Ni l’un ni l’autre. Je choisis la confiance qui permet le conflit qui engendre l’engagement qui soutient l’imputabilité qui mène à se concentrer sur les résultats!

Il y a quelques semaines, j’évoquais avec Éric Laramée le fait que quelques fois, lorsqu’une chose doit être réalisée, il vaut mieux le faire sans attendre la permission puis demander pardon par la suite. J’avoue avoir succombé à cette facilité par le passé.

À la suite de cette conversation, Éric m’a dirigé vers cet article récent de Ben Snyder : “Don’t Ask For Permission When Forgiveness is Easier” dont je vous recommande la lecture.
41ym2vZ0X1L. BO2,204,203,200 PIsitb sticker arrow click,TopRight,35, 76 AA300 SH20 OU15  La permission ou le pardon : faites votre choix!
Je n’ai pas pu m’empêcher de faire le parallèle avec la (re)lecture récente du livre de Patrick Lencioni : “The Five Dysfunctions of a Team: A Leadership Fable“.

Dans un groupe, lorsqu’une personne agit à l’encontre des autres, même s’il demande pardon par la suite, cela laisse des traces. C’est d’autant plus vrai que l’action est faite avec une intention cachée, une intention de nuire ou bien à des fins personnelles sans égards au groupe.

La prochaine fois que vous entendrez l’expression bien connue “il vaut mieux demander pardon que demander la permission”, prenez quelques minutes pour comprendre le contexte, et pour déterminer à qui profite l’action qui a été entreprise.

Cette expression révèle souvent les dysfonctionnements fondamentaux évoqués dans le livre ci-contre. Une telle action ne pouvant venir d’un membre d’une équipe telle que décrite par Patrick Lencioni, une équipe dont les membres placent la réussite du groupe avant la satisfaction personnelle.

Finalement ce que ça m’inspire c’est : “Encore de belles conversations à venir”, beaucoup d’efforts à faire sur le plan personnel et de beaux jours pour continuer à faire un métier qui me passionne.

Et vous, êtes-vous inpiré?

Hope to meet you at Agile Coach Camp Canada

May 17th, 2010 3 comments
agilecoach2010 300x88 Hope to meet you at Agile Coach Camp Canada

Click on the logo to register on Agile Coach Camp Canada website

I’ll attend Agile Coach Camp Canada in Waterloo (Ontario) with many other great agile coaches

Agile Coach Camp Canada
An Open Space Conference for Agile Coaches
Peer-to-peer Learning in a Collaborative Setting
June 11-12, 2010
Waterloo, Ontario, Canada
Free!

Follow #accca on Twitter

To know more about registred people, have a look at postion papers.

Action = porteur + date

March 18th, 2010 2 comments

Pour qu’une action se réalise, il faut un porteur et une occasion identifiée dans le temps.

polo clap board 228x300 Action = porteur + date

Pour qu'une action se réalise, il faut un porteur de l'action et une occasion identifiée dans le temps.

Dans le tableau Kanban, lorsqu’une carte est bloquée, l’équipe à tendance à dire : « Cette carte est bloquée! Elle dépend de X, il faut que je le rappelle [...] mais il n’est pas très disponible. »

Lorsque j’entends ceci, je parie : « dans deux jours, la carte sera toujours bloquée au même endroit! ». D’ailleurs pourqoui changerait-elle de place? Il y a deux jours, la carte était là et j’avais déjà entendu la même excuse phrase, il n’y a donc pas de raison que cela change. Même cause, même effet!

Alors l’équipe me regarde avec de grands yeux et nous entamons un dialogue qui ressemble au suivant :

- moi : « Ok, qui va le faire et quand? ».

- équipe : « Il faut rappeler X, mais il n’est pas très disponible. ».

- moi : « Qui subit l’impact de la carte bloquée? ».

- équipe : « C’est nous! ».

- moi : « Qui a intérêt à ce que la carte soit débloquée? ».

- équipe : « C’est nous! ».

- moi : « Ok, qui va appeler et quand? ».

Certaine fois, je n’ai pas fini de poser la question qu’il y a un volontaire pour prendre la responsabilité de régler le problème dès la fin du daily. D’autre fois la réponse est : « Je n’ai pas le temps maintenant, je regarde mon horaire dès la fin de la rencontre et j’y place cette tâche ».

[Quelques semaines plus tard...]

L’équipe adresse chaque jour les points bloquants avec une action portée par une personne et identifiée dans le temps. Et les cartes bloquées se libèrent icon wink Action = porteur + date

Êtes-vous toujours attentifs aux : « Il faut que? »

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

March 11th, 2010 Comments off
goulot d etranglement1 300x299 Mettre de la pression sur le système pour faire apparaître le gaspillage

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 WIP1

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 ?

  1. Work In Progress