Embedded Files
Post date: Feb 28, 2011 2:30:45 PM
Comme indiqué en début de séance le 17 février 2011, la valeur d'un jeu réside dans le feedback que l'on retire. Il est nécessaire de prendre le temps de disséquer les informations afin d'essayer de dégager la plus grande valeur. Comme il y a eu beaucoup de retours, cela n'a pas été facile de tout compulser, et cela m'a pris presque deux semaines. La liste des observations et des perles est disponible dans la page Fichiers . Il en ressort des choses assez voir très intéressantes et je vous remercie toutes et tous pour votre participation qui m'a permis de voir certaines chose. Je vais essayer de partager avec vous dans les lignes suivantes les idées qui me semblent intéressantes à partager.
Entraide
Sur ce point, mon avis est un peu mitigé. Je pense que sans appel du pied de Fabrice (qui voulait vraiment aider, le Scrum Master était là) les équipes n'auraient probablement pas partagé leur productivité (les dés) dès les premiers jets.
Mais au delà de ce petit point de démarrage, on a pu noter quand même que l'entraide ne naît pas comme cela.
Même si la plus part des participants se connaissaient déjà, il a fallu attendre la deuxième itération avant de voir les gens se lever, aller voir ce qui se passait en amont ou en aval sur la chaine. L'entraide n'est donc pas quelque chose de naturel, il faut aider les équipes à cultiver cette notion, et quoi de mieux que la transparence, des objectifs communs à atteindre ensemble. Dès lors, on a pu entendre des applaudissements lorsque les premières stories sortaient de la chaine. Est-ce que l'on peut dire que l'on a atteint à ce moment là une propriété commune du produit réalisé? Sentiment d'inutilitéIl semble que lorsque l'on aide une autre équipe, il y ait un sentiment d'inutilité : "Oh ben, on ne sert a rien nous", "C'est comme si tu payais un mec a ne rien faire".
Est-ce à dire que dans notre quotidien, nous n'aidons pas le reste de la chaine, les autres équipes, car cela nous donne un sentiment d'inutilité? Est-on jugé sur sa production personnelle ou sur la valeur produite collectivement (ici la chaine de production ou de l'équipe)?
Stress et Surproduction
Un point important visible lors du jeu et que les équipes stressent lorsque le travail s'accumule. Le fait de n'avoir rien produit sur un jour, "Ils sont pipés ces dés, on n'a pas fait de 1", fait que l'on veut produire plus immédiatement pour essayer de rattraper ce qui n'a pas été fait, "Filez-nous des dés!". C'est une réaction assez individualiste, car elle n'est pas basée sur une vision complète de la chaine mais juste de sa situation sur son poste. Est-il plus probable de finir plus (en valeur délivrée) si j'ai plus de production sur mon poste par apport de capacité complémentaire? A l'inverse cela montre que chacun a conscience qu'il est un élément dans la chaine de production et que s'il ne fait pas ce qu'il est censé faire, la totalité de la chaine est donc impactée. Peut-être est-ce le bon moment pour regarder quels sont les goulets d'étranglements avant d'augmenter la capacité?
Toujours sur ce thème, il y a eu un évènement assez important. A la fin du deuxième sprint, afin de donner le maximum de valeur ajouté, tout le monde a donné de la capacité de production au dernier poste. Cela part d'un sentiment collectif, on va y arriver. Mais cela ne prend pas en compte, que cela sert a rien, de mettre dix fois plus de capacité, cette capacité est perdue, alors qu'elle aurait pu servir a continuer a alimenter le plus de production. Est-il plus important à ce moment là de terminer une storie de plus, ou est-il plus important alimenter la chaine avec un flux continu?
Auto organisation
Il est apparu très vite qu'une stratégie de production était mise en place. Elle a eu comme très gros avantage que l'ensemble de l'équipe de production a tendu vers le même objectif. Il y a même eu lors du dernier sprint, l'apparition d'un daily meeting, pendant lequel on pouvait voir une courte discussion au sujet des postes où la production était a priori la plus critique. Cela a eu aussi pour conséquence, que l'équipe s'est mis tacitement d'accord sur la production de la moitié du produit. Le problème s'est que l'équipe que s'est auto organisé s'est refermée sur elle-même. A aucun moment, elle n'a demandé au product owner si ses décisions étaient en adéquation avec le besoin. Elle a perdue au fur et à mesure la notion de flux de productivité. Il n'y a avait pas ou pas toujours de valeur ajoutée délivrée. Pour moi, la grande leçon ici, et qu'il faut que l'équipe s'auto-organise, mais il doit y avoir quelqu'un qui la guide dans le processus afin qu'elle reste dans les objectifs attendus.Split ou pas SplitC'est le sujet de la soirée, je ne pouvais pas conclure sans en parler "Le split c'est démodé". L'expérience a montré qu'aucune storie entrée dans la chaine n'en est sortie sans avoir été splittée.
Cela confirme une chose que l'on savait déjà, mais c'est mieux de l'expérimenter : il est plus facile de travailler sur des petites tâches que sur des grosses. Une question aussi, qui a jaillit pendant le jeu. Quel est le bon niveau de granularité. A tout splitté jusqu'au niveau atomique (ici le 1), ne risque-t-on pas à un moment de passer plus de temps de production à découper qu'à produire? Il est sur qu'une tache à 12 est difficile a réaliser, et donc consommer une unité de production pour la couper semble un bon calcul. Pour une tâche qui coute deux unités de production, est-il une bonne idée de la découper? La valeur de travail pour faire cela est la moitié de ce qu'il faut pour finir le travail, donc est-ce un bon calcul? Voilà, je pense que cela ouvre un certain nombre de réflexions. A chacun de nous de voir au niveau des équipes dans lesquelles nous travaillons, si on retrouve les mêmes situations. Peut-être certains ont déjà abordés ces questions, ont déjà des idées qu'ils partageront avec nous?
Je n'ai peut-être pas tout vu dans les retours, je vous laisse le soin de disséquer à votre tour et de partager avec nous votre lecture des retours.
Et encore merci à tous pour tous ses enseignements....
Voir plus de Présentations de philAgile
Page updated
Google Sites
Report abuse