Criteria of a Good Coach

((/dotclear/public/punaise.JPG|Punaise|L|Punaise, aoû 2009)){{According to Sally Gunnell (former Olympic British Champion in the 400m hurdles), a good coach has the following attributes: 1°Treat people as individuals, 2°Use feedback as an opportunity to improve, 3°Always listens, 4°Always learning new techniques.}}%%% %%% Source : blog Selfish Programming de Portia Tung – ++[« It’s Hard to Say Goodbye »|http://www.selfishprogramming.com/2011/02/07/its-hard-to-say-goodbye/|en]++

Agile Coaching (10/14)

[((/dotclear/public/lectures/.agile_coaching_rds_t.jpg|Agile Coaching|L|Agile Coaching))|/dotclear/public/lectures/agile_coaching_rds.jpg]Découvrez comment coacher votre équipe pour qu’elle devienne plus Agile. __Agile coaching__ démystifie les pratiques agiles, il s’agit d’un guide pratique pour créer de solides équipes agiles. Enrichi avec les conseils utiles des coachs agiles __Rachel Davies__ et __Liz Sedley__, ce livre vous donne des outils de coaching que vous pouvez appliquer si vous êtes chef de projet, responsable technique ou membre d’une équipe de développement logiciel.%%% %%% %%% Je suis en train de le traduire  »patiemment et passionnément » :%%% * __06/02/2011__ – ++[chapitre 10 – Piloter le développement par les tests|/dokuwiki/doku.php/traduction:agilecoaching:10]++%%% * 29/10/2010 – ++[chapitre 9 – Réussir « Terminer »|/dokuwiki/doku.php/traduction:agilecoaching:9]++%%% * 12/07/2010 – ++[chapitre 8 – Rendre tout visible|/dokuwiki/doku.php/traduction:agilecoaching:8]++%%% * 05/07/2010 – ++[chapitre 7 – Planifier|/dokuwiki/doku.php/traduction:agilecoaching:7]++%%% * 21/06/2010 – ++[chapitre 6 – Comprendre ce qu’il faut construire|/dokuwiki/doku.php/traduction:agilecoaching:6]++%%% * 26/06/2010 – ++[chapitre 5 – Daily Standup|/dokuwiki/doku.php/traduction:agilecoaching:5]++%%% * 29/08/2010 – ++[chapitre 4 – Construire une équipe Agile|/dokuwiki/doku.php/traduction:agilecoaching:4]++%%% * 11/08/2010 – ++[chapitre 3 – Conduire le changement|/dokuwiki/doku.php/traduction:agilecoaching:3]++%%% * 23/07/2010 – ++[chapitre 2 – Travailler avec les gens|/dokuwiki/doku.php/traduction:agilecoaching:2]++%%% * 17/07/2010 – ++[chapitre 1 – Commencer le voyage|/dokuwiki/doku.php/traduction:agilecoaching:1]++%%% %%% Feedback :%%% * Antoine Vernois : ++[« Agile Coaching — Rachel Davies et Liz Sedley »|http://antoine.vernois.net/dotclear/index.php?post/2010/11/03/Agile-Coaching-Rachel-Davies-et-Liz-Sedley]++%%% * Yves Hanoulle : ++[« I finished reading the Agile coaching book »|http://www.hanoulle.be/2009/09/i-finished-reading-the-agile-coaching-book/|en]++%%% * Guillaume Vincent : ++[« Sémaphore du flux de productivité »|http://rolala.fr/?p=383]++%%% %%% —- ((/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]++.

Que faire lorsque Scrum ne fonctionne pas

((/dotclear/public/photos/.HenrikKniberg_sq.jpg|Henrik Kniberg|L|Henrik Kniberg))J’ai traduit cet article de Henrik Kniberg : ++[« What to do When Scrum Doesn’t Work »|http://www.scrumalliance.org/articles/332-what-to-do-when-scrum-doesnt-work|en]++.%%% > Cet article est basé sur mon ++[discours fait lors du Scrum Gathering à Cape Town|http://blog.crisp.se/henrikkniberg/2010/09/01/1283373060000.html|en]++ l’automne dernier.%%% > %%% > Scrum c’est super ! Sauf quand il ne l’est pas. Que faites-vous quand Scrum ne semble pas fonctionner ?%%% > %%% > __Diagnostic 1 : Mal utiliser le processus__%%% > %%% > Si votre réponse immédiate à l’échec est « Oh, ça veut dire que vous utilisiez mal Scrum », alors soyez prudent.%%% > %%% > Scrum est en effet souvent mal utilisé (dans ce cas, le remède est clair). Mais si vous arrivez à cette conclusion trop vite sans examiner la situation en jeu, alors vous êtes coupable de __Scrum-fondamentalisme__ (la croyance erronée que Scrum est toujours la bonne solution). La déclaration « Si votre projet a échoué, alors c’est que vous appliquiez mal Scrum » se transforme, par ++[transposition logique|http://en.wikipedia.org/wiki/Transposition_(logic)|en]++, en « Si vous appliquez bien Scrum, votre projet aurait réussi ». Rappelez-vous ce que Fred a dit au sujet des ++[balles d’argent|http://en.wikipedia.org/wiki/No_Silver_Bullet|en]++ !%%% > %%% > Alors, que faire si Scrum est bien utilisé et que le projet semble encore être un échec ?%%% > %%% > __Diagnostic 2 : Blâmer le messager__%%% > %%% > Scrum est conçu pour révéler les problèmes. Une fois, un client a annulé un projet après le premier sprint. En se basant sur la vélocité de l’équipe et de sa future vélocité estimée, le product owner a réalisé que ce projet prendrait beaucoup trop de temps pour être rentable. Alors il l’a annulé.%%% > %%% > Parfois, nous sommes tentés de tirer sur le messager : « Regardez, dès qu’ils ont commencé à faire du Scrum, le projet a explosé ! ». Heureusement, ils n’ont pas fait cela, ils ont réalisé que Scrum les avait aidé à économiser beaucoup d’argent en tuant un mauvais projet très tôt. Scrum a généré une « douleur saine ».%%% > %%% > Quand un problème est révélé par Scrum, concentrez-vous sur le problème, pas sur Scrum.%%% > %%% > Mais que faire si le problème semble être causé par Scrum ?%%% > %%% > __Diagnostic 3 : Être impatient__%%% > %%% > Le premier sprint, pour une nouvelle équipe, est généralement un véritable gâchis. Cela prend quelques sprints avant qu’une nouvelle équipe apprenne à collaborer efficacement. Des personnes impatientes pourraient tout de suite arriver à la conclusion que Scrum ne fonctionne pas : « Hé, regardez ce gâchis ! L’équipe n’a rien produit d’utile au cours du premier sprint, et ils ont passé la moitié du temps à discuter sur des chiffres sur des post-its ! ». Soyez patient, donner à l’équipe le temps de faire des erreurs et d’apprendre à partir de ces erreurs.%%% > %%% > Lorsque vous apprenez à jouer de la guitare (ou tout autre instrument de musique), cela ne sonne pas très bien au départ. Cela ne signifie pas que l’instrument ne fonctionne pas, cela signifie seulement que vous devez continuer à pratiquer et à veiller à continuellement vous améliorer.%%% > %%% > Donc, que se passe-t-il si nous sommes à bout de patience ? Que se passe-t-il si l’équipe a déroulé plusieurs sprints sans livrer quoi que ce soit ?%%% > %%% > __Diagnostic 4 : Ne pas adapter le processus__%%% > %%% > Supposons que vous appliquez Scrum « à la lettre » depuis maintenant plusieurs mois, et que vous vous tapez la tête constamment contre le même problème. Si vous continuez ainsi, vous allez être victime de __Scrum-masochisme__ (l’hypothèse erronée selon laquelle la douleur provoquée par Scrum est toujours une « douleur saine »).%%% > %%% > Il est temps de faire évoluer votre propre dialecte de Scrum.%%% > %%% > Oui, vous pouvez modifier Scrum. Et vous le devez. Mais seulement après vous être assuré que les diagnostics 1, 2 & 3 ne s’appliquent pas.%%% > %%% > Vous passez trop de temps à discuter pendant l’estimation des tâches ? Eliminer l’estimation des tâches, ou éliminez les tâches tout court.%%% > %%% > Vous passez trop de temps à discuter pendant l’estimation des stories ? Estimez alors en taille de T-shirt (S / M / L), ou arrêter d’estimer tout court. La vélocité peut se baser sur le nombre de stories plutôt que sur des points de story.%%% > %%% > Vous avez de la difficulté à comprendre la façon de répartir de manière cohérente 15 personnes dans de plus petites équipes ? Laissez-les se former et se réformer, comme un organisme vivant, au gré des fonctionnalités à implémenter.%%% > %%% > Est-ce que le product owner a désespérément besoin de changer quelque chose dans le sprint ? Laissez-les échanger la nouvelle story contre une story qui n’a pas encore été commencée au cours du sprint.%%% > %%% > Est-ce que ces changements amélioreront la situation ? Vous ne le saurez pas tant que vous n’aurez pas essayé.%%% > %%% > Est-ce encore du Scrum ? Je ne sais pas, mais est-ce vraiment important ? Tout ce qui fonctionne pour vous est bon, tout ce qui ne fonctionne pas pour vous est mauvais. Méfiez-vous de la __Scrumbut-phobie__ (peur de mal faire du Scrum ; symptôme : coincé au niveau ++[Shu|http://en.wikipedia.org/wiki/Shuhari|en]++).%%% > %%% > __Diagnostic 5 : Utiliser le mauvais processus__%%% > %%% > Il ya des contextes où Scrum n’est tout simplement pas approprié.%%% > %%% > Supposons que nous ayons une équipe d’exploitation, de maintenance ou de support dont l’objectif principal est d’être réactif. Elle fait du correctif et de l’évolutif mineurs chaque jour. Cette activité ne peut pas être rythmée dans des sprints parce que les priorités changent trop vite. Lorsque l’équipe a un peu de temps, elle travaille sur de longues tâches d’amélioration. Ces longues tâches ne sont pas bien dimensionnées pour s’adapter parfaitement à un sprint; elles sont divisés en morceaux de taille différente qui représentent la valeur client.%%% > %%% > Dans ce contexte, les sprints et les réunions de planification associées peuvent apparaître comme une perte de temps.%%% > %%% > Les autres principes de Scrum – des équipes multidisciplinaires, des mêlées quotidiennes, … – peuvent être conservés. Les itérations et d’autres rythmes de travail peuvent être appliqués. Mais un sprint est une boîte de temps de durée fixe, avec un périmètre fixe et parfois ce n’est pas le bon outil pour travailler.%%% > %%% > Dans ce contexte, ++[Kanban|http://www.crisp.se/kanban|en]++ se propage rapidement. Les limites WIP de Kanban fournissent le même type de « stress positif pour livrer » que les sprints en Scrum, mais d’une manière différente. Les itérations ne sont pas la seule façon d’être Agile, en fait les itérations ne sont même pas mentionnées dans le ++[manifeste Agile|http://www.agilemanifesto.org/|en]++ ou dans les ++[principes de l’Agile|http://www.agilemanifesto.org/principles.html|en]++.%%% > %%% > __Résumé : Que faire lorsque Scrum ne fonctionne pas__%%% > %%% > Le point clé est de __ne pas sauter hâtivement aux mauvaises conclusions__. Comme tout bon médecin, diagnostiquez le problème avant de suggérer un remède (++[les diagrammes de causes à effet|http://blog.crisp.se/henrikkniberg/2009/09/29/1254176460000.html|en]++ marchent très bien dans ce cas).%%% > %%% > Faites bien la différence entre « Mal utiliser l’outil » et « Utiliser le mauvais outil ».%%% > %%% > Et quoi que vous fassiez, ne blâmez pas l’outil. Scrum ne réussit pas ou n’échoue pas, ce sont les gens qui le font. Les gens choisissent où, quand, comment et pourquoi appliquer Scrum.%%% —- ((/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]++.

Comment réaliser le Sprint Planning 2

((/dotclear/public/photos/.Peter-Stevens_sq.jpg|Peter Stevens|L|Peter Stevens))J’ai traduit l’article de __Peter Stevens__ : ++[« How we do Sprint Planning 2″|http://www.scrum-breakfast.com/2011/02/how-we-do-sprint-planning-2.html|en]++.%%% > Beaucoup de gens pensent que le Sprint Planning 2 (la seconde mi-temps de la réunion de Sprint Planning) concerne juste la création et l’estimation de la liste des tâches concernant la sélection faite dans le backlog produit. Il s’agit d’une simplification excessive ! Voici une démarche simple pour effectuer une réunion de Sprint Planning 2 efficace.%%% > %%% > Lors du Sprint Planning 1, l’Equipe de développement et le Product Owner négocient les stories qui seront mises en oeuvre dans le sprint à venir. L’équipe s’assure qu’elle comprend bien les stories, en particulier les critères d’acceptation (je recommande de se mettre d’accord sur la question « Comment faire la Démo ? »).%%% > %%% > Au cours du Sprint Planning 2, l’Equipe de développement doit trouver une façon de résoudre le problème pris lors du Sprint Planning 1. Cela peut se décomposer en deux parties :%%% > 1. La conception de la solution – une conception, une architecture, … qui explique comment le problème doit être résolu / comment la fonctionnalité doit être réalisée.%%% > 2. La liste de tâches – les étapes que doit franchir l’équipe pour que chaque item sélectionné dans le backlog passe à l’état « Fini ».%%% > %%% > Dans mon travail de coaching, j’ai trouvé qu’il était efficace que les membres de l’équipe travaillent en binôme selon une séquence résoudre-présenter-résoudre-présenter. Ils réfléchissent à la conception technique, puis ils la présentent à l’équipe. En fonction des réactions, ils peuvent avoir besoin d’améliorer, modifier ou peut-être même repenser la conception. Puis, toujours en binôme, ils créent des cartes pour les tâches, montrant ainsi le chemin qu’il reste à parcourir vers l’état « Fini ». Enfin, chaque binôme présente ces tâches au reste de l’équipe.%%% > %%% > Supposons que l’équipe se soit engagée sur 6 stories, qu’il y a 6 membres dans l’équipe et que l’équipe fait des sprints de 2 semaines. La durée du Sprint Planning 2 est alors limitée à 2 heures. L’équipe forme 3 binômes et chaque binôme travaille sur deux stories. L’ordre du jour de la réunion est donc le suivant :%%% > %%% > Ordre du jour du Sprint Planning 2 :%%% > %%% > 14h00 – 14h05 : Démarrage – binômer et répartir les stories entre binômes.%%% > 14h05 – 14h35 : Conception – chaque binôme réfléchit à la conception technique (sous forme d’un diagramme, d’un texte ou de quelque chose qui peut être présenté au reste de l’équipe).%%% > 14h35 – 15h05 : Présentation – chaque binôme présente ses solutions au reste de l’équipe. Le temps de présentation et de questions/réponses de chaque story est limité à un total de 5 minutes (30 minutes / 6 Stories).%%% > 15h05 – 15h35 : Tâches – chaque binôme crée un ensemble de tâches pour amener ses stories à l’état « Fini ». Chaque tâche représente un objectif pour la journée. Les tâches ne sont pas estimées mais doivent pouvoir être réalisées en moins d’une journée de travail. Ceci permet d’économiser beaucoup d’efforts !%%% > 15h35 – 16h00 : Présentation – une fois de plus, chaque binôme présente les tâches nécessaires pour finir ses stories. Au cours de la discussion, ils peuvent découvrir des tâches manquantes ou inutiles. Chaque présentation de story est limitée à 4 minutes (25 minutes / 6 Stories).%%% > %%% > Cette approche garantit qu’au minimum 2 personnes ont passé du temps à réfléchir sur chaque story. Cela structure la réunion et permet à l’équipe de mener la réunion dans le délai fixé. De plus, en présentant et en discutant de la solution avec toute l’équipe, le reste de l’équipe est bien mieux placé pour donner un coup de main au cours de l’exécution du sprint.%%% —- ((/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]++.

Story Time, la réunion Scrum cachée

((/dotclear/public/photos/.kane-mar_sq.jpg|Kane Mar|L|Kane Mar))Suite à une discussion sur les activités liées à la préparation d’un backlog produit (avec Mathieu, l’un de mes collègues agilistes), j’ai traduit cet article de __Kane Mar__$$About the author: Kane Mar is an international Scrum Coach and Trainer, based in Australia. He has trained over 1000 people in over 30 countries, and worked with large multinational corporations such as Microsoft, Oracle, Telstra, and Capital One. His blog on Scrum and software can be found here: ++[Scrumology Pty Ltd|http://Scrumology.com|en]++$$ qui nous décrit la réunion Story Time : ++[« STORY-TIME! THE HIDDEN SCRUM MEETING »|http://kanemar.com/2008/02/14/story-time-the-hidden-scrum-meeting/]++.%%% > Est-ce que votre équipe a des difficultés à prévoir lorsque le projet sera terminé ? Avez-vous un grand nombre de stories non-estimées dans votre backlog produit ? Vos réunions de planification traînent-elles longuement sur plusieurs journées en générant beaucoup de discussions ? Si c’est le cas, il se pourrait que vous ayez tendance à oublier de « nettoyer » régulièrement votre backlog produit.%%% > %%% > Ken Schwaber conseille généralement que l’équipe consacre cinq pour cent de son temps (à chaque sprint) sur la préparation du backlog. Ce procédé est généralement connu sous le nom de « nettoyage »$$NdT : grooming$$ ou maintenance. Voici une bonne définition de ce que cela implique :%%% > %%% > {{Il y a beaucoup de choses que l’on fait dans le backlog pour préparer les futurs travaux. On ajoute de nouvelles stories et epics$$NdT : epics = grosses stories$$, on découpe des epics en stories, on estime, on ajoute la valeur métier espérée, et ainsi de suite. Dr. Dan Rawsthorne, CST}}%%% > %%% > J’ai récemment travaillé avec plusieurs clients qui approuvent la recommandation des cinq pour cent de Schwaber, mais qui en fait ne l’applique pas. Ils comprennent bien qu’ils ont besoin de passer cinq pour cent de leur temps sur la maintenance du backlog, mais ils ne le font pas et, par conséquent, leurs réunions de planification deviennent tendues et très longues.%%% > %%% > Depuis plusieurs années, je préconise explicitement la maintenance du backlog comme faisant partie intégrante du processus Scrum. Je conseille aux équipes de tenir périodiquement une réunion de deux heures chaque semaine. C’est une occasion de discuter et de maintenir le backlog, de sorte que la réunion de planification puisse être aussi efficace et productive que possible. J’appelle ces réunions « Story Time ». Ce n’est pas un nouveau concept. Quand je travaillais exclusivement avec des équipes XP il y a plusieurs années, il était de pratique courante de tenir régulièrement une réunion Story Time. Bien que ça ne fasse pas officiellement partie de Scrum, j’ai découvert que le Story Time améliorait grandement la planification des projets et diminuait significativement les risques de discussions interminables qui apparaissent trop souvent dans de nombreuses équipes.%%% > %%% > Une réunion Story Time devrait se tenir à la même heure et au même endroit chaque semaine et impliquer toute l’équipe, y compris le Product Owner et le ScrumMaster. Le seul but de ces réunions hebdomadaires est de travailler sur le backlog produit pour préparer les futurs travaux. Ceci peut aussi inclure l’ajout de nouvelles stories et epics, le découpage de grosses stories et l’estimation.%%% > %%% > Donc, si le Product Owner et les Développeurs de votre équipe passent la majorité du temps de la réunion de planification à discuter sémantique, essayez les réunions de Story Time pour vous permettre d’être plus efficace dans vos prévisions. Je serais curieux de savoir comment cela impacte votre métier au jour le jour.%%% —- ((/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]++.