Ce dont le monde a besoin, c’est de plus de management lean

((/dotclear/public/photos/.MattiasSkarin_t.jpg|Mattias Skarin|L|Mattias Skarin))J’ai traduit ce billet de __Mattias Skarin__ : ++[« What the world needs is more lean management »|http://blog.crisp.se/mattiasskarin/2011/06/28/1309296251916.html]++.%%% > – Quelle est la capacité de vos équipes ? (ce qui est régulièrement livré)%%% > – Comment vous assurez-vous que cette capacité est en constante amélioration ?%%% > – Quel travail avez-vous du mal à faire, et que faites-vous pour résoudre ce problème ?%%% > %%% > Une des grandes illusions que nous a apporté la littérature sur le management, c’est que les managers  »gèrent les personnes ». Ce sont des leaders, qui embauchent des gens talentueux pour faire le travail. Lorsque ces gens talentueux ont des ennuis, on attend d’eux qu’il trouve une force intérieure pour surmonter les problèmes d’eux-mêmes. S’ils ne le font pas, le manager intervient et s’en charge.%%% > %%% > – Jeff n’a pas livré sa fonctionnalité à temps, il doit donc y avoir quelque chose qui ne va pas avec Jeff !%%% > – Roger se plaint des spécifications de mauvaise qualité qu’il reçoit (il doit y avoir quelque chose qui ne va pas avec Roger, puisque pour Jeff c’est aussi le cas).%%% > – Le manager a d’autres chats à fouetter que de s’occuper de résoudre les obstacles de l’équipe (personne au-dessus de lui ne lui a jamais demandé si les obstacles étaient résolus, mais évidemment, il doit y avoir quelque chose qui ne va pas avec ce manager).%%% > %%% > Vous commencez à voir ce que je veux dire. __Le problème, c’est que chaque problème est automatiquement transformé en un  »problème de personne ».__ Mais « Qu’en est-il des compétences alors ? ». Bien sûr, les compétences comptent pour beaucoup. Mais n’est-il pas un peu injuste de transformer » tous les problèmes » (problèmes de processus, problèmes de formation, …) en problèmes de personnes ? Et lequel de ces problèmes a-t-il en réalité vraiment été directement créé par le système que pilote le manager ?%%% > %%% > Donc, trouvons un meilleur moyen de gérer les choses :%%% > – des managers qui comprennent comment le travail est fait, en observant le travail,%%% > – des managers qui connaissent la capacité de leurs équipes,%%% > – des managers qui posent des questions, quand la capacité diminue,%%% > – des managers qui savent remettre en cause les hypothèses de départ, nous forçant à comprendre le problème avant de le résoudre,%%% > – des managers qui font ça tous les jours.%%% > %%% > C’est ce que j’appelle un manager Lean, une personne qui améliore la capacité de son organisation. Une personne qui va voir elle-même le travail réellement réalisé sur le terrain$$NdT : Genshi Genbutsu !$$. Cette attitude, cet état d’esprit, nous en redemandons… et moins de  »problèmes de personnes ».%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Agilement vôtre avec Alex et Claude

Il y aura vraiment moyen de se faire plaisir du 19 au 21 octobre avec __Alexandre Boutin__ et __Claude Aubry__ :%%% * Ils seront présents le 19 octobre à ++[l’Agile Tour Toulouse 2011|http://www.agiletoulouse.org/]++ ; Alex, invité d’honneur, ouvrira la session plénière d’introduction.%%% * Ils animeront une formation « Définition de Produit : Ateliers Agiles » à Toulouse le 20 octobre (plus d’infos sur ++[Innovation avec des jeux agiles, la formation|http://www.aubryconseil.com/post/Innovation-avec-des-jeux-agiles-la-formation]++ et ++[Formation « Jeux Agiles »|http://www.agilex.fr/2011/06/formation-jeux-agiles/]++).%%% * Ils seront présents le 21 octobre à ++[l’Agile Tour Bordeaux 2011|http://agiletourbordeaux.okiwi.org/]++.%%% %%% Je ne fais pas de commerce… je vous invite juste à optimiser votre calendrier agile avec 2 persuadeurs agiles !%%% %%% __Inscrivez-vous !__%%% %%% [((/dotclear/public/affiches/.affiche-alex-et-claude_m.jpg|Agilement vôtre : Alex et Claude||Agilement vôtre : Alex et Claude))|/dotclear/public/affiches/affiche-alex-et-claude.png]

Atteindre la stabilité d’abord

((/dotclear/public/photos/.photo_art_smalley_sq.jpg|Art Smalley|L|Art Smalley))J’ai traduit cet article de Art Smalley : ++[Achieving Basic Stability|http://www.leaninstituut.nl/publications/achieving_basic_stability.pdf]++.%%% > __Introduction__%%% > %%% > Le mode de production lean a considérablement élevé le niveau de compétitivité de nombreuses entreprises industrielles ainsi que le niveau de valeur livrée à leurs clients. Par ailleurs, cela a encouragé les nouveaux entrants à embrasser le lean dans des activités ne concernant pas la fabrication au sens industriel du terme, comme par exemple le développement de produits, les achats, la gestion de la chaîne logistique et l’ingénierie.%%% > %%% > En dépit de ces succès, de nombreuses entreprises que je visite sont restées bloquées au stade de leurs efforts initiaux vers le lean. Elles essaient de créer un flux mais sans conviction. Il y a plusieurs raisons à ce manque de progrès. Les plus communes sont un manque de leadership, de ressources, ou d’engagement. Mais le piège que je vois le plus souvent est un manque de stabilité au départ dans les opérations de fabrication. Tout simplement, les processus ne peuvent pas fonctionner à cause d’éléments clés des équipements qui sont en panne.%%% > %%% > __Premiers combats de Toyota__%%% > %%% > Taiichi Ohno, l’architecte en chef du lean manufacturing, a développé les principes de base chez Toyota Motor Corporation au Japon entre 1950 et 1955. Pendant cette période d’apprentissage de cinq ans, Ohno réalisa des expériences dans les ateliers de production intensive qu’il gérait. Les concepts clés tels que le takt time$$NdT : Takt time = rythme auquel les produits doivent sortir du système pour satisfaire exactement la demande$$, le flux, le travail standardisé, le changement rapide d’outils$$NdT : SMED = Single Minute Exchange of Die – la clé pour réduire la taille de lots de production$$ et les mécanismes de base d’un système à flux tirés furent tous découverts et testés sous son contrôle.%%% > %%% > Malheureusement, très peu a été écrit sur ce qu’a fait Ohno. Aujourd’hui nous entendons seulement parler des succès du lean et de la nature impressionnante du Toyota Production System. Les entretiens que j’ai eus avec des cadres de Toyota à la retraite m’ont conduit à adopter une perspective différente sur la difficulté à établir les bases du lean. Ces commentaires sont des réflexions typiques :%%% > %%% > « Notre processus de changement rapide d’outils était absolument terrible, et prenait, où qu’on soit, un à deux postes$$NdT : Le travail posté est la forme d’organisation du travail où des équipes se relaient au même poste les unes après les autres. Une forme fréquente de travail posté est l’organisation en 3 × 8.$$ pour être terminé. Ensuite, la qualité de production n’a jamais été aussi bonne. »%%% > %%% > « Nos machines-outils à commande numérique étaient toutes en provenance d’Allemagne ou des États-Unis. Notre durée de fonctionnement tournait en moyenne autour de 50 à 60% au mieux, et nous avions beaucoup de mal avec la documentation étrangère et la livraison de pièces de rechange en provenance de l’étranger. »%%% > %%% > « Nous n’avons jamais eu les pièces dont nous avions besoin produites au moment où nous en avions besoin. Le matériel était rare, et il semblait que nous accordions toujours beaucoup trop d’importance aux mauvaises choses. »%%% > %%% > « Nos employés voulaient uniquement faire fonctionner une seule machine et travailler à leur propre rythme. Des montagnes de WIP$$NdT : WIP = Work-in-Progress ; TAF = Travail à Faire$$ apparaissaient entre les processus étant donné que la vitesse des machines n’étaient pas du tout synchronisée sur le rythme de la demande clients (takt time). »%%% > %%% > Les personnes qui déploient la démarche Lean devraient se sentir motivées par ces premiers combats menés chez Toyota. Personne n’a jamais dit que faire des améliorations/changements radicaux était un processus facile. Ce que Toyota a appris sur ce dur parcours, c’est qu’au début d’une transformation, vous avez besoin de beaucoup de stabilité avant de pouvoir réussir avec les éléments les plus sophistiqués du lean.%%% > %%% > __Étapes de mise en œuvre du Lean__%%% > %%% > Toyota a été réticent à publier ou même approuver ce qu’il considère être la bonne façon de mettre en œuvre le Lean. Leur réticence est normale compte tenu de notre tendance humaine inhérente à chercher un moyen facile de copier-coller des réponses d’ailleurs. Les cadres de Toyota ont toujours affirmé que le TPS/lean était un système de pensée et que ses pratiquants devenaient meilleurs lorsqu’ils « apprenaient en faisant ».%%% > %%% > Lorsqu’on insiste, cependant, les vétérans de Toyota précisent que certaines conditions préalables sont nécessaires pour que la démarche de mise en œuvre lean se passe en douceur. Il s’agit notamment d’y intégrer quelques problèmes concernant la disponibilité de l’équipement, le matériel disponible mais avec quelques anomalies, et une supervision poussée au niveau de la ligne de production. Et ce sont précisément ces problèmes auxquels je vois encore les industriels se heurter aujourd’hui.%%% > %%% > Évidemment, si nous devions attendre que tous ces problèmes soient résolus, nous n’aurions jamais commencé. Le fait de mettre en œuvre des éléments lean éliminera certains de ces problèmes. Nous avons donc un problème de serpent qui se mord la queue : par où allons-nous commencer ?%%% > %%% > Une piste provient de la façon dont Toyota travaille avec de nouveaux fournisseurs situés à l’étranger. Les consultants en production Toyota suivent généralement (mais pas de façon dogmatique) un framework permettant d’établir cette stabilité au départ, d’améliorer le processus, de rythmer le travail selon le takt time, de développer un système à flux tirés est de lisser la production. La mise en œuvre effective dépend du contexte courant et selon les propres mots de Ohno, 50 ans auparavant, qui conseille à tous de « commencer et cibler vos efforts sur votre besoin le plus crucial ». Pour de nombreuses industries, cela signifie de travailler davantage sur la stabilité au départ avant d’essayer d’atteindre le flux de travail parfait.%%% > %%% > __La stabilité d’abord__%%% > %%% > Alors, c’est quoi la stabilité ? Au départ, cela implique une prédictibilité et une disponibilité constante en termes de main d’œuvre, de machines, de matériel et de méthodes – les __4Ms__. Sous chacune de ces briques techniques de la fabrication, Toyota a tenté d’établir un processus cohérent et prédictible, avant d’aller trop loin avec les éléments que sont le flux et le takt time.%%% > %%% > La raison est simple. Sans les éléments fondamentaux comme la disponibilité machine ou les ressources humaines en place, vous ne pouvez pas exécuter une ligne de production et atteindre un flux parfait ou rythmer selon le takt time. Par exemple, produire selon un takt time et atteindre un flux parfait requiert un niveau suffisant de disponibilité machine. La même chose est vraie pour le reste des 4Ms.%%% > %%% > Comment savez-vous si vous avez suffisamment de stabilité dans les opérations concernées par le flux ? La réponse dépend de votre capacité à répondre à quelques exigences clés :%%% > %%% > – Avez-vous une disponibilité machine suffisante pour produire la demande clients ?%%% > – Avez-vous suffisamment de matériel sur place chaque jour pour répondre à vos besoins de production ?%%% > – Avez-vous assez d’employés formés sur place pour gérer les processus en cours ?%%% > – Avez-vous des méthodes de travail définies comme des instructions de bases ou des standards en place ?%%% > %%% > Si la réponse à l’une de ces questions est catégoriquement « non », arrêtez-vous et réglez le problème avant de continuer. Tenter de produire exactement la demande clients avec des employés non formés, une supervision défaillante, ou un stock limité sur place est la recette qui mène au désastre.%%% > %%% > Inversement, vous ne devriez pas tomber dans le piège d’utiliser ces questions comme des excuses pour ne pas avancer. Rappelez-vous, vous n’avez pas besoin d’une disponibilité parfaite pour répondre à la demande clients. Si, par exemple, le takt time de l’assemblage est de 60 secondes et que le temps de cycle du processus machine amont est de 30 secondes, alors vous n’aurez besoin que de quelques stocks pour agir comme tampon et un peu mieux que 50% de disponibilité pour commencer à établir un meilleur flux de production au rythme du takt time. Le même bon sens peut aussi s’appliquer aux autres 4 Ms. Si la ligne de production a besoin de huit personnes pour fonctionner et que vous n’avez constamment à disposition que six personnes formées pour faire le travail, alors vous avez un problème de stabilité au départ.%%% > %%% > __Atteindre la stabilité__%%% > %%% > Pour parvenir à la stabilité au départ, vous devez vous concentrer sur quatre éléments clés correspondant aux 4Ms.%%% > %%% >  »1. Main-d’œuvre »%%% > %%% > En lean, la stabilité commence avec une main-d’œuvre bien formée. Heureusement, les employés ont tendance à très bien connaître leur travail, sinon nous aurions de très graves problèmes. Toutefois, Toyota, dans les années 1950, a appris quelques techniques de base pour superviser la production et sur la manière d’améliorer les compétences et les capacités des équipes. Plus précisément, ils ont adopté un programme de formation industrielle que les États-Unis ont utilisé pendant la Seconde Guerre Mondiale et qui s’appelle « La formation au sein de l’industrie »$$NdT : TWI = Training Within Industry$$. Ce programme est composé de trois modules de formation professionnelle dédiés aux superviseurs de production : les instructions dans le travail, les méthodes dans le travail et les relations dans le travail. Chaque module était un cours de dix heures dans lequel on enseignait des compétences pratiques en supervision.%%% > %%% > Le module instructions dans le travail$$NdT : Job instruction (JI)$$ enseignait aux superviseurs la façon de planifier les ressources appropriées dont ils auraient besoin dans la production, comment décomposer le travail pour rédiger les instructions et comment enseigner aux individus en toute sécurité, correctement et consciencieusement. Le module méthode dans le travail$$NdT : Job methods (JM)$$ enseignait aux superviseurs la manière d’analyser le travail et d’apporter des améliorations simples à l’échelle de leur domaine. Chaque activité était inspectée pour être améliorée si nécessaire. Les superviseurs apprenaient à se demander pourquoi une activité était réalisée d’une certaine manière, et si elle pouvait être éliminée, combinée avec autre chose, réarrangée, ou simplifiée. Le module relations au travail$$NdT : Job relations (JR)$$ enseignait aux superviseurs la manière de traiter les gens comme des individus et de résoudre les problèmes fondamentaux de l’homme liés à la production plutôt que de les ignorer.%%% > %%% > Pris ensemble, ces trois modules aident les superviseurs à créer une routine, une discipline et un sens de l’équité dans les équipes. Cinquante ans plus tard, ces mêmes modules constituent la base fondamentale pour la formation des superviseurs et des équipes chez Toyota.%%% > %%% >  »2. Machines »%%% > %%% > Vous n’avez pas besoin d’équipement avec une disponibilité parfaite, mais vous devez connaître votre demande clients, la capacité de votre processus et la production moyenne réelle.%%% > %%% > Toyota utilise un document de base appelé la feuille de capacité du processus pour mesurer le potentiel de production réelle d’un processus durant un poste. Si vous avez la capacité théorique ainsi que la capacité constatée à satisfaire la demande clients, alors il n’y a pas de problème. C’est seulement quand vous n’avez aucune capacité constatée à répondre à la demande que vous avez un problème de stabilité sur les machines. Par exemple, si la demande clients est de 700 unités par poste et que votre production réelle est seulement de 500 unités malgré une capacité théorique de 1000, alors vous avez besoin de plus de disponibilité.%%% > %%% > Dans de tels cas, Ohno a effectivement eu des gens debout devant la machine problématique sur l’ensemble des huit heures du poste pour régulièrement enregistrer la production réelle toutes les 15 minutes à 1 heure par rapport à la production planifiée. A la fin du poste, toutes les pertes et les raisons réelles associées étaient identifiées sur un diagramme de Pareto. De simples et rapides réunions étaient menées si nécessaire et des plans d’amélioration mis en place. C’est le respect par essence du « Genba » (terme japonais pour qualifier l’endroit où s’effectue réellement le travail) chez Toyota.%%% > %%% >  »3. Matériels »%%% > %%% > En général, le but du lean est de réduire les gaspillages et de raccourcir le délai entre le moment où une commande est reçue jusqu’au moment où elle est produite. Normalement, cela nécessite la réduction des stocks dans la chaîne de valeur. Si vous souffrez d’une instabilité fondamentale, cependant, vous pouvez avoir besoin d’accroître les stocks à court terme dans certains endroits ou dans certains cas.%%% > %%% > La raison c’est que pour certains processus, vous pouvez produire pièce à pièce ou de très petites quantités. Pour les procédés par lot, toutefois, une certaine quantité de stocks est nécessaire pour couvrir le moment où les autres processus sont en cours d’exécution, ou des outils sont changés.%%% > %%% > La quantité de stocks dont vous avez besoin est composé de ce que Toyota appelle le stock du cycle de commande (la quantité de stocks nécessaire pour couvrir la demande moyenne et le lead time pour reconstituer le stock), le stock tampon (la quantité de stocks pour couvrir les variations qui pourraient exister dans votre flux aval ou dans la demande clients), et le stock de sécurité (la quantité de stocks pour couvrir les pertes comme les rejets ou les temps d’arrêt que vous avez actuellement). Il serait déraisonnable de pas tenir compte de ces stocks tampon et de sécurité dans un environnement instable, cela nuirait sérieusement à l’efficacité de ligne de production.%%% > %%% > J’ai été frappé par deux conseils que l’on m’a donné sur ce sujet chez Toyota. Premièrement, tous les stocks ne constituent pas des gaspillages. Seuls les stocks au-delà ce qui est nécessaire pour exécuter le processus sont considérés comme un gaspillage. Deuxièmement, le stock existe souvent comme le symptôme d’un problème dans le processus. Résoudre le problème vous donne le droit de réduire le stock.%%% > %%% >  »4. Méthodes »%%% > %%% > Enfin, atteindre la stabilité au départ nécessite d’avoir des méthodes standards pour la fabrication. Le point clé ici est la définition d’un standard. La définition normale est qu’un standard est une règle ou une façon de faire les choses. L’effet secondaire involontaire est que les gens ne sont pas encouragés à remettre en question ou à modifier la règle. « Nous le faisons de cette façon parce que c’est la norme dans notre entreprise » est une phrase que j’entends souvent.%%% > %%% > La définition d’un standard chez Toyota est légèrement différente. Un standard est une « règle ou une base de comparaison ». Un standard n’est rien de plus qu’un outil pour mesurer la manière dont nous faisons quelque chose et auquel se référer lorsque nous souhaitons changer quelque chose. La pensée Lean traite du changement des méthodes de travail afin d’éliminer les gaspillages et apporter des améliorations. Les standards sont ce que nous utilisons pour mesurer et comparer nos changements afin que nous sachions si la nouvelle voie est meilleure ou non.%%% > %%% > Ce système de pensée basé sur l’amélioration est enraciné dans la tête de tous les employés de Toyota depuis le premier jour. Chacun est encouragé à faire des changements. Cependant, le changement n’est seulement mis en œuvre et maintenu que s’il bat l’ancien standard, c’est ce que l’on appelle à proprement parler le kaizen.%%% > %%% > __Résumé__%%% > %%% > Il y a beaucoup d’autres éléments de stabilité qui se cache sous chacun des 4Ms de Toyota. Par exemple, les méthodes peuvent être élargies afin d’inclure les cinq S, le contrôle visuel, le déjà célèbre tableau de travail standardisé et d’autres outils simples de gestion du travail. Et nous pourrions même ajouter un cinquième M pour Métriques. Le dernier point c’est que comme beaucoup d’entre nous aujourd’hui, Toyota s’est vigoureusement battu pour mettre en œuvre une démarche de production lean. Sur le chemin, Toyota a découvert que vous avez souvent besoin d’une bonne dose de stabilité au départ donc avant de pouvoir avancer sur les autres éléments du lean. Tout comme nous avons besoin de ramper et de marcher avant de pouvoir courir, les entreprises constatent souvent qu’elles ont besoin d’améliorer leur stabilité au départ avant de parfaire un système à flux tiré.%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Rétrospective Soirée Devops, Scrum & Kanban du 24 juin 2011

((/dotclear/public/logos/badge-fsug.jpg|Badge FSUG||Badge FSUG))%%% !!What went well%%% * __Laurent Morisseau__ a ouvert le bal avec une introduction à Kanban illustrée par ses retours d’expérience dans trois projets significatifs qu’il a accompagné (migration et recette usine) et par une démarche circulaire en 5 étapes : 1°Identifier la valeur, 2°Identifier la chaîne de valeur, 3°Créer un flux continu pièce à pièce, 4° Établir un flux tiré et 5°Rechercher la perfection. Il a parfaitement lancé les deux sujets qui devaient suivre.%%% * __Dominica DeGrandis__, associée chez David J Anderson & Associates, nous a fait un grand retour d’expérience sur l’amélioration d’une gestion de configuration grâce à Kanban. Beaucoup de messages sur l’humain.%%% * Concernant notre présentation « Scrum & Kanban : tirer le meilleur des deux », __Antoine Vernois__ et moi avons eu de nouvelles questions (par rapport à l’Agile Tour Toulouse 2010 et au Scrum Day 2011) : on a bien tous cogité ensemble, c’était agréable 🙂 Ah oui, j’oubliais : ne soyez pas dogmatique, essayez par vous-même ! soyez agile !%%% * Discussion intéressante avec __Martin Sudmann__ sur l’utilisation de Scrum et Kanban chez PriceMinister.%%% * Conversation à bâtons rompues avec Antoine et __Xavier Warzee__ dans un bar de la capitale jusqu’à 1 heure du matin !%%% !!What went wrong%%% * Batterie du HTC à plat, plus possible de prendre des photos !%%% * Rentré à 2h à l’hôtel, levé à 6h30 et train à 7h30, arrivé à 11h à Bordeaux… grosse fatigue !%%% !!Puzzles%%% * Qui veut sponsoriser le French Scrum User Group ? immergez-vous dans la communauté agile !%%% * ++[Laurent Lemoine|http://jeu-symbiose.blogspot.com/search/label/equipe]++, gamer chez multimondes.net ? j’attends l’ouverture du site.%%% * J’ai invité __Caroline Damour__, Product Owner chez Vidal, à venir parler de son travail à l’Agile Tour Bordeaux ++2012++… viendra-t-elle ? * CDD ? Chaos Driven Development.%%% * Difference between 2h meeting and 2h movie ? emotion… people are polite in meeting, they don’t say what they think.%%% !!Lessons (re-)learnt%%% * La démarche Lean est une démarche d’amélioration continue « petits pas ».%%% * Laissez vivre le système, mettez-le sous contrainte puis expérimentez au fur et à mesure.%%% * Knowledge work is perishable.%%% * Trust is essential, so increase level of trust for influencing change.%%% * Good to have the what but would have been better to include the why to understand the bigger picture for flow.%%% * Belonging to a team is a behavior.%%% * Transparency = Trust – Vulnerability = Empathy.%%% * Quality doesn’t happen with 5 hours of sleep !%%% * Tolerance for process exploration… brought understanding.%%% * A focus on cutting costs actually results in higher costs.%%% * Kanban : all the work is on the board.%%% * Work item flows across different functions of all departments of the enterprise.%%% * Management must create a way for improvements to occur, but it’s not free.%%% !!Appreciations%%% * Merci à Microsoft de nous avoir accueilli dans ses (superbes) locaux, il y avait un buffet !%%% * Merci aux organisateurs : le French Scrum User Group, notamment Xavier Warzee.%%% * Merci aux orateurs : Dominica, Laurent, Xavier (guest) et Antoine.%%% * Merci aux participants : Caroline, Emilie, Oana, Alexis, Laurent, Luc, Christophe, Martin, Lucian, Gilles, Yannick, Mohammed, … et tous les autres !%%% !!Links%%% * Livre ++[Kanban and Scrum – making the most of both|http://www.infoq.com/minibooks/kanban-scrum-minibook]++, traduit en 8 langues à ce jour.%%% * Livre ++[Death by Meeting|https://www.amazon.fr/Death-Meeting-Leadership-Solving-Business/dp/0787968056/ref=sr_1_5?ie=UTF8&qid=1309015597&sr=8-5|en]++ de Patrick Lencioni.%%% * T-Shirt Limited WIP Society : ++[« Yes We Kanban »|http://www.cafepress.com/ltdwipsociety.402743105]++%%% * Site ++[French Scrum User Group|http://www.frenchsug.org/display/FRSUG/French+Scrum+User+Group]++%%% * Site ++[David J Anderson & Associates|http://www.agilemanagement.net/|en]++%%% * Site ++[Laurent Morisseau|http://www.laurentmorisseau.com/]++%%% * Yahoo! group ++[KanbanOps|http://tech.groups.yahoo.com/group/kanbanops/|en]++%%% * Twitter Dominica DeGrandis ++[@dominicad|https://twitter.com/#!/dominicad]++%%% !!Feedback :%%% * Antoine Vernois : ++[24 juin 2011 — Scrum, Kanban et Devops au Scrum User Group France|http://antoine.vernois.net/dotclear/index.php?post/2011/06/25/24-juin-2011-Scrum,-Kanban-et-Devops-au-Scrum-User-Group-France]++%%% * Xebia (/ Gilles Mantel) : ++[Compte rendu de la soirée Kanban Devops du French SUG|http://blog.xebia.fr/2011/06/28/revue-de-presse-xebia-217/#CompterendudelasoireKanbanDevo]++%%% * Laurent Morisseau :%%% ** ++[Soirée Devops, Scrum & Kanban avec le French SUG|http://www.laurentmorisseau.com/2011/06/soiree-devops-scrum-kanban-avec-le.html]++%%% ** ++[Une démarche Kanban pour un enjeu Lean|http://www.laurentmorisseau.com/2011/07/une-demarche-kanban-pour-un-enjeu-lean.html]++%%% ** ++[Une démarche Kanban pour un enjeu Lean – partie 2|http://www.laurentmorisseau.com/2011/07/une-demarche-kanban-pour-un-enjeu-lean_05.html]++%%% ** ++[Une démarche Kanban pour un enjeu Lean – partie 3|http://www.laurentmorisseau.com/2011/07/une-demarche-kanban-pour-un-enjeu-lean_07.html]++%%% * Anne Gabrillagues : ++[Retours sur la soirée “DevOps, Scrum et Kanban” du French Scrum User Group|http://blog.ippon.fr/2011/09/01/retours-sur-la-soiree-devops-scrum-et-kanban-du-french-scrum-user-group/]++%%% %%% [((/dotclear/public/fsug/.opera_s.jpg|Opéra Garnier||Opéra Garnier))|/dotclear/public/fsug/opera.jpg] [((/dotclear/public/fsug/.microsoft_s.jpg|Microsoft||Microsoft))|/dotclear/public/fsug/microsoft.jpg] [((/dotclear/public/fsug/.programme_s.jpg|Programme de la soirée Devops, Scrum et Kanban||Programme de la soirée Devops, Scrum et Kanban))|/dotclear/public/fsug/programme.jpg] [((/dotclear/public/fsug/.dominica-et-xavier_s.jpg|Dominica DeGrandis et Xavier Warzee||Dominica DeGrandis et Xavier Warzee))|/dotclear/public/fsug/dominica-et-xavier.jpg] [((/dotclear/public/fsug/.laurent-et-xavier_s.jpg|Laurent Morisseau et Xavier Warzee||Laurent Morisseau et Xavier Warzee))|/dotclear/public/fsug/laurent-et-xavier.jpg] [((/dotclear/public/fsug/.demarche-kanban_s.jpg|Démarche Kanban||Démarche Kanban))|/dotclear/public/fsug/demarche-kanban.jpg] [((/dotclear/public/fsug/.chaine-de-valeur_s.jpg|Chaîne de valeur||Chaîne de valeur))|/dotclear/public/fsug/chaine-de-valeur.jpg] [((/dotclear/public/fsug/.chicago-1901_s.jpg|Chaos Driven Development : Chicago, 1901||Chaos Driven Development : Chicago, 1901))|/dotclear/public/fsug/chicago-1901.jpg] [((/dotclear/public/fsug/.phenomene-hibou_s.jpg|Méfiez-vous des hiboux la nuit !||Méfiez-vous des hiboux la nuit !))|/dotclear/public/fsug/phenomene-hibou.jpg] [((/dotclear/public/fsug/.casquettes_s.jpg|3 casquettes (Kanban, ScrumBan et Scrum)||3 casquettes (Kanban, ScrumBan et Scrum)))|/dotclear/public/fsug/casquettes.jpg]%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes rétrospectives sur le wiki ++[Rétrospectives Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/retrospective:start]++.

Il ne s’agit pas simplement de rester debout : les bonnes pratiques du Daily Stand-up Meeting

J’ai traduit cet article très détaillé de__ Jason Yip__ de la société ThoughtWorks, Inc. : ++[« It’s Not Just Standing Up: Patterns of Daily Stand-up Meetings »|http://martinfowler.com/articles/itsNotJustStandingUp.html|en]++.%%% > ((/dotclear/public/traductions/.standingup_m.jpg|Se tenir debout||Se tenir debout))%%% > %%% > __1. Nous restons debout pour que la réunion reste courte__%%% > %%% > Le daily stand-up meeting (aussi connu sous le nom de « mêlée/scrum quotidien(ne) »$$daily scrum$$, « regroupement quotidien »$$daily huddle$$, « appel du matin »$$morning roll-call$$, etc.) est simple à décrire: l’équipe entière se réunit tous les jours pour une mise à jour rapide de l’état d’avancement des tâches. Nous restons debout pour que la réunion reste courte. C’est tout. Mais cette définition rapide ne vous aide pas vraiment à comprendre les subtilités qui distinguent un bon stand-up d’un mauvais.%%% > %%% > Compte tenu de l’apparente simplicité du stand-up, j’ai été assez surpris la première fois quand j’ai vu que cela ne fonctionnait pas. Ce qui n’allait pas m’a immédiatement paru évident, mais j’ai réalisé que ce n’était pas aussi évident pour l’équipe. J’ai réalisé que mon équipe n’avait pas conscience des principes sous-jacents et des détails qui leur permettraient de diagnostiquer et de résoudre les problèmes liés aux stand-ups.%%% > %%% > Les gens qui ont connu de bons stand-ups sauront généralement quoi faire quand les choses ne fonctionnent pas bien. Lorsque que les choses tournent mal, les participants qui débutent ne comprendront probablement pas ce qu’il faut faire. Une façon d’aborder ce problème est de prétendre que tout est une question de connaissances tacites et que les débutants ont juste besoin de participer à davantage de stand-ups qui se passent bien. Je crois, cependant, qu’il est beaucoup plus probable que, si on ne les aide pas, les débutants abandonneront purement et simplement la pratique du daily stand-up. Ce serait regrettable puisque des stand-ups bien exécutés ajoutent une valeur significative aux projets.%%% > %%% > Je tente ici de communiquer certaines des connaissances tacites que j’ai pu acquérir sur les bénéfices et les conséquences de bonnes pratiques pour mener les daily stand-ups. Ces bonnes pratiques de daily stand-up meetings sont destinées à aider les nouveaux pratiquants ainsi qu’à rappeler aux pratiquants expérimentés ce qu’ils savent déjà en leur for intérieur.%%% > %%% > __2. Le thème sous-jacent est l’auto-organisation__%%% > %%% > Le thème sous-jacent aux daily stand-up meetings est l’auto-organisation. Ce n’est pas juste parce que l’auto-organisation conduit à une meilleure productivité, mais aussi, et peut-être plus encore, parce qu’elle génère un environnement de travail plus humain, respectueux et évolué. Bon nombre des problèmes qui surgiront durant l’exécution d’un bon stand-up sont liés à une mauvaise compréhension de cette motivation sous-jacente à l’auto-organisation.%%% > %%% > L’auto-organisation n’est pas une vertu propre à une culture, qu’il s’agisse d’une équipe, d’une organisation, ou d’un pays. Si l’équipe entière ne s’engage pas à prendre la responsabilité de son propre succès, sa performance va forcément empirer.%%% > %%% > __3. Quel est le but d’un daily stand-up meeting ?__%%% > %%% > Si l’on fait la synthèse de plusieurs documents et références ([Anderson, 2002], [Beedle et al., 2000], [Cochango, 2006], [OrgPatternsStandUp], [Rising, 2002], [Rising et Janoff, 2002], [Wells, 1999]), les daily stand-ups doivent atteindre les objectifs suivants :%%% > %%% > __3a. S’engager ensemble__%%% > %%% > Prendre des engagements quotidiens les uns envers les autres, comme une équipe, est l’objectif le plus important des daily stand-ups. Partager les engagements est plus important que partager un état d’avancement. Cela ne veut pas dire qu’un observateur ne verra pas ressortir l’état d’avancement d’un stand-up, mais cela reste secondaire pour les membres des équipes qui s’engagent publiquement les uns envers les autres et qui identifient les obstacles qui les empêchent de respecter leurs engagements.%%% > %%% > __3b. Communiquer l’état d’avancement__%%% > %%% >  »L’objectif de ces réunions est de communiquer sur l’état d’avancement en termes d’architecture et de plan de production. [OrgPatternsStandUp] »%%% > %%% > Ce n’est pas le fait de communiquer sur l’état d’avancement qui différenciera les stand-ups des autres types de réunions d’avancement. Ce qui fait la différence c’est le mécanisme qu’utilise les stand-ups pour communiquer l’état d’avancement, à savoir les membres de l’équipe se synchronisent entre eux plutôt qu’avec leur manager. Actualiser quotidiennement l’état d’avancement permet également à l’équipe de réfléchir sur ce qu’elle va faire à un rythme quotidien, au minimum.%%% > %%% > __3c. Identifier les obstacles__%%% > %%% >  »Lorsqu’un membre de l’équipe partage un obstacle lors d’une réunion Scrum, l’équipe entière se penche sur ce problème. Parce que les membres de l’équipe travaille de concert vers un objectif commun, chaque membre de l’équipe doit coopérer pour atteindre cet objectif. Toute l’équipe s’approprie instantanément les problèmes de chacun des individus qui la composent. [Rising et Janoff, 2000] »%%% > %%% > Identifier et éliminer les obstacles le plus tôt possible permet à l’équipe de maintenir son rythme. Le stand-up en lui-même n’est pas destiné à éliminer les obstacles, mais plutôt à fournir un forum permettant aux personnes d’identifier les obstacles afin que les autres membres de l’équipe aient la possibilité de les aider.%%% > %%% > __3d. Donner la direction et se concentrer dessus__%%% > %%% >  »Pendant les daily meetings, le Scrum master prêtera attention à la priorité des items du backlog. C’est particulièrement utile pour les nouveaux membres de l’équipe, qui pourraient partir dans une autre direction. [Rising et Janoff, 2000] »%%% > %%% > Nous souhaitons que tout le monde aille dans la même direction. Le stand-up est utilisé pour rappeler cette direction continuellement à l’équipe.%%% > %%% > __3e. Construire une équipe__%%% > %%% > Si l’on va plus loin que les exercices artificiels de « construction d’équipe », des équipes efficaces sont construites en communiquant régulièrement, en travaillant et en s’entraidant. Ceci est également fortement lié au fait que les membres de l’équipe s’entraident sur la base des obstacles partagés. L’équipe est consciente des problèmes de chacun en particulier parce qu’elle en entend parler tous les jours (jusqu’à ce que le problème soit résolu). Cet environnement encourage les gens à identifier les problèmes et à aider les autres.%%% > %%% > __4. Les daily stand-up meetings efficaces génèrent un sentiment particulier__%%% > %%% > Techniquement, la réunion est un « daily stand-up » si tout le monde est debout et si la réunion a lieu tous les jours. Cependant, il y a une différence entre un bon stand-up et un rituel vide de sens.%%% > %%% > Une ancienne description des daily stand-up meetings les appellent Daily Scrums [Beedle et al., 2000] en les associant volontairement au rugby. Le niveau d’énergie d’un daily stand-up n’est peut-être pas aussi élevé que celui d’une mêlée de rugby, mais cela doit rester énergisant. La __rapidité__ et un __haut niveau d’énergie__ servent l’objectif de concentrer l’équipe vers la bonne direction. Des réunions longues avec un faible niveau d’énergie ont tendance à perturber et même à pénaliser la journée.%%% > %%% > De bons stand-ups reposent sur la __solidarité__. Si les gens sont démolis à chaque fois qu’ils remontent un problème, ils auront tendance à arrêter de le faire. Au-delà de l’élimination des obstacles, un stand-up n’apportant aucun soutien aux membres de l’équipe va à l’encontre de la dynamique de l’équipe. Dans ce cas, le stand-up devient plutôt un rituel craint par les membres de l’équipe [LaPlante, 2003].%%% > %%% > Lorsque les choses vont bien, il n’y a plus vraiment besoin de faciliter le stand-up. Un bon stand-up doit être perçu comme étant __auto-géré__.%%% > %%% > __5. Les bonnes pratiques du Daily stand-up meeting__%%% > %%% > __5a. Qui participe au daily stand-up ?__%%% > %%% > __5a1. Tout le monde__%%% > %%% > Les gens et les représentants des divers services (par exemple le marketing, l’exploitation, la direction générale, la formation, etc.) souhaitent connaître et/ou contribuer à l’état d’avancement du projet. Communiquer l’état d’avancement dans de multiples réunions et reportings nécessite beaucoup d’efforts redondants.%%% > %%% > __ »Par conséquent »__%%% > %%% > Remplacez une partie ou l’ensemble des réunions et des reportings par le daily stand-up. Toute personne qui est directement impliqué ou qui veut connaître la marche au jour le jour du projet devrait assister à l’unique et quotidien daily stand-up meeting.%%% > %%% > __ »Mais »__%%% > %%% > Les gens qui ne sont pas directement impliqués peuvent perturber le stand-up. Cela veut donc dire qu’un autre forum serait encore nécessaire pour les questions hors du périmètre du stand-up.%%% > %%% > Trop de gens dans la réunion peuvent provoquer des perturbations et/ou mettre mal à l’aise les gens dans le fait de partager les informations. Les daily stand-ups classiques seront commposés d’au plus 10 personnes. Pour des groupes de plus grosse taille, il est encore plus important de faire respecter la __Politique des Cochons et des Poulets__ et __Traitez le sujet à part__ afin de s’assurer que tous les contributeurs peuvent fournir les informations au moment opportun.%%% > %%% > Le format du stand-up ne pourra – ne devrait – pas couvrir toutes les formes de reporting. Par exemple, l’état d’avancement de l’ensemble du projet serait mieux transmis à l’aide d’un Gros Graphique Visible$$Big Visible Chart$$ [Jeffries, 2004] tels qu’un burn-down, un burn-up, un diagramme de flot cumulé, etc.%%% > %%% > __5a2. Cochons et poulets__%%% > %%% >  »Un poulet et un cochon sont ensemble quand le poulet dit : « Créons un restaurant ! ». »%%% >  »Le cochon réfléchit et dit : « Comment appellerions-nous ce restaurant ? ». »%%% >  »Le poulet dit : « Jambon & Oeufs ! ». »%%% >  »Le cochon dit : « Non merci, je serais personnellement engagé, alors que toi tu ne serais qu’impliqué ! ». »%%% >  »[Schwaber et Beedle, 2001] »%%% > %%% > Lors d’un stand-up, les observateurs peuvent perturber la communication au sein de l’équipe. Ces perturbations peuvent se traduire sous la forme d’interruptions ou simplement en participant et en fournissant des informations inappropriées. Si la perturbation est suffisamment grave, les membres de l’équipe soit ne prendront pas la peine d’utiliser le stand-up pour communiquer sur les problèmes du projet, soit créeront même une autre instance, soit ne communiqueront plus du tout.%%% > %%% > __ »Par conséquent »__%%% > %%% > Instituer une règle où seules les « personnes engagées » participent et les « personnes impliquées » sont uniquement autorisées à observer. « Engagé » désigne toutes les personnes qui contribuent au fait de terminer l’itération courante (c’est à dire, les développeurs, les testeurs, les managers de proximité, etc.). En d’autres termes, les gens qui peuvent dire quelque chose qui affecte directement le backlog d’items/features/stories. « Impliqué » désigne les autres personnes qui peuvent être intéressés par l’état d’avancement de l’itération, mais ne contribuent pas directement à son achèvement. Cela peut être d’autres managers, les commerciaux, les développeurs d’autres projets, etc. Toutes les questions et les problèmes que se posent les « impliqués » peuvent être traités après la réunion (__Traitez le sujet à part__) ou communiqués dans une autre instance.%%% > %%% > __ »Mais »__%%% > %%% > Trop insister sur la distinction entre les types de participants à la réunion risque de créer une relation d’adversité. Ce n’est pas que les observateurs ne sont pas autorisés à communiquer avec l’équipe, c’est juste que cette communication est généralement inappropriée pendant le daily stand-up.%%% > %%% > __5a3. Participer par procuration__%%% > %%% >  »Tous les membres de l’équipe doivent participer. Si pour une raison ou une autre, un membre de l’équipe ne peut pas participer en personne, le membre absent doit soit participer par téléphone, soit demander à un autre membre de l’équipe de reporter l’état d’avancement. [Cochango, 2006] »%%% > %%% > Si les membres de l’équipe se manifestent au stand-up uniquement quand ils le souhaitent, cela laisse entendre que l’engagement de l’équipe n’est pas important. Cependant, il y a des situations où un membre de l’équipe ne peut pas participer à la réunion pour une raison très légitime (par exemple, des problèmes personnels, des problèmes en production, etc.). Dans ces cas, nous voulons trouver un moyen pour que le membre en question puisse exprimer son engagement lors du stand-up.%%% > %%% > __ »Par conséquent »__%%% > %%% > Les membres de l’équipe qui ne peuvent pas assister au stand-up en personne doivent trouver un moyen d’y __Participer par procuration__. Cela peut être sous la forme d’un représentant, en appelant au téléphone, en envoyant un e-mail récapitulatif avant. Une participation virtuelle vaut toujours mieux que pas de participation du tout.%%% > %%% > __ »Mais »__%%% > %%% > Si les membres de l’équipe ne peuvent régulièrement pas participer au stand-up, cela peut indiquer que le stand-up a lieu à une heure ou dans un endroit qui n’est pas pratique pour toute l’équipe. Cela peut aussi signifier que le membre ne fait pas réellement partie de l’équipe, parce qu’il a d’autres responsabilités ou des problèmes relationnels avec l’équipe. Bien sûr, participer par procuration est également moins satisfaisant que réellement participer en personne.%%% > %%% > __6. De quoi parlons-nous lors du daily stand-up meeting ?__%%% > %%% > __6a. Hier Aujourd’hui Obstacles__%%% > %%% > Certaines personnes sont bavardes et vont loin dans la narration. Certaines personnes veulent s’engager dans la Résolution de problème immédiatement après avoir entendu un problème. Les réunions qui prennent trop de temps ont tendance à avoir un niveau d’énergie faible et les participants qui ne sont pas directement liés à une longue discussion auront tendance à perdre leur concentration.%%% > %%% > __ »Par conséquent »__%%% > %%% > Structurer les contributions selon le format suivant :%%% > %%% > – Qu’ai-je accompli hier ?%%% > – Que vais-je faire aujourd’hui ?%%% > – Quels sont les obstacles qui m’empêchent d’avancer ?%%% > %%% > C’est le nombre minimal de questions pour satisfaire les objectifs des daily stand-ups. Les autres sujets de discussion (par exemple, la conception, les rumeurs, etc.) devrait être reportés après la réunion.%%% > %%% > Lasse Koskela propose une autre forme pour ces questions afin d’insister sur le fait que les membres de l’équipe ne doivent pas __Reporter au Chef__ :%%% > %%% >  »Chaque membre de l’équipe informe ses pairs : »%%% >  »À son tour, chaque membre de l’équipe fournit à ses pairs 3 informations : »%%% >  »1. Les choses que j’ai faites depuis la réunion d’hier »%%% >  »2. Les choses que je vais terminer aujourd’hui »%%% >  »3. Les obstacles pour lesquels j’ai besoin que quelqu’un intervienne pour les supprimer »%%% >  »[Koskela, 2006] »%%% > %%% > Si l’on reprend cela à la lumière de l’engagement, les questions peuvent être reformulées comme suit :%%% > – Ai-je été capable de respecter mon engagement ?%%% > – Sur quoi puis-je raisonnablement m’engager aujourd’hui ?%%% > – Quels sont les obstacles qui m’empêcheront d’atteindre mes engagements ?%%% > %%% > Je préfère cette forme pour sa clarté même si l’originale est plus simple.%%% > %%% > __ »Mais »__%%% > %%% > La structure n’est pas aussi importante que les informations fournies par les réponses aux questions. Si l’information est fournie via une forme moins structurée, il n’est pas important de se conformer à une liste de contrôle. Au fur et à mesure que les équipes montent en maturité, vous pourrez ajuster la structure. Par exemple, j’ai tendance à ajouter une quatrième question : « Qu’est-ce qui pourrait aider ou empêcher les autres de respecter leurs engagements ? ».%%% > %%% > __6b. Se concentrer sur le backlog__%%% > %%% > Certaines personnes trouvent qu’il est difficile de garder le contexte du projet à l’esprit quand elles contribuent. Les symptômes possibles sont que les participants quittent le stand-up sans avoir une idée claire de ce qui reste à faire pour l’itération et la release, et sans avoir d’affinités avec les problèmes soulevées lors du stand-up.%%% > %%% > Il est beaucoup plus facile de comprendre le contexte du projet avec un pense-bête visible.%%% > %%% > __ »Par conséquent »__%%% > %%% > Rappelez aux participants du stand-up de __Se concentrer sur le backlog__, où le backlog est simplement une liste de tâches et de fonctionnalités à réaliser. Par exemple, maintenez un radiateur d’information [Cockburn, 2001] (c’est-à-dire un Gros Tableau Visible) montrant l’état d’avancement de l’itération et de la release et tenez le stand-up à proximité. L’affichage sert évidemment de pense-bête sur ce qui reste à faire.%%% > %%% > __ »Mais »__%%% > %%% > Se concentrer sur le backlog peut avoir comme conséquence de se concentrer plus sur les tâches que sur les personnes. Il y aura toujours des problèmes importants et subtils liés aux personnes et que vous ne découvrirez pas en vous concentrant trop sur l’état d’avancement des tâches.%%% > %%% > __6c. Tableau des obstacles__%%% > %%% > Les obstacles identifiés pendant le stand-up ne sont pas directement supprimés, autrement dit traités à un autre moment plus opportun.%%% > %%% > __ »Par conséquent »__%%% > %%% > Les obstacles sont identifiés sur un __Tableau des obstacles__. Il s’agit d’un tableau blanc visible publiquement qui identifie les obstacles remontés et trace l’état d’avancement de leur résolution. Un __Tableau des obstacles__ peut être mis à jour en dehors des stand-ups et sert plus immédiatement – et peut-être même dans un milieu moins agressif – à remonter les obstacles. Une erreur commune est de ne pas écrire assez grand pour permettre aux gens de lire les obstacles à distance.%%% > %%% > Le simple fait d’écrire un problème, et donc de le reconnaître explicitement, est un moyen très fiable pour réduire la durée des conversations. Donc, même si tous ne se mettent pas d’accord sur le fait qu’un élément particulier soit un obstacle, cela vaut tout simplement le coup de l’écrire pour l’aborder après que la réunion soit terminée.%%% > %%% > __7. Quand et où se tiennent les daily stand-up meeting ?__%%% > %%% > __7a. Même lieu, même heure__%%% > %%% > Nous voulons que l’équipe s’approprie le stand-up. Nous voulons aussi que les parties intéressées soient en mesure d’observer un stand-up pour éviter d’avoir à planifier une autre réunion d’avancement. C’est donc difficile si un membre de l’équipe est autorisé à changer le lieu ou l’heure du stand-up.%%% > %%% > __ »Par conséquent »__%%% > %%% > Exécutez le daily stand-up au __Même lieu, Même heure__. N’attendez pas les retardataires, notamment les architectes et les managers. La réunion est pour toute l’équipe, pas pour une personne en particulier. Ceci est particulièrement important si vous __Utilisez le stand-up pour démarrer la journée__.%%% > %%% > Certaines équipes plus strictes imposent une « amende » aux retardataires. J’ai tendance à me méfier de toute forme de mécanisme de punition et je préfère la discussion.%%% > %%% > __ »Mais »__%%% > %%% > __Même lieu, même heure__ n’est pas destiné à être aveuglément appliqué. La chose importante pour l’heure de début c’est qu’elle soit la plupart du temps uniforme et rarement replanifiée. Si la replanification est souvent nécessaire, cela peut indiquer que l’heure de démarrage doit changer. Si un lieu est particulièrement gênant à atteindre pour tout le monde, cela indique probablement que le lieu doit changer.%%% > %%% > __7b. Utiliser le stand-up pour démarrer la journée__%%% > %%% > Le daily stand-up meeting permet de se concentrer et de prendre conscience des problèmes en suspens. S’il a lieu en fin de journée, cette concentration et cette prise de conscience sont gaspillées.%%% > %%% > __ »Par conséquent »__%%% > %%% > __Utilisez le stand-up pour démarrer la journée__. Avec la flexibilité des heures de travail flexibles, les membres de l’équipe n’arriveront pas tous au travail en même temps. Une pratique courante avec la « flexibilité des heures de travail », c’est d’utiliser des heures de travail communes. L’heure de début doit être fixée au début de ces heures de travail. De même, si les membres de l’équipe doivent arriver plus tard pour des raisons personnelles (par exemple, ils ont besoin de déposer les enfants à l’école), l’heure de début doit être fixée à un moment où chacun peut y participer.%%% > %%% > __ »Mais »__%%% > %%% > Il y a généralement une tendance à ne pas travailler sur les tâches d’un projet tant que le stand-up n’a pas eu lieu. Si le __Stand-up meeting démarre la journée… plus tard__, le temps de relâche peut être significatif. Dans une certaine mesure, cela peut être simplement être utilisé comme une occasion de consulter ses e-mails, de remplir ses feuilles de temps, etc. mais il peut être intéressant de supprimer cette notion du stand-up en tant que rituel de « début de journée » en le planifiant plus tard dans la journée.%%% > %%% > __7c. Ne pas utiliser le stand-up pour démarrer la journée__%%% > %%% > Le stand-up a vocation à être le rituel permettant de se concentrer sur la journée à venir, surtout si vous __Utilisez le stand-up au démarrage de la journée__. Pour cette raison, les membres de l’équipe ont tendance à ne pas travailler sur les fonctionnalités jusqu’à ce que le stand-up ait lieu. Lorsque la réunion n’est pas réellement exécutée en premier, cette tendance peut avoir un impact significatif sur la productivité.%%% > %%% > __ »Par conséquent »__%%% > %%% > __N’utilisez pas le stand-up pour démarrer la journée__. Planifiez le daily stand-up assez loin dans la journée pour qu’il ne soit pas associé psychologiquement au démarrage de la journée.%%% > %%% > __ »Mais »__%%% > %%% > Si le daily meeting ne démarre pas la journée, alors il ne peut plus être utilisé comme un rituel partagé pour focaliser l’attention de l’équipe pour démarrer la journée. Selon l’équipe, ce prix ne vaudra pas l’apparente augmentation d’efficacité.%%% > %%% > Quand il y a des nombreux projets utilisant les stand-ups, il est possible que plusieurs stand-up se produisent simultanément. Les observateurs intéressés par de multiples projets peuvent vouloir changer l’heure des stand-ups pour leur permettre d’être en mesure d’y assister. Cette situation est problématique car cela risque de frustrer le sentiment d’appropriation du stand-up par l’équipe si un observateur peut forcer un stand-up à s’adapter à ses horaires. Néanmoins, cela doit également être pris en considération pour décider de l’heure de début du daily stand-up.%%% > %%% > __8. Comment maintenir le niveau d’énergie du daily stand-up ?__%%% > %%% > __8a. Regroupement__%%% > %%% > Le volume de la parole affecte aussi bien l’écoute que l’efficacité de la communication. La distance physique change le niveau du volume nécessaire pour bien communiquer. Certaines personnes n’aiment pas parler fort et cela les gênera de le faire.%%% > %%% > __ »Par conséquent »__%%% > %%% > Le stand-up doit plus ressembler à un regroupement qu’à une réunion. S’il est difficile d’entendre quelque chose, rapprochez tout le monde. Au-delà de permettre un volume de parole plus confortable, être physiquement proche amène les participants à être plus attentifs. Être capable de se tenir physiquement plus proche est aussi une expression d’une plus grande confiance au sein de l’équipe.%%% > %%% > Si le stand-up est une nouvelle chose, il est généralement suffisant de faire un signe de la main en disant « Venez ». Si la taille du cercle a été établie pour un certain temps, pensez à expliquer les raisons pour lesquelles il faut fermer le cercle avant de le rétrécir.%%% > %%% > __ »Mais »__%%% > %%% > L’équipe doit trouver un équilibre entre proximité et zone de confort personnel. Même dans une équipe très confiante, il y a un point à partir duquel les gens sont simplement trop près pour se sentir confortables. Les symptômes sont une tendance des participants à être tendus et/ou remuants.%%% > %%% > __8b. Debout__%%% > %%% > Certaines personnes sont bavardes et ont tendance à aller loin dans la narration. Certaines personnes veulent s’engager dans la Résolution de problèmes immédiatement après avoir entendu un problème. Les réunions qui prennent trop de temps ont tendance à avoir un faible niveau d’énergie et les participants qui ne sont pas directement concernés par une longue discussion auront tendance à perdre leur concentration.%%% > %%% > __ »Par conséquent »__%%% > %%% > Exigez que tous les participants soient debouts. Utilisez la position debout comme un lien entre le physique et la préparation mentale. Un inconfort physique peut également rappeler aux participants que la réunion est trop longue. Un moyen simple d’encourager cela est de tenir la réunion à un endroit où il n’y a pas de chaises.%%% > %%% > __ »Mais »__%%% > %%% > La position debout a tendance à écourter les réunions, mais elle ne garantit pas qu’elles seront écourtées selon une durée optimale. Les gens peuvent apprendre à gérer l’inconfort plutôt que d’avoir une réponse plus appropriée. Si les réunions ne sont pas trop longues et ne tombent pas dans le hors-sujet, la position debout est un rituel inutile.%%% > %%% > __8c. Quinze minutes ou moins__%%% > %%% > La plupart des gens vagabondent mentalement lorsqu’ils sont dans de longues réunions. Une longue réunion est une manière horrible de démarrer la journée et tue l’énergie de l’équipe. Une durée spécifique nous aide à nous rappeler à quel moment envisager de réduire la durée de la réunion.%%% > %%% > __ »Par conséquent »__%%% > %%% > Maintenez les daily stand-up à __Quinze minutes ou moins__. En règle générale, après quinze minutes, l’esprit des personnes a tendance à vagabonder, ce qui n’aide pas à se concentrer.%%% > %%% > __ »Mais »__%%% > %%% > Quinze minutes, cela peut même être trop long pour de petites équipes. En raison de cet effet d’esprit qui vagabonde, même pour les grandes équipes, quinze minutes est une bonne limite. Il est également possible d’avoir une réunion qui soit trop courte, où les participants n’ont pas encore d’idée précise de ce qui se passe, ni à qui en parler afin de le découvrir.%%% > %%% > __8d. Signaler la fin__%%% > Une fois que la dernière personne a parlé, l’équipe ne réalise pas immédiatement que la réunion est terminée. La prise de conscience progressive qu’il est temps de s’en aller ne termine pas la réunion sur une note positive et peut même contribuer à baisser le niveau d’énergie de l’équipe.%%% > %%% > __ »Par conséquent »__%%% > %%% > __Signaler la fin du stand-up__ avec une phrase bateau (par exemple : « Eh bien, bon appétit à tout le monde. » [Gibbs, 2006, Signal]) ou équivalent.%%% > %%% > __8e. Chronométrer les réunions__%%% > %%% > Il est difficile de juger qualitativement si un stand-up est trop long ou non, surtout si sa durée augmente progressivement.%%% > %%% > __ »Par conséquent »__%%% > %%% > Chronométrez les réunions et publiez les résultats. La plupart du temps, les participants ne réalisent pas l’impact de __Raconter des histoires__ et ne sont pas préparés à __Traiter le sujet à part__, ou ne se sont pas préparés à la durée de la réunion. Rendez-le quantifiable.%%% > %%% > __ »Mais »__%%% > %%% > Comme avec toutes les mesures, chronométrer des réunions ne devrait pas être effectué à moins qu’il y ait un véritable objectif à atteindre en raison d’un problème de niveau d’énergie. Une fois le but atteint, l’action de mesurer doit être abandonnée. Mesurer sans raison particulière conduit à la méfiance et l’indifférence aux mesures.%%% > %%% > __8f. Traiter le sujet à part__%%% > %%% > Certaines personnes veulent s’engager dans la Résolution de problèmes immédiatement après avoir entendu un problème. Les réunions qui prennent trop de temps ont tendance à baisser le niveau d’énergie de l’équipe et les participants qui ne sont pas directement concernés par cette longue discussion auront tendance à perdre leur concentration. Il est toujours important de reconnaître que d’autres discussions seront nécessaires pour résoudre le problème remonté. Certains personnes trouveront peut être ça gênant de faire respecter la structure du stand-up en interrompant la discussion.%%% > %%% > __ »Par conséquent »__%%% > %%% > Utilisez une phrase simple et cohérente, telle que « Traitez le sujet à part », comme un rappel pour que ces discussions aient lieu en dehors du daily stand-up. Si la discussion est de l’ordre de la __Socialisation__, rien de plus n’est nécessaire. Si la discussion est de l’ordre de la __Résolution de problèmes__, le facilitateur (ou simplement l’équipe) doit s’assurer que les bonnes personnes sont désignées pour traiter la question plus tard.%%% > %%% > __ »Mais »__%%% > %%% > Il y a une différence entre la Résolution de problèmes et Clarifier une question. L’information qui n’est pas comprise n’est pas utile. Jusqu’à quel point aller pour clarifier une question variera en fonction de la taille de l’équipe et si cela impacte la durée de __Quinze minutes ou moins__.%%% > %%% > __9. Comment pouvons-nous encourager des daily stand-ups auto-gérés ?__%%% > %%% > __9a. Le dernier arrivé parle en premier__%%% > %%% > Lors d’un stand-up, les participants ont besoin de savoir qui est censé parler en premier. Laisser un facilitateur décider qui doit parler le premier, produit une force subtile mais contraire à l’auto-organisation. L’équipe doit savoir, sans intervention, qui parle en premier.%%% > %%% > __ »Par conséquent »__%%% > %%% > Mettez-vous d’accord sur le fait que le __Dernier arrivé parle en premier__. C’est une règle simple qui offre également l’avantage supplémentaire d’encourager les gens à être ponctuel en arrivant au stand-up.%%% > %%% > __9b. Round Robin__%%% > %%% > Lors d’un stand-up, les participants ont besoin de savoir qui est censé parler ensuite. Laisser un facilitateur décider qui doit parler ensuite, produit une force subtile mais contraire à l’auto-organisation. L’équipe doit savoir, sans intervention, qui parle ensuite.%%% > %%% > __ »Par conséquent »__%%% > %%% > Utilisez une règle simple comme un Round Robin $$NdT : algorithme d’ordonnancement notoirement utilisé pour la répartition de charges, aussi appelé le Tourniquet, voir http://fr.wikipedia.org/wiki/Round-robin_%28informatique%29$$ pour déterminer qui doit ensuite parler. Ce n’est pas grave si cela a lieu dans le sens horaire ou anti-horaire. Ce qui importe c’est que l’équipe mène la réunion, et non le facilitateur ou le manager.%%% > %%% > __9c. Se passer un objet__%%% > %%% > Avec des mécanismes d’ordonnancement simples et prédictifs (par exemple, le __Round Robin__), il est très facile pour les participants d’ignorer les autres jusqu’à ce que leur tour approche. On peut avoir tendance à penser à autre chose et ne pas prêter attention à ce que disent les autres.%%% > %%% > __ »Par conséquent »__%%% > %%% > Introduisez un mécanisme d’ordonnancement imprévisible, comme lancer un objet (par exemple, une balle) pour déterminer qui doit ensuite parler. Disposer d’un objet pour prendre la parole simplifie également la décision pour savoir qui va parler en premier car ce sera la personne qui arrive à récupérer l’objet (ou la première personne à qui on lance l’objet).%%% > %%% > Lancer quelque chose introduit un peu d’amusement dans le rituel du daily stand-up et se révèle ainsi un agent pour infecter les autres équipes qui observent.%%% > %%% > J’ai appris cette bonne pratique sur un projet sur lequel j’étais avec Simon Stewart. Nous avons utilisé une petite balle de jonglage mais vous pouvez presque tout utiliser. D’autres équipes ont utilisé des ballons de rugby [Gibbs, 2006, Rugby] ou même des jouets en peluche [Mar, 2006].%%% > %%% > __ »Mais »__%%% > %%% > Avec de plus grandes équipes, il peut devenir difficile de se rappeler qui a déjà parlé. Dans ce cas, il peut être plus facile de s’en tenir à des mécanismes plus simples comme le Round Robin. Selon la culture de l’organisation voire de l’équipe, lancer une balle peut être considéré comme non professionnel et peut créer une perception négative superflue du rituel sous-jacent.%%% > %%% > __9d. Prenez une carte__%%% > %%% > Lors d’un stand-up, les participants ont besoin de savoir qui est censé parler en premier et qui est censé parler ensuite. Laisser un facilitateur décider qui doit parler produit une force subtile mais contraire à l’auto-organisation. L’équipe n’a pas envie de __Se passer un objet__ parce qu’ils ont généralement des tasses de café dans leurs mains.%%% > %%% > __ »Par conséquent »__%%% > %%% > Demandez aux membres de l’équipe de tirer une carte qui a un certain nombre indiquant l’ordre dans lequel ils vont parler [Russell, 2006].%%% > %%% > __9e. Faites tourner le Facilitateur__%%% > %%% > Les membres de l’équipe font le __Reporting à leur chef__, c’est-à-dire qu’ils parlent uniquement au facilitateur de la réunion au lieu de le faire entre eux. Seul le facilitateur de la réunion est identifié et aborde les problèmes de processus liés au stand-up. Nous voulons que l’équipe s’approprie le stand-up et cela nécessite de supprimer toute dépendance à l’égard d’un facilitateur unique.%%% > %%% > __ »Par conséquent »__%%% > %%% > __Faites tourner le rôle du Facilitateur__. Faites tourner le rôle chargé d’assurer que les personnes participent au stand-up et respectent les règles précisées plus haut.%%% > %%% > __ »Mais »__%%% > %%% > Les équipes qui n’ont pas beaucoup d’expérience avec les stand-ups bénéficieront grandement d’avoir un coach expérimenté. C’est un plus si l’équipe est accompagnée pour une meilleure maîtrise du stand-up. Au bout d’un certain temps, le facilitateur en tant que tel ne sera plus nécessaire.%%% > %%% > __9f. Brisez le contact avec les yeux__%%% > %%% > Les membres de l’équipe font le __Reporting à leur chef__, c’est-à-dire qu’ils parlent uniquement au facilitateur de la réunion au lieu de le faire entre eux. Nous voulons que l’équipe s’approprie le stand-up et cela nécessite de supprimer toute dépendance à l’égard d’un facilitateur unique.%%% > %%% > __ »Par conséquent »__%%% > %%% > Le facilitateur doit __Briser le contact avec les yeux__ [Nicolette, 2006] comme une façon subtile de rappeler à l’orateur qu’il/elle doit s’adresser à l’équipe, pas à une seule personne. Une façon de procéder est de se déplacer [Shimp, 2006] de sorte que l’orateur ne peut pas voir le facilitateur.%%% > %%% > __10. Avoir une mauvaise sensation lorsque ça va mal__%%% > %%% >  »J’ai enduré des stand-up meetings réguliers trois ans. Mon patron (je vais l’appeler Wally) a rendu ces réunions plus douloureuses. Selon lui, la raison principale d’une réunion stand-up n’était pas d’augmenter l’efficacité ou d’embrasser XP$$NdT : eh oui, c’est l’eXtreme Programming qui a introduit le terme Daily stand-up meeting, voir http://www.extremeprogramming.org/rules/standupmeeting.html$$ autant qu’il soit possible de le faire pour concentrer au maximum les interactions humaines sur ce qui était directement lié aux tâches de fabrication du produit … En fait, pour Wally, le stand-up meeting (à 7 heures le lundi et à 17 heures le vendredi) était un test de loyauté visant à renforcer la relation employeur-employé. [LaPlante, 2003] »%%% > %%% > La sensation d’efficacité d’un stand-up repose sur la façon dont vous savez quand les choses vont bien. Les mauvaises sensations reposent sur la façon dont vous savez quand les choses vont mal. Il est important de remarquer que même si vous n’avez pas de mauvaises sensations, cela ne signifie pas pour autant que le stand-up se déroule bien. Cela signifie simplement que vous ne le « sentez pas ».%%% > %%% > La plupart des mauvaises sensations qui suivent sont liées aux bonnes pratiques précédentes. Pour celles qui ne le sont pas, les problèmes sous-jacents ont tendance à être plus subtils ou hors périmètre du daily stand-up, dans ce cas les gens devront venir avec leurs propres solutions.%%% > %%% > __10a. Reporting au chef__%%% > %%% >  »Les membres de l’équipe s’adressent à l’équipe. Ce n’est pas une réunion de « Reporting au ScrumMaster ». [Cochango, 2006] »%%% > %%% > Les membres de l’équipe font face au manager ou au facilitateur de la réunion au lieu de faire face à l’équipe. Ceci indique que le daily stand-up est réalisé pour le manager/facilitateur alors qu’il est en réalité censé l’être pour l’équipe. Il y a différentes façons de briser cette dépendance : __Faites tourner le rôle du facilitateur__, __Brisez le contact avec les yeux__, changer la forme __Hier Aujourd’hui Obstacles__, __Faites passer un objet pour prendre la parole__, etc.%%% > %%% > __10b. Les gens sont en retard__%%% > %%% > Ceci est directement lié au fait qu’il s’agit du __Même Lieu, Même Heure__, mais cela peut aussi indiquer que le stand-up se déroule au mauvais moment ou au mauvais endroit.%%% > %%% > __10c. Le stand-up meeting démarre la journée… trop tard__%%% > %%% > Étant donné que le stand-up est vu comme une réunion qui lance la journée de travail, il arrive qu’aucun travail ne soit effectué avant le stand-up. Selon que le stand-up est mené plus ou moins tard dans la matinée, cela peut avoir un impact significatif sur les heures de travail. Donc __N’utilisez pas le stand-up pour commencer la journée__.%%% > %%% > __10d. Les observateurs interviennent__%%% > %%% > L’interruption régulière par des observateurs est très perturbatrice pour l’équipe et remet en question le postulat comme quoi le daily stand-up est principalement dédié à l’équipe. Ces interventions peuvent également menacer la durée des __Quinze minutes ou moins__. Appliquez la __Politique des Cochons et des Poulets__.%%% > %%% > __10e. Socialisation__%%% > %%% > L’un des objectifs du stand-up est d’augmenter la socialisation des membres de l’équipe. Cependant, le daily stand-up n’a pas vocation à permettre aux membres de l’équipe de « récupérer » des informations des uns et des autres sur des questions qui ne sont pas liées au projet. Il est difficile de donner des exemples puisque ce degré de socialisation (cohésion <-> perturbation) varie d’une équipe à l’autre. Le seuil peut être détecté à partir des comportements des participants qui ne sont pas directement impliqués dans la socialisation de l’équipe. Si le niveau d’énergie du daily stand-up reste élevée, alors c’est probablement de la cohésion d’équipe ; si le niveau d’énergie du daily stand-up chute, __Traitez le sujet à part__ et proposez une autre tribune pour traiter le sujet en agissant comme un __Refroidisseur__ [OrgPatternsWaterCooler].%%% > %%% > __10f. Je ne me souviens pas__%%% > %%% > « Ce que j’ai fait hier ? … Je ne me souviens pas… Ce que je vais faire aujourd’hui ? … Je ne sais pas… »%%% > %%% > Les daily stand-ups sont des réunions. Comme toutes les réunions, les participants ont la responsabilité de les préparer. Dans ce cas, tous les participants sont tenus de connaître les réponses aux trois questions __Hier Aujourd’hui Obstacles__. On peut être plus indulgent sur le fait de ne pas savoir ce qui sera fait aujourd’hui, car parfois il n’y a en réalité rien de prévu spécifiquement sauf à aller chercher la tâche suivante de plus haute priorité dans la pile.%%% > %%% > Un manque de préparation peut générer un rythme plus faible donc moins d’énergie. Cela risque aussi de pénaliser la durée __Quinze minutes ou moins__, ce qui réduit encore le niveau d’énergie.%%% > %%% > __10g. Raconter une histoire$$Story Telling$$__%%% > %%% > Au lieu de fournir une brève description d’un problème, le participant fournit trop de détails et rentre trop dans le contexte ce qui fait que les autres en arrivent à faire la sourde oreille. La règle générale est d’identifier les obstacles lors du stand-up et de discuter des détails après le stand-up. Cela peut se résumer par « Donnez le titre, pas toute l’histoire » ou __Traitez le sujet à part__.%%% > %%% > __10h. Résolution de problèmes__%%% > %%% > L’idée clé pour maintenir la durée des stand-ups à __Quinze minutes ou moins__ est d’éviter de __Raconter une histoire__ et ne pas être tenté par la __Résolution de problèmes__ en séance. __Traitez le sujet à part__.%%% > %%% > __10i. Faible niveau d’énergie__%%% > %%% > Cela peut indiquer un ralentissement du rythme dû au fait de __Raconter une histoire__, d’être tenté par la __Résolution de problèmes__, etc. Dans ce cas, __Traitez le sujet à part__. Cela peut être simplement lié à la taille de l’équipe. Cela peut être lié au moment de la journée, ce qui invite à essayer d’__Utiliser le stand-up pour commencer la journée__ et __N’utilisez pas le stand-up pour commencer la journée__.%%% > %%% > __10j. Les obstacles ne sont pas identifiés__%%% > %%% > Il peut y avoir plusieurs raisons pour lesquelles les obstacles ne sont pas soulevés. Ne pas se souvenir, ça dépasse le seuil de douleur, le manque de confiance liée au fait de soulever des problèmes (car les __Obstacles ne sont pas supprimés__, les __Observateurs interviennent__ en blâmant le membre de l’équipe), etc. Selon le contexte, se contenter d’introduire les questions __Hier, Aujourd’hui, Obstacles__ et appliquer la __Politique des Cochons et des Poulets__ peut ne pas être suffisant. Passer par un __Tableau des obstacles__ peut fournir un environnement moins agressif pour identifier les obstacles. Les Rétrospectives [Kerth, 2001] sont un moyen efficace de découvrir la raison profonde pour laquelle __Les obstacles ne sont pas identifiés__.%%% > %%% > __10k. Les obstacles ne sont pas supprimés__%%% > %%% > À l’exception d’un environnement où l’on blâme les gens, le plus sûr moyen d’empêcher les gens d’identifier les obstacles, c’est de ne pas les traiter/supprimer. Pour que cela devienne difficile d’oublier et/ou ignorer les obstacles, suivez-les publiquement sur un __Tableau des obstacles__.%%% > %%% > __10l. Les obstacles sont Uniquement identifiés lors du stand-up__%%% > %%% > Les stand-ups agissent comme un filet de sécurité. Au pire, un obstacle sera communiqué à l’équipe complète à une journée près. Cependant, le stand-up n’est pas destiné à arrêter d’identifier et résoudre des obstacles au cours de la journée. Introduire un autre environnement pour identifier les obstacles tel qu’un __Tableau des obstacles__ peut vous aider. Sinon, les raisons sous-jacentes pourront être découvertes à l’aide des rétrospectives.%%% > %%% > __11. Si vous avez une bonne sensation, c’est que les choses se déroulent probablement bien__%%% > %%% > Espérons que ce document vous aura donné un aperçu des subtilités des bonnes pratiques des stand-ups ainsi que des indicateurs sur des problèmes communément observés. Dans tous les cas, il doit être clair que le daily stand-up ne consiste pas simplement à se tenir ensemble debout tous les jours.%%% > %%% > Il est important de ne pas trop se soucier de ne pas avoir toutes les bonnes pratiques ou même d’avoir quelques mauvaises pratiques. Si tous les objectifs sont atteints et que vous avez une bonne sensation, tout se passe probablement bien. Après tout, il s’agit juste de rester ensemble debout tous les jours :)%%% > %%% > __12. Que disent les autres ?__%%% > %%% > Autant que je sache, il n’y a pas d’autres articles plus précis sur les bonnes pratiques des daily stand-ups même si les idées de base existent dans les documents référencés. Il y a quelques articles en ligne sur les mauvaises pratiques ([Miller, 2003], [Cohn, 2003]) même s’ils restent tous les deux de portée limitée.%%% > %%% > __13. Remerciements__%%% > %%% > Je tiens à remercier Ivan Moore et Alan Francis de m’avoir aidé à déterminer ce que je voulais exprimer, Owen Rogers pour certaines des bonnes pratiques, Susan Newton de m’avoir rappelé que les stand-ups devait être soutenus, James Ross et Rebecca Parsons pour certaines modifications, Brian Marick pour m’avoir suivi, toutes les personnes présentes lors de mon atelier PLoP 2004 (Dick Gabriel, Linda Rising, James Coplien, Lise Hvatum, Cecilia et Terje Haskins, Danny Dig, David Hecksel, et Ali Arsanjani), Bill Wake pour ses commentaires détaillés, toutes les personnes présentes lors de mon atelier PLoP 2006 (Ralph Johnson, Pau Arumi, David Garcia, Léon Welicki, Djamal Bellebia, Dirk Riehle, Hesham Saadawi, et Paddy Fagan), Karthik Chandrasekarial pour la photo du stand-up, et toutes les personnes avec qui j’ai participé à un stand-up.%%% > %%% > __14. Références__%%% > %%% > [Anderson, 2002] Anderson, D., « Morning Roll Call », The Coad Letter: Process, Issue 101 (August 2002), URL: http://bdn.borland.com/article/0,1410,29686,00.html%%% > [Beedle et al., 2000] Beedle, M. et al., « SCRUM: An Extension Pattern Language for Hyperproductive Software Development », Pattern Languages of Program Design 4, N. Harrison, B. Foote, and H. Rohnert, eds., Addison-Wesley, 2000, pp. 637-651%%% > [Cockburn, 2001] Cockburn, A., Agile Software Development, Addison-Wesley, 2001%%% > [Cochango, 2006] « Daily Scrum Meeting », URL: http://scrumforteamsystem.com/ProcessGuidance/Process/DailyScrumMeeting.html%%% > [Cohn, 2003] Cohn, M., « Toward a Catalog of Scrum Smells », October 2003, URL: http://www.mountaingoatsoftware.com/articles/ScrumSmells.pdf%%% > [Gibbs, 2006, Leaderless] Gibbs, E., « Leaderless Standups », 10 August 2006, URL: http://edgibbs.com/2006/08/10/leaderless-standups/%%% > [Gibbs, 2006, Rugby] Gibbs, E., « Passing A Rugby Ball in Standups”, 14 August, 2006, URL: http://edgibbs.com/2006/08/14/passing-a-rugby-ball-in-standups/%%% > [Gibbs, 2006, Signal] Gibbs, E., « Signaling the End of a Standup », 7 August, 2006, URL: http://edgibbs.com/2006/08/07/signaling-the-end-of-a-standup/%%% > [Jeffries, 2004] Jeffries, R., « Big Visible Charts », March 2004, URL: http://www.xprogramming.com/xpmag/BigVisibleCharts.htm%%% > [Kerth, 2001] Kerth, N., Project Retrospectives, Dorset House, 2001%%% > [Koskela, 2006] Koskela, L., « On Scrum and the curse of the three questions », May 7, 2006, URL: http://radio.javaranch.com/lasse/2006/05/07/1147034972559.html%%% > [LaPlante, 2003] Laplante, Phillip A., « Stand and Deliver: Why I Hate Stand-up Meetings », ACM Queue, 1, 7 (October 2003) > [Mar, 2006] Mar, K., « Controling the flow of daily meetings with a team mascot », 13 May 2006, URL: http://kanemar.wordpress.com/2006/05/13/controling-the-flow-of-daily-meetings-with-a-team-mascot/%%% > [Miller, 2003] Miller, C., « Stand-up Meeting Antipatterns », 19 November 2003, URL: http://fishbowl.pastiche.org/2003/11/19/standup_meeting_antipatterns%%% > [Nicolette, 2006] Nicollete, D., « Re: On Scrum and the curse of the three questions », May 8, 2006, URL: http://radio.javaranch.com/lasse/2006/05/07/1147034972559.html#comment1147110635098%%% > [Rising, 2002] Rising, L., « Agile Meetings », STQE, May/June 2002, pp. 42-46%%% > [Rising and Janoff, 2000] Rising, L. and N. Janoff, « The Scrum Software Development Process for Small Teams », IEEE Software, July/August 2000, pp. 2-8%%% > [Russell, 2006] Russell, R., « The Daily Stand Up, Part 2 », 30 May 2006, URL: http://www.robbyonrails.com/articles/2006/05/29/the-daily-stand-up-part-2%%% > [OrgPatternsStandUp] « Stand Up Meeting », Org Patterns, 7 October 2003, URL: http://www.easycomp.org/cgi-bin/OrgPatterns?StandUpMeeting%%% > [OrgPatternsWaterCooler] « The Water Cooler », Org Patterns, 18 November 2003, URL: http://www.easycomp.org/cgi-bin/OrgPatterns?TheWaterCooler%%% > [Schwaber and Beedle, 2001] Schwaber, K. and M. Beedle. (2001) Agile Software Development with Scrum, Prentice-Hall%%% > [Shimp, 2006] Shimp, D., « An Overview of ScrumMaster – Part 2 », July 18, 2006, URL: http://www.netobjectives.com/podcasts/last20060719_podcasts.mp3%%% > [Wells, 1999] Wells, D., « Daily Stand Up Meeting », Extreme Programming: A gentle introduction., 1999, URL: http://www.extremeprogramming.org/rules/standupmeeting.html%%% __Feedback :__%%% * Blog Xebia : ++[Tout le monde se lève pour Daily|http://blog.xebia.fr/2011/07/05/revue-de-presse-xebia-218/#ToutlemondeselvepourDaily]++%%% %%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Le Corpus de Connaissances de l’Agile Certified Practitioner du PMI

J’ai traduit cet article de David Bulkin sur InfoQ : ++[« PMI Agile Certified Professional Body of Knowledge »|http://www.infoq.com/news/2011/06/pmi-certified-professional-body|en]++.%%% > Il n’y a pas de référence unique pour ceux qui cherchent à préparer le nouvel examen Agile Certified Practitioner du Project Management Institute (PMI-ACP); le PMI propose plutôt une liste de domaines de test, d’ouvrages de référence, qui, pris ensemble, constituent le corpus de connaissances pour la certification.%%% > %%% > Ceux qui détiennent la certification Project Management Professional (PMP) ont le ++[Guide PMBOK|http://marketplace.pmi.org/Pages/ProductDetail.aspx?GMProduct=00101095501|en]++, beaucoup s’attendaient donc à un équivalent pour l’Agile.%%% > %%% > « J’aurais supposé que si le PMI offrait une certification Agile, ils auraient un Agile BOK dédié », a déclaré Chris Bodgwic, un PMP.%%% > %%% > Chris, et d’autres qui préparent l’Examen PMI-ACP, peuvent commencer par un ++[aperçu sur le contenu de l’examen de la certification Agile du PMI|http://www.pmi.org/~/~/media/Files/PDF/Agile/PMI_Agile_Certification_Content_Outline.ashx|en]++. Il y a deux catégories, Outils et Techniques, et Connaissances et Compétences, représentant chacun 50% de l’examen. Le PMI définit également six domaines qui sont des groupes de travail pour les projets agiles. Mike Griffiths les a regroupé en un seul cube qui représente un ++[schéma simplifié|/dotclear/index.php?post/2011/06/18/La-Certification-Agile-du-PMI-s-appelera-Agile-Certified-Practitioner]++ du corpus de connaissances du PMI-ACP.%%% > %%% > [((/dotclear/public/traductions/.agile-certified-practitioner-1_m.jpg|Agile Certified Practitioner 1||Agile Certified Practitioner 1))|/dotclear/public/traductions/agile-certified-practitioner-1.jpg]%%% > %%% > Pour le contenu, le PMI propose une liste de dix ouvrages de référence qui sont représentatifs des connaissances évaluées lors de l’examen.%%% > – ++[Agile Retrospectives: Making Good Teams Great|http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649/ref=sr_1_1?ie=UTF8&s=books&qid=1307132949&sr=8-1|en]++ – Esther Derby, Diana Larsen, Ken Schwaber (Foreward) ISBN #0977616649%%% > – ++[Agile Software Development: The Cooperative Game – 2nd Edition|http://www.amazon.com/Agile-Software-Development-Cooperative-Game/dp/0321482751|en]++ – Alistair Cockburn ISBN #032148275%%% > – ++[The Software Project Manager’s Bridge to Agility|http://www.amazon.com/Software-Project-Managers-Bridge-Agility/dp/0321502752/ref=sr_1_1?ie=UTF8&s=books&qid=1307133206&sr=1-1|en]++ – Michele Sliger, Stacia Broderick ISBN #032150275%%% > – ++[Coaching Agile Teams|http://www.amazon.com/Coaching-Agile-Teams-ScrumMasters-Addison-Wesley/dp/0321637704/ref=sr_1_1?ie=UTF8&s=books&qid=1307133256&sr=1-1|en]++ – Lyssa Adkins ISBN #032163770%%% > – ++[Agile Project Management: Creating Innovative Products – 2nd Edition|http://www.amazon.com/Agile-Project-Management-Creating-Innovative/dp/0321658396/ref=sr_1_fkmr0_2?ie=UTF8&qid=1307133392&sr=1-2-fkmr0|en]++ – Jim Highsmith ISBN #032165839%%% > – ++[Agile Estimating and Planning|http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415/ref=sr_1_1?s=books&ie=UTF8&qid=1307133417&sr=1-1|en]++ – Mike Cohn ISBN #0131479415%%% > – ++[The Art of Agile Development|http://www.amazon.com/Art-Agile-Development-James-Shore/dp/0596527675/ref=sr_1_1_title_0_main?s=books&ie=UTF8&qid=1307133446&sr=1-1|en]++ – James Shore ISBN #059652767%%% > – ++[User Stories Applied: For Agile Software Development|http://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685/ref=sr_1_1?s=books&ie=UTF8&qid=1307133474&sr=1-1|en]++ – Mike Cohn ISBN #032120568%%% > – ++[Agile Project Management with Scrum|http://www.amazon.com/Agile-Project-Management-Microsoft-Professional/dp/073561993X/ref=sr_1_1?s=books&ie=UTF8&qid=1307133514&sr=1-1|en]++ – Ken Schwaber ISBN #073561993%%% > – ++[Lean-Agile Software Development: Achieving Enterprise Agility|http://www.amazon.com/Lean-Agile-Software-Development-Achieving-Enterprise/dp/0321532899/ref=sr_1_1?ie=UTF8&s=books&qid=1307133568&sr=1-1|en]++ – Alan Shalloway, Guy Beaver, James R. Trott ISBN #032153289%%% > %%% > Ces livres sont bien connus de la communauté Agile et les thèmes de ces livres qui sont couverts par le ++[Contenu de l’Examen de la Certification Agile du PMI|http://www.pmi.org/~/~/media/Files/PDF/Agile/PMI_Agile_Certification_Content_Outline.ashx|en]++ représentent le corpus de connaissances du PMI-ACP.%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

La Certification Agile du PMI s’appelera « Agile Certified Practitioner »

((/dotclear/public/photos/.mike-griffiths_sq.jpg|Mike Griffiths|L|Mike Griffiths))J’ai traduit ce billet de __Mike Griffiths__ : ++[PMI Agile Cert to be called « Agile Certified Practitioner »|http://leadinganswers.typepad.com/leading_answers/2011/05/pmi-agile-cert-to-be-called-agile-certified-practitioner.html|en]++.%%% >[((/dotclear/public/traductions/.agile-certified-practitioner-0_s.jpg|Agile Certified Practitioner 0|L|Agile Certified Practitioner 0))|/dotclear/public/traductions/agile-certified-practitioner-0.jpg]Il s’avère que la suggestion initiale de « Agile Project Practitioner » (PMI-APP) était trop proche de « App. » qui renvoie trop à Application et même à une application de téléphone$$NdT : phone app$$. Donc, le nom sera désormais ACP pour « Agile Certified Practitioner ».%%% > %%% > Le calendrier pour les personnes souhaitant postuler est le suivant :%%% > – __23 Mai__ : Lancement public.%%% > – __Mi-Juillet__ : Des participants pilotes peuvent s’inscrire aux examens dans les centres de tests Prometric.%%% > – __15 Septembre__ : Démarrage des tests des programmes pilotes.%%% > – __30 Novembre__ : Fin des tests des programmes pilotes.%%% > – __1er Janvier__ : La première série de personnes qui ont réussi l’examen est informée.%%% > %%% > Je reçois beaucoup de questions sur le contenu de l’examen, donc j’ai pensé présenter différentes manières de l’interpréter. Dans mon dernier billet sur le sujet, j’ai montré le modèle de la boîte pour associer les Domaines avec les Connaissances et Compétences (KS$$NdT : Knowledge & Skills$$), et les Outils et Techniques (TT$$NdT : Tools & Techniques$$).%%% > %%% > [((/dotclear/public/traductions/.agile-certified-practitioner-6_m.jpg|Agile Certified Practitioner 6||Agile Certified Practitioner 6))|/dotclear/public/traductions/agile-certified-practitioner-6.jpg]%%% > %%% > Voici une version avec les répertoires KS et TT :%%% > %%% > [((/dotclear/public/traductions/.agile-certified-practitioner-1_m.jpg|Agile Certified Practitioner 1||Agile Certified Practitioner 1))|/dotclear/public/traductions/agile-certified-practitioner-1.jpg]%%% > %%% > Une autre façon de le visualiser est d’examiner les champs couverts.%%% > Nous pouvons commencer avec le champ de la gestion de projet :%%% > %%% > [((/dotclear/public/traductions/.agile-certified-practitioner-2_m.jpg|Agile Certified Practitioner 2||Agile Certified Practitioner 2))|/dotclear/public/traductions/agile-certified-practitioner-2.jpg]%%% > %%% > On y retrouve la vision mondiale par le PMI de la gestion de projet et que j’appelle le contenu du Guide du PMBOK v4.%%% > %%% > [((/dotclear/public/traductions/.agile-certified-practitioner-3_m.jpg|Agile Certified Practitioner 3||Agile Certified Practitioner 3))|/dotclear/public/traductions/agile-certified-practitioner-3.jpg]%%% > %%% > Le Guide du PMBOK v4 n’est cependant pas un pur sous-ensemble de la gestion de projet, puisque des choses comme le Code d’Ethique, bien qu’intéressant pour un PM, n’est pas strictement de la gestion de projet. De même, il existe de nombreuses techniques de gestion de projet, comme la Théorie des Contraintes, qui ne sont pas pleinement adopté par le Guide du PMBOK.%%% > %%% > [((/dotclear/public/traductions/.agile-certified-practitioner-4_m.jpg|Agile Certified Practitioner 4||Agile Certified Practitioner 4))|/dotclear/public/traductions/agile-certified-practitioner-4.jpg]%%% > %%% > Lorsque nous ajoutons les principes Agile et Lean, nous constatons un chevauchement important.%%% > %%% > [((/dotclear/public/traductions/.agile-certified-practitioner-5_m.jpg|Agile Certified Practitioner 5||Agile Certified Practitioner 5))|/dotclear/public/traductions/agile-certified-practitioner-5.jpg]%%% > %%% > Agile et Lean sont tout aussi concernés par la Qualité et l’Estimation que le Guide PMBOK, mais leur approche est souvent très différente.%%% > %%% > La dernière partie importante de la connaissance est le Leadership.%%% > %%% > [((/dotclear/public/traductions/.agile-certified-practitioner-7_m.jpg|Agile Certified Practitioner 7||Agile Certified Practitioner 7))|/dotclear/public/traductions/agile-certified-practitioner-7.jpg]%%% > %%% > Le Leadership couvre des sujets comme la Vision, l’Ethique, l’Intelligence Émotionnelle, le Leadership Situationnel et le Leadership au service de l’équipe$$NdT : Servant Leadership ; et hop, j’en profite pour faire un clin d’oeil au ++[petit cochon pendu au plafond|http://etreagile.thierrycros.net/home/?post/2011/04/21/Un-petit-cochon-pendu-au-plafond]++ de Thierry Cros.$$. Bon nombre des concepts que les projets Agile emploient. C’est la combinaison de ces champs Gestion de Projet, Agile et Leadership qui constitue la base pour l’examen « Agile Certified Practitioner » et qui est représentée par l’ovale en pointillé rouge ci-dessous.%%% > %%% > [((/dotclear/public/traductions/.agile-certified-practitioner-8_m.jpg|Agile Certified Practitioner 8||Agile Certified Practitioner 8))|/dotclear/public/traductions/agile-certified-practitioner-8.jpg]%%% > %%% > Dans ce modèle, nous pouvons cartographier toutes les Connaissances et Compétences (KS) et les Outils et techniques (TT) qui feront partie de l’examen, mais l’image devient assez vite surchargée, donc je ne présente qu’une vue partielle.%%% > %%% > [((/dotclear/public/traductions/.agile-certified-practitioner-9_m.jpg|Agile Certified Practitioner 9||Agile Certified Practitioner 9))|/dotclear/public/traductions/agile-certified-practitioner-9.jpg]%%% > %%% > Quoi qu’il en soit, j’espère que le modèle de boîte et le diagramme de Venn fournissent des moyens de comprendre le contenu. Les annonces officielles du PMI sur le calendrier seront faites le lundi 16 mai. Comme toujours, j’attends vos questions et commentaires.%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Attention à l’orig(i)nal !

Ça fait une dizaine de jours que je vis par procuration des __vacances au Québec__… grâce à __Antoine Vernois__ qui a blogué tout au long de son parcours. Chaque jour, je lisais son billet et pointais son trajet sur une carte google. Lisez ses billets qui sont une véritable invitation au voyage… « au roadtrip photo en Gaspésie » comme il dit sur ++[Son blog à lui qu’il a|http://antoine.vernois.net/dotclear/]++ 🙂 :%%% * ++[Des vacances agiles au Québec|http://antoine.vernois.net/dotclear/index.php?post/2011/06/08/Des-vacances-agiles-au-Quebec]++%%% * ++[Jour 1 : Toulouse -> Montréal -> Lévis|http://antoine.vernois.net/dotclear/index.php?post/2011/06/08/Jour-1-%3A-Toulouse-Montr%C3%A9al-L%C3%A9vis]++%%% * ++[Jour 2 : Lévis -> Rivière du Loup|http://antoine.vernois.net/dotclear/index.php?post/2011/06/10/Jour-2-%3A-L%C3%A9vis-Rivi%C3%A8re-du-Loup]++%%% * ++[Jour 3 : Rivière du Loup -> Matane|http://antoine.vernois.net/dotclear/index.php?post/2011/06/10/jour-3-%3A-Rivi%C3%A8re-du-Loup-Matane]++%%% * ++[Jour 4 : Réserve faunique de Matane|http://antoine.vernois.net/dotclear/index.php?post/2011/06/11/Jour-4-%3A-Reserve-faunique-de-Matane]++%%% * ++[Jour 5 : Matane -> Anse aux griffons|http://antoine.vernois.net/dotclear/index.php?post/2011/06/13/Jour-5-%3A-Matane-Anse-aux-griffons]++%%% * ++[Jour 6 : Anse au Griffon -> Percé|http://antoine.vernois.net/dotclear/index.php?post/2011/06/13/Jour-6-%3A-Anse-au-Griffon-Perc%C3%A9]++%%% * ++[Jour 7 : Percé|http://antoine.vernois.net/dotclear/index.php?post/2011/06/14/Jour-7-%3A-Perc%C3%A9]++%%% * ++[Jour 8 : Percé -> Bonaventure|http://antoine.vernois.net/dotclear/index.php?post/2011/06/16/Jour-8-%3A-Perc%C3%A9-Bonaventure]++%%% * ++[Jour 9 : Bonaventure -> Carleton|http://antoine.vernois.net/dotclear/index.php?post/2011/06/16/Jour-9-%3A-Bonaventure-Carleton]++%%% * ++[Jour 10 : Carleton -> Matane|http://antoine.vernois.net/dotclear/index.php?post/2011/06/17/Jour-10-%3A-Carleton-Matan]++%%% * ++[Jour 11 : Matane -> Lévis|http://antoine.vernois.net/dotclear/index.php?post/2011/06/18/Jour-11-%3A-Matane-L%C3%A9vis]++%%% * ++[Jour 12 : Lévis -> Montréal -> Toulouse|http://antoine.vernois.net/dotclear/index.php?post/2011/06/19/Jour-11-%3A-L%C3%A9vis-Montr%C3%A9al-Toulouse]++%%% * ++[Voyage en Gaspésie, les photos|http://antoine.vernois.net/dotclear/index.php?post/2011/07/01/Voyage-en-Gaspesie%2C-les-photos]++%%% %%% [((/dotclear/public/screenshots/.trajet-antoine-quebec_m.jpg|Trajet d’Antoine au Québec||Trajet d’Antoine au Québec))|/dotclear/public/screenshots/trajet-antoine-quebec.JPG]%%%

Equipe feature

((/dotclear/public/photos/.craig_larman_t.jpg|Craig Larman|L|Craig Larman)) ((/dotclear/public/photos/.bas_vodde_t.jpg|Bas Vodde|L|Bas Vodde))Suite à la traduction de l’article ++[« Avant qu’il existe un Management »|/dotclear/index.php?post/2011/06/09/Avant-qu-il-existe-un-management]++ de Mary Poppendieck, j’ai décidé de traduire l’article ++[« Feature Team Primer »|http://featureteamprimer.org/feature_team_primer.pdf]++ de __Craig Larman__ and __Bas Vodde__ qui abordent les concepts extrêmement intéressants d’équipes feature$$NdT : Feature teams$$ et de domaines fonctionnels$$NdT : Requirement areas$$ décrits dans leurs deux livres ++[Scaling Lean & Agile Development|http://www.amazon.fr/Scaling-Lean-Agile-Development-Organizational/dp/0321480961/ref=pd_sim_eb_1|en]++ et ++[Practices for Scaling Lean & Agile Development|http://www.amazon.fr/Practices-Scaling-Lean-Agile-Development/dp/0321636406/ref=pd_sim_eb_1|en]++… que je viens d’ajouter à ma liste d’envies.%%% %%% (c) 2010 Craig Larman and Bas Vodde – ++[www.featureteamprimer.org|http://www.featureteamprimer.org|en]++%%% %%% __Introduction aux équipes features__%%% %%% Une équipe feature, comme illustrée à la figure 1, est une équipe multi-composants, multi-fonctionnelles et pérenne$$Les membres d’une équipe features restent ensemble pendant des années, réalisant plusieurs features.$$ qui livre de nombreuses fonctionnalités bout-en-bout à ses clients, mais une à la fois.%%% %%% Figure 1 : équipe Feature%%% %%% [((/dotclear/public/traductions/.Equipe-Feature_m.jpg|Equipe Feature||Equipe Feature))|/dotclear/public/traductions/Equipe-Feature.png]%%% %%% Les caractéristiques d’une équipe feature sont énumérées ci-dessous :%%% * pérenne, les membres de l’équipe restent ensemble et forment un « noyau dur »%%% * très performante, l’équipe réalise de nouvelles fonctionnalités au fil de l’eau%%% * multi-fonctionnelles et multi-composantes%%% * idéalement, colocalisée%%% * travaille sur une fonctionnalité centrée sur le client et de bout en bout, en passant à travers tous les composants et toutes les disciplines (analyse, programmation, tests, …)%%% * composée de spécialistes se généralisant%%% * dans Scrum, habituellement 7 ± 2 personnes%%% %%% Appliquer des pratiques d’ingénierie modernes, en particulier l’intégration continue, est essentielle lorsque vous choisissez d’être une équipe feature. L’intégration continue facilite la propriété partagée du code, ce qui est nécessaire lorsque plusieurs équipes travaillent en même temps sur les mêmes composants.%%% %%% Un malentendu fréquent : chaque membre d’une équipe feature doit connaître l’ensemble du système. Pas forcément, parce que :%%% * L’équipe entière, et non chaque membre, doit avoir les compétences pour mettre en œuvre l’ensemble de la feature centrée sur le client. Il s’agit notamment de la connaissance des composants et de compétences fonctionnelles tels que les tests, la conception centrée utilisateur ou la programmation. Mais au sein de l’équipe, les gens continuent à être spécialisés … de préférence dans de multiples domaines.%%% * Les features ne sont pas réparties au hasard sur des équipes features. Les connaissances et compétences actuelles d’une équipe sont prises en compte pour décider quelle équipe va travailler sur quelles features.%%% %%% Dans une organisation basée sur des équipes feature, lorsque la spécialisation devient une contrainte… l’apprentissage commence.%%% %%% Une organisation basée sur des équipes feature exploite les avantages de la vitesse générée par la spécialisation, ceci tant que la cartographie des exigences correspond aux compétences des équipes.%%% %%% Mais lorsque les exigences ne correspondent pas aux compétences des équipes, l’apprentissage est « forcé », rompant ainsi la contrainte de sur-spécialisation.%%% %%% Les compétences d’une équipe feature s’équilibrent entre spécialisation et flexibilité.%%% %%% Le tableau 1 et la figure 2 suivantes mettent en évidence les différences entre les équipes feature et les équipes composants plus traditionnelles.%%% %%% Tableau 1 : équipes feature vs composant%%% ///html

Équipe feature Équipe composant
optimale pour livrer la valeur métier maximale (a) optimale pour livrer le nombre maximum de lignes de code
se concentre sur des features à forte valeur ajoutée et la productivité du système se concentre sur l’augmentation de la productivité individuelle en implémentant des features « faciles » de faible valeur
responsable de la feature de bout en bout et orientée client responsable seulement partiellement d’une feature orientée client
démarche « moderne » d’organisation des équipes (b) — évite la loi de Conway démarche traditionnelle d’organisation des équipes — respecte la loi de Conway (c)
conduit à se concentrer sur le client, à de la visibilité et à de plus petites organisations conduit à « réinventer » le travail et à des organisations sans cesse croissantes
minimise les dépendances entre les équipes et augmente la flexibilité les dépendances entre les équipes génèrent des efforts de planification supplémentaires (d)
met l’accent sur la multi-spécialisations met l’accent sur l’hyper-spécialisation
propriété collective du code produit propriété individuel du code
partage des responsabilités par l’équipe responsabilités clairement portées par chaque individu
s’appuie sur du développement itératif aboutit à un développement « cycle en V »
exploite la flexibilité ; apprentissage large et continu exploite l’expertise existante ; au plus bas concernant l’apprentissage de nouvelles compétences
requiert des pratiques d’ingénierie qualifiées, les effets sont largement visibles fonctionne avec des pratiques d’ingénierie bâclées, les effets restent localisés
fournit une motivation pour produire un code facile à maintenir et à tester contrairement à la croyance, génère souvent un code de faible qualité dans le composant
apparemment difficile à mettre en œuvre apparemment facile à mettre en œuvre

/// (a) Une optimisation différente peut donner  »l’impression » à l’équipe feature qu’elle est plus lente, d’un point de vue local.%%% (b) Relativement « moderne » puisque les équipes feature ont une longue histoire dans le développement à grande échelle, par exemple chez Microsoft et Ericsson.%%% (c) Mel Conway  »a observé » cette structure indésirable en1968, il ne la  »recommandait » pas, en fait c’était même tout le contraire.%%% (d) Cet effort de planification supplémentaire est visible dans la plupart des « réunions de planification de releases » ou « trains de release »” et génère un management inutile.%%% %%% Figure 2 : équipes feature vs composant%%% %%% [((/dotclear/public/traductions/.Equipes-feature-vs-composant_m.jpg|Equipes feature vs composant||Equipes feature vs composant))|/dotclear/public/traductions/Equipes-feature-vs-composant.PNG]%%% %%% Le tableau ci-dessous résume les différences entre les équipes feature et les projets traditionnels ou  »groupes feature ».%%% %%% Tableau 2 : Equipes feature vs Projets feature%%% ///html

Équipe feature Groupe/Projet feature
équipe stable dont les membres restent ensemble pendant des années et qui travaillent sur de nombreuses features groupe temporaire de personnes créé pour une feature ou un projet
responsabilité partagée par l’équipe sur toutes les tâches responsabilité individuelle des membres sur « leur » partie et basée sur la spécialisation
équipe auto-gérée contrôlée par un chef de projet
génère une organisation horizontale simple (pas de matrice !) génère une organisation matricielle avec des pools de ressources
les membres sont affectés à temps plein (100%) à l’équipe les membres sont à temps partiel sur de nombreux projets en raison de leur spécialisation

/// %%% La majorité des défauts des équipes composant sont explorés dans le chapitre « Feature Teams » du livre « Scaling Lean & Agile Development » ; la figure 3 en résume quelques-uns.%%% %%% Figure 3 : quelques défauts des équipes composant%%% %%% [((/dotclear/public/traductions/.Defauts-equipe-composant_m.jpg|Quelques défauts des équipes composant||Quelques défauts des équipes composant))|/dotclear/public/traductions/Defauts-equipe-composant.PNG]%%% %%% Ce qu’on ne voit pas parfois, c’est que la structure d’une équipe composant renforce le développement séquentiel (modèle de la « cascade » ou cycle en V) en générant beaucoup de files d’attente, des tâches de taille variable, des niveaux élevés de TAF$$NdT : WIP = Work in Progress – Travaux à Faire$$, de nombreux passages de relais, une augmentation du multitâches et l’affectation partielle des ressources.%%% %%% __Choisir des équipes composant ou des équipes feature ?__%%% %%% Une organisation basée uniquement sur des équipes feature est idéale d’un point de vue valeur ajoutée livrée et souplesse. Valeur et souplesse ne sont cependant pas les seuls critères pour construire une organisation, et de nombreuses organisations finissent par conséquent en mode hybride, plus particulièrement pendant la transition des équipes composant vers des équipes feature. Attention : les modèles hybrides ont les inconvénients des deux mondes et peuvent donc être… douloureux.%%% %%% Un motif fréquemment exprimé en faveur d’une organisation hybride est la nécessité de construire des infrastructures, des composants réutilisables, ou de nettoyer le code écrit au sein des équipes composant. Mais ces activités peuvent aussi être réalisées une organisation basée sur des équipes purement feature, sans établir d’équipes composant permanentes. Comment ? En ajoutant les besoins d’infrastructure, de composants réutilisables ou de travail de nettoyage dans le Backlog Produit et en le donnant tel quel à une équipe feature existante comme s’il s’agissait de feature centrée client. L’équipe feature réalise ces travaux pendant un certain temps – aussi longtemps que le Product Owner le permet – puis retourne au développement de features centrées client.%%% %%% __Evoluer vers des Equipes Feature__%%% %%% Différentes organisations exigent différentes stratégies de transition lors du passage d’équipes composant à des équipes feature. Nous avons l’expérience de nombreuses stratégies qui ont marché… et échoué dans un contexte différent. Une stratégie de transition sécurisée – mais lente – consiste à établir une seule équipe feature au sein de l’organisation basée sur des équipes composant. Une fois que cette équipe fonctionne bien, une deuxième équipe feature est formée. Cela continue progressivement selon un rythme adapté à l’organisation. Ceci est illustré à la Figure 4.%%% %%% Figure 4 : transition graduelle d’équipes composant vers des équipes feature%%% %%% [((/dotclear/public/traductions/.Transition-graduelle-equipe-composant-vers-feature_m.jpg|Transition graduelle des équipes composants vers feature||Transition graduelle des équipes composants vers feature))|/dotclear/public/traductions/Transition-graduelle-equipe-composant-vers-feature.PNG]%%% %%% __Introduction aux domaines fonctionnels__%%% %%% On peut créer des équipes features sans problème mais quand leur nombre dépasse dix, soit environ une centaine de personnes, une structure supplémentaire est nécessaire. Les domaines fonctionnels fournissent cette structure et étoffent les concepts derrière les équipes feature. Un domaine fonctionnel est une catégorisation des exigences menant à des vues différentes du Backlog Produit.%%% %%% Le Product Owner (PO) classe chaque item du Backlog Produit sous exactement une catégorie fonctionnelle, son domaine fonctionnel. Ensuite, il génère des vues différentes sur l’ensemble du Backlog Produit que l’on peut appeler un Backlog Domaine. Les Backlogs Domaines sont priorisés par Product Owner Domaine qui se spécialise dans une partie du produit et selon une perspective client. Chaque domaine fonctionnel comporte plsieurs équipes feature travaillant sur le Backlog Domaine, comme illustré à la Figure 5.%%% %%% Figure 5 : domaines fonctionnels%%% %%% [((/dotclear/public/traductions/.Domaines-fonctionnels_m.jpg|Domaines fonctionnels||Domaines fonctionnels))|/dotclear/public/traductions/Domaines-fonctionnels.PNG]%%% %%% Les domaines fonctionnels permettent de dimensionner correctement les équipes feature. Dimensionner en structurant les équipes en fonction de l’architecture du produit est appelé domaines de développement. Le tableau 3 résume les différences.%%% %%% Tableau 3 : domaines fonctionnels vs domaines de développement%%% ///html

Domaine fonctionnel Domaine de développement
organisé autour d’exigences centrées client organisé autour de l’architecture du produit
pas de propriété sur le code sous-système propriété du code pour chaque sous-système
de nature temporaire ; devrait changer au cours de la durée de vie du produit, mais pas à chaque itération tend à être plus figé sur la durée de vie du produit
on se concentre sur le client, en utilisant le langage du client on se concentre sur l’architecture, en utilisant le langage technique

/// %%% Finalement, un Product Owner Domaine est différent d’un Product Owner  »délégué » qui travaillerait avec une ou deux équipes pour aider un Product Owner  »débordé ». Un Product Owner Domaine a différentes responsabilités, se concentre et travaille avec (probablement) au moins  »quatre » équipes, pas seulement une. Cela évite des situations d’optimisation localisée aux activités d’une seule équipe.%%% %%% __Conclusion__%%% %%% Les équipes feature sont des équipes stables qui travaillent sur des features complètes et centrées client. Ces équipes apportent des solutions vis-à-vis des habituelles optimisations locales et travaux de coordination supplémentaires liés aux organisations basées sur des équipes composant. Cependant, ces équipes features doivent elles aussi relever des défis.%%% %%% Les différents domaines fonctionnels génèrent des vues centrées client sur la globalité du Backlog Produit et permettent donc de structurer et dimensionner les équipes feature à la taille voulue.%%% %%% __Références__%%% %%% [((/dotclear/public/traductions/.scaling-lean-agile-development_t.jpg|Scaling Lean Agile Development|L|Scaling Lean Agile Development))|/dotclear/public/traductions/scaling-lean-agile-development.PNG]++Scaling Lean & Agile Development – Chapitres :++%%% – Introduction%%% – Systems Thinking%%% – Lean%%% – Queueing Theory%%% – False Dichotomies%%% – Be Agile%%% – Feature Teams%%% – Teams%%% – Requirement Areas%%% – Organization%%% – Large-Scale Scrum%%% %%% [((/dotclear/public/traductions/.practices-for-scaling-lean-agile-development_t.jpg|Practices for Scaling Lean Agile Development|L|Practices for Scaling Lean Agile Development))|/dotclear/public/traductions/practices-for-scaling-lean-agile-development.PNG]++Practices for Scaling Lean & Agile Development – Chapitres :++%%% – Large-Scale Scrum%%% – Test%%% – Product Management%%% – Planning%%% – Coordination%%% – Requirements%%% – Design%%% – Legacy Code%%% – Continuous Integration%%% – Inspect & Adapt%%% – Multisite%%% – Offshort%%% – Contracts%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Rétrospective « Le Lean, la Totale Productive Maintenance (TPM) pour tous »

((/dotclear/public/logos/.Club-Lean-Aquitaine_m.jpg|Club Lean Aquitaine||Club Lean Aquitaine))%%% !!What went well%%% * Présentation très intéressante de l’activité d’AEROCAMPUS sur le Centre de Latresne par Marc PECHEUX. Le Centre de Formation de Latresne (CFLE) est repris par la région Aquitaine et devient AEROCAMPUS en septembre 2011. C’est une bonne nouvelle quand on sait que cette école était menacée de fermeture. AEROCAMPUS s’inscrit désormais dans la structuration d’un pôle européen de la maintenance aéronautique en Aquitaine. Il propose un cursus complet en maintenance aéronautique allant du bac au diplôme d’ingénieur.%%% * Présentation intéressante d’un exemple d’optimisation des flux dans l’industrie pharmaceutique par Sophie BOISSON (BMS AGEN). J’ai bien aimé la lutte des opérateurs contre le progiciel SAP pour réajuster les stocks à la main 50 fois par mois…%%% * Présentation très intéressante de la mise en pratique du Lean pour la prestation de service en maintenance industrielle par Eric SAINTCLAIR (AQMO Blanquefort) : management visuel, A3 de résolution de problèmes, …%%% * Bonne vidéo sur « Les métiers de la maintenance » dans la filière industrielle par Michel COURBATERE (GETRAG FORD)… valoriser ce métier par les jeunes pour les jeunes.%%% * Compte rendu de l’AG de Montargis par Jean Pierre RENAULT, Président de l’AFIM : la maintenance c’est 2,5% de la production en valeur, c’est 45000 emplois dont 12000 cadres.%%% * Ah oui, ma présentation « Devenir un Problem Solver » s’est bien passée, je pense être resté dans l’esprit de la conférence :)%%% !!What went wrong%%% * La visite de l’AIA Floirac (Atelier Industriel de l’Aéronautique) a pris beaucoup plus de temps que prévu : 1 heure de retard dans le programme, donc 2 sujets de conférence annulés : ** L’essentiel du Lean par Alain COUPETE (A2C)%%% ** Le lean et le développement durable en maintenance par Philippe KOCIEMBA (APAVE)%%% * Problèmes de version Powerpoint sur le PC de l’amphithéâtre… heureusement, Alain avait son Mac pour convertir les documents pptx en ppt !%%% !!Puzzles%%% * ++[PART66|http://www.dac.public.lu/services/espace_personnel/AML/index.html]++ ? définit les exigences en matière de connaissances, de qualifications et d’expérience des personnels destinés à prononcer la remise en service d’un aéronef.%%% * ++[PerfoLean|http://www.2adi.fr/telechargements/PerfoLean.pdf]++ ? action collective, organisée pour la mise en place d’un plan d’actions Lean dans une vingtaine de PMI d’Aquitaine de tous secteurs d’activités.%%% * ++[TRS|http://fr.wikipedia.org/wiki/Taux_de_rendement_synth%C3%A9tique]++ ? Taux de Rendement Synthétique.%%% !!Lessons (re-)learnt%%% * « On se concentrera sur les échanges entre les services ou les personnes. C’est en effet aux interfaces que l’on observe généralement une déperdition d’efficacité dans les services. » – Lean Services – Baglin & Capraro%%% * « Les personnels sont les capitaux les plus importants de la société et le déterminant de la croissance ou de l’effondrement de l’entreprise. » – Eiji Toyoda%%% !!Appreciations%%% * Merci aux organisateurs : l’AFIM Aquitaine, A2C et Le Club Lean Aquitaine.%%% * Merci au CFLE, ou plutôt AEROCAMPUS, de nous recevoir dans ses locaux.%%% * Merci aux orateurs : Alain, Philippe, Marc, Sophie, Eric, Michel, Jean-Pierre.%%% * Merci au Club Lean Aquitaine, et notamment à Jean-Pierre LESCURE, de m’avoir permis d’intervenir.%%% * Merci aux participants, et à la prochaine fois !%%% !!Links%%% * Site ++[2ADI|http://2adi.fr/]++ (Agence Aquitaine de Développement Industriel)%%% * Site ++[A2C|http://a2c-lean.fr/]++ (Aquitaine – Amélioration Continue de la Compétitivité)%%% * Site ++[AFIM|http://www.afim.asso.fr/]++ (Association française des ingénieurs et responsables de maintenance)%%% * Site ++[APAVE|http://www.apave.com/]++ (La maîtrise des risques)%%% * Site ++[AQMO|http://www.aqmo.fr/]++ (Ingénierie de Maintenance)%%% * Site ++[BMS France|http://www.bmsfrance.fr/]++ (Laboratoire pharmaceutique Bristol-Myers Squibb France – BMS UPSA)%%% * Site ++[CFLE|http://www.lp-flora-tristan.net/cfle/]++ (Centre de Formation de Latresne)%%% * Site ++[Club LEAN Aquitaine|http://www.lean-aquitaine.fr/]++ (contribuer à l’amélioration de la compétitivité des entreprises aquitaines déjà engagées dans des démarches de « Lean Management » en facilitant l’échange des bonnes pratiques)%%% * Site ++[GETRAG FORD|http://www.getrag.de/fr/108]++ (Production de transmissions manuelles et automatisées)%%% [((/dotclear/public/lean-aquitaine/.alain_s.jpg|Alain se bat avec le PC||Alain se bat avec le PC))|/dotclear/public/lean-aquitaine/alain.jpg] [((/dotclear/public/lean-aquitaine/.amphi_s.jpg|Une quarantaine de personnes dans l’amphi.||Une quarantaine de personnes dans l’amphi.))|/dotclear/public/lean-aquitaine/amphi.jpg]%%% %%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes rétrospectives sur le wiki ++[Rétrospectives Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/retrospective:start]++.