Agile

January 23rd, 2010 Leave a comment Go to comments

Un coach agile doit-il exposer ou préserver l’équipe?

AgileGardener : May 6, 2010 5:05 am : Agile, Coaching

Un coach agile doit-il exposer ou préserver l'équipe?

Laisser l'équipe faire des erreurs pour apprendre (photo par http://www.flickr.com/photos/sayonara/)

Je ne vous apprendrai rien en vous disant que j’accompagne des équipes lors de leur transition agile!

En tant qu’accompagnateur agile, je veille à être à l’écoute des membres du groupe pour les aider à trouver leur propre chemin vers leur succès. J’ai toujours en tête l’idée de n’être qu’une béquille temporaire, avec l’objectif, comme toute béquille, de permettre à l’équipe de progresser seule lorsque je quitte le mandat.

Cependant, lors d’une transition agile, l’équipe doit faire fasse aux difficultés du changement et comme beaucoup de personnes doit faire ses expériences pour comprendre certaines modifications de comportement que l’on essaie de mettre en oeuvre.

Ma posture est habituellement d’expliquer à l’équipe les valeurs du manifeste agile, et selon l’approche choisie, souvent Scrum, les principes et quelques règles qui guident cette approche.

Cependant, après avoir expliqué ceci à l’équipe, je l’assiste pour qu’elle trouve ses propres solutions aux problèmes auxquels elle doit faire face. Il arrive que je propose des alternatives, mais en bout de ligne, j’impose peux de choses, uniquement quelques règles de base, en expliquant aux participants qu’ils pourront les remettre en cause lorsqu’ils comprendront les implications de celles-ci.

Il arrive donc souvent que l’équipe fasse des choix qui peuvent la conduire dans une impasse, voir « dans le mur ». Lorsque je perçois cette impasse, j’en avise l’équipe, mais je la laisse suivre son chemin si elle ne souhaite pas m’écouter. Cependant, je travaille à réduire la taille du mur car je pense qu’une équipe en apprentissage, hors de sa zone de confort est plus fragile.

Finalement, en tant qu’accompagnateur agile, et comme l’équipe à besoin de faire ses propres expériences, mon but est de conduire rapidement l’équipe face au mur, tout en minimisant la taille de celui-ci et dans le même temps, de préparer le futur.

Pour illustrer la démarche, je dirai qu’après avoir prévenu l’équipe qu’il est bon de se préparer (rapidement) pour une revue d’itération ou bien qu’il est important de travailler sur les user stories dans l’ordre établi par le propriétaire de produit, je n’insiste pas et je n’oblige pas l’équipe à le faire.

Pour une équipe qui débute dans une approche agile, les exemples ci-dessus sont des pièges fréquents. Mais en laissant l’équipe expérimenter ces problèmes très tôt en ne l’en protégeant pas, je peux aborder avec elle des discussions intéressantes qui lui permettent de comprendre le nouveau comportement attendu et qui mènent souvent à des nouvelles solutions encore (et toujours) prises par l’équipe. Ces pièges restent plutôt de l’ordre de la marche que du mur.

Cependant je me demande souvent si c’est la bonne approche, si je devrais être plus directif?

Qu’en pensez-vous? Quelle est votre approche?

8 Comments »

Les points de visibilité en Scrum : comment choisir la longueur des itérations?

AgileGardener : April 22, 2010 5:10 am : Agile

Les points de visibilité en Scrum : comment choisir la longueur des itérations?

Les points de visibilité en Scrum : comment choisir la longueur des itérations?

Choisir la longueur des itérations en Scrum est une décision délicate qui a son importance pour le bon fonctionnement de l’équipe et du projet. Il faut trouver le bon compromis entre un rythme soutenable pour l’équipe et la souplesse de pilotage des priorités par le propriétaire de produit.

Si la littérature originale de Scrum[1. Agile Software Development with Scrum] préconise des itérations d’une durée de un mois, la réalité est souvent différente. Depuis la publication du livre Agile Software Development with Scrum, les choses ont évolué et, dans la pratique, j’ai vu des équipes choisir des longueurs d’itérations allant de deux à six semaines, dans ce dernier cas peut-on encore parler de Scrum me direz-vous avec raison!

À chaque fois le choix est difficile, il demande un compromis entre la fréquence des points de visibilité[2. Un point de visibilité est la séquence des rencontres suivantes de Scrum : revue d’itération suivie de la planification d’itération. En effet, c’est le moment d’observer l’avancement de l’équipe et de réajuster les priorités en fonction des objectifs du projet.] offerte au propriétaire de produit (et aux parties prenantes du projet) et la capacité de l’équipe à livrer des incréments du logiciel en qualité production de façon récurrente. Ce choix peut aussi mettre en jeu bien d’autres facteurs, comme par exemple la capacité du propriétaire de produit ou des membres de l’organisation à suivre et ajuster l’horaire de plusieurs équipes.

Le choix de la longueur des itérations s’effectue souvent lors des rencontres de démarrage du projet, pendant la période de trois à cinq jours qui permet de bâtir l’équipe, de planifier et de lancer la première itération. De mon expérience, ce choix est souvent fait selon le schéma suivant :

  • Le propriétaire de produit propose la date de première livraison.
  • Le propriétaire de produit choisi un nombre de points de visibilité au cours de cette durée en fonction des différentes longueurs d’itérations possibles.
  • L’équipe et le propriétaire de produit négocie la durée la plus adaptée.

Par exemple, pour une livraison dans trois mois nous obtenons le tableau suivant :

Taille du sprint (en semaine) Nombre de points de visibilité
2 5
3 3
4 2
6 1

On se rend compte alors de l’importance de bien choisir la longueur des itérations pour un pilotage optimum du projet du point de vue du propriétaire de produit.

Cependant, la capacité de l’équipe à livrer des incréments du logiciel de qualité production doit être prise en compte. Et bien que livrer souvent puisse être difficile pour  les équipes, elles doivent aussi se rendre compte que c’est un avantage pour elles d’avoir l’occasion de s’ajuster en profitant des rétrospectives[3. voir les billets suivants au sujet des rétrospectives :

Pour ma part, mon choix va à des itérations de 2 semaines. Elles sont parfois difficiles à accepter pour des équipes débutantes en Scrum, mais je pense que c’est une durée intéressante pour ces équipes notamment. Cela leur permet de s’ajuster fréquemment, de comprendre ce qu’elles sont capables de livrer en peu de temps, de comprendre l’importance, par exemple, d’automatiser les tests ou bien le processus de déploiement. Cela permet aussi de créer une dynamique de construction d’équipe intéressante par le biais des rétrospectives qui reviennent vites et qui permettent ainsi de ne pas laisser ‘pourrir’ des problèmes tant que l’équipe n’est pas encore assez mature pour les traiter au fil de l’eau.

Et vous, vos itérations s’étalent-elles sur 1, 2, 3, 4 semaines? Plus encore?

Je suis curieux de connaître vos choix en matière de longueur d’itération ainsi que la logique qui y conduit, alors n’hésitez pas à laisser des commentaires :-).

12 Comments »

Construire des règles d’équipe

AgileGardener : April 16, 2010 9:50 am : Agile, Coaching

Lors d’une rétrospective, que j’ai animé à la demande d’une équipe[1. Il est intéressant pour une équipe que sa rétrospective soit animée, à l’occasion, par une autre personne que le ScrumMaster. Cela peut être un membre de l’équipe, le ScrumMaster d’une autre équipe ou bien une personne extérieure, un accompagnateur agile, ce qui était mon cas. Au delà de changer la dynamique, cela permet au ScrumMaster de participer pleinement à la rétrospective.] 4 mois après l’avoir aidé à faire ses premiers pas en Scrum, j’ai proposé un atelier sur la gestion des attentes au sein de l’équipe.

Au cours des 4 mois j’ai entendu plusieurs fois des phrases telles que la suivante : « Certaines personnes parlent d’une façon que je trouve parfois déplacée. Je ne sais pas quoi faire avec ça. » Je demandais alors à la personne si elle avait parlé, aux membres de l’équipe, de cette attente concernant la façon de s’exprimer dans le groupe. Bien souvent la réponse était : « non! »

Cet exemple est loin d’être le seul, je le retrouve souvent en tant que coéquipier ou en tant qu’accompagnateur. Très souvent les membres d’un groupe souhaitent un comportement des autres membres sans jamais avoir exprimé l’attente de ce comportement. Habituellement chacun adopte le comportement qu’il pense être celui que le groupe attend ou bien celui que la personne à l’habitude d’avoir. On se rend compte que la responsabilité est partagée, on pourrait renversé la discussion et chacun pourrait demandé aux autres si tel ou tel comportement à un impact ‘négatif’ sur eux.

Le but de l’atelier était donc de permettre à chacun d’exprimer ses attentes. Je visais à les rendre explicites envers les autres membres du groupe et ultimement, j’espérais voir l’équipe se construire un espace d’attentes communes et parler des comportements respectifs dans différentes situations vécues ensemble.

La session de travail s’est très bien déroulée et au final, les attentes communes ont émergé. Elles sont mêmes devenues des règles d’équipes et des objectifs à atteindre en tant qu’équipe.

Satisfait du résultat de cet atelier, j’ai eu l’envie de le partager ;-). En voici donc le déroulement tel qu’expérimenté.

L’atelier

Le matériel : des Post-it ou des cartes, des stylos, des murs ou des tables

L’agenda en trois parties tel que je l’ai proposé :

  1. Mes attents (25 min)
  2. Nos attentes (30 min)
  3. Une équipe ! (30 min)

Remarque : Nous avons utilisé 1h30 pour effectuer cet atelier, mais il aurait mérité plus de temps, notamment les parties 2 et 3 parce que les échanges étaient riches et certaines sujets demandent du temps pour être pleinement exprimés.

Mes attentes

Construire des règles d'équipes

Résultat final de l'atelier de gestion des attentes - les régles d'équipe

J’avais réservé 25 minutes pour la première partie.

Dans cette phase chacun pose sur papier ses attentes personnelles, une par Post-it ou carte.

En tant qu’animateur lorsque j’ai présenté l’exercice, j’ai essayé de donner quelques exemples de situations, quelques exemples de comportements que moi j’attends, mais qui ne sont pas la façon de faire ou de réagir de tous.

L’exercice s’arrête à la fin de la période de 25 minutes. Si tout le monde semble avoir terminé avant, assurez vous tout de même de laisser quelques minutes pour une dernière idée.

Nos attentes

L’objectif de cette deuxième phase est d’établir les attentes communes à un sous-groupe.

Pour cela, j’ai séparé le groupe en 2. (Remarque : au delà de 5 personnes par équipe il est sans doute judicieux de faire 3 équipes pour maximiser les échanges et la participation de tous.)

Pendant la période, les membres de chaque sous-groupe, après les avoir affichées au mur, présentent leurs attentes aux autres. Ensuite le groupe essaie de créer un espace d’attentes communes. Pour matérialiser cet espace commun, j’ai demandé aux groupes de placer les Post-it en commun au centre d’une zone délimitée par les Post-it de leur attentes personnelles.

Dans ce cas, le groupe n’a pas gardé les attentes personnelles autour des attentes collectives, je suis curieux de voir ce que cela donnerait au final

Comme je l’ai mentionné plus tôt, cette période aurait mérité un peu plus de temps, mais c’est surtout la période suivante qui demande de réserver plus de temps du fait de la taille du groupe.

Une équipe!

Construire des règles d'équipe

Résultat final de l'atelier de gestion des attentes - les objectifs d'équipe

L’objectif de cette dernière partie est d’établir les attentes collectives de tout le groupe en rassemblant les attentes communes de chaque sous-groupe.

Pour cela, j’ai réuni tout le groupe et j’ai demandé aux participants de présenter les attentes de son groupe. Ensuite j’ai demandé de refaire le même exercice que précédemment, établir un espace des attentes communes tout en préservant les attentes personnelles en périphérie.

Comme lors de la précédente partie, la mise en commun a été le moment de discussion et de négociations très intéressantes et ouvertes des membres de l’équipe. Comme lors de la précédente partie, l’équipe n’a pas conservé les Post-it d’attentes personnelles autour de la zone commune.

Une fois la zone collective établie, j’ai demandé à l’équipe de regrouper ces attentes dans les 2 groupes suivants : les « règles d’équipe », les « objectifs d’équipe »

Du fait du nombre de personne et de la teneur des discussions, il faudrait prévoir plus de temps pour cette partie. Je pense que 45 minutes est un minimum.

Le résultat final est illustré par les deux photos ci-contre.

Pour conclure

L’équipe a beaucoup apprécié cet atelier. Malheureusement nous avons manqué de temps et certains ont du quitté avant la fin. Je réserverai  2h pour la prochaine fois et voici l’agenda que je compte utiliser :

  1. Mes attents (25 min)
  2. Nos attentes (35 min)
  3. Une équipe ! (45 min)

Je suis cependant très content d’avoir expérimenté cet atelier avec l’équipe et surtout je suis très content de la participation de l’équipe et de son engagement pendant tout l’exercice.

Je serai curieux de l’impact de garder visibles, autour des règles et des objectifs communs, les attentes personnelles de chacun.

J’envisage maintenant d’utiliser cet atelier lors de la ‘construction’ d’une équipe lors du warm-up d’un projet.

Si vous avez déjà mis en œuvre un tel atelier ou que vous essayé celui-ci, n’hésitez pas à partager vos retours d’expérience, je suis avide d’idées nouvelles 😉

11 Comments »

Estimer un carnet de produit complet en 2 heures : Wall Planning Poker

AgileGardener : April 8, 2010 12:05 am : Agile

En quelques semaines, j’ai eu l’opportunité d’animer à plusieurs reprises un atelier d’estimation de l’ensemble d’un carnet de produit.

Le but de cet atelier, aussi appelé Wall Planning Poker®, est d’estimer de façon relative un grand nombre de User Stories en un temps limité[1. time-box].

Cet atelier est basé sur l’estimation en Planning Poker lors des séances de planification d’itération, cependant, l’équipe n’utilise pas les cartes de planning poker, elle réalise l’estimation en plaçant les User Stories au mur (ou sur une grande table) par rapport au nombre de points évalués. On insiste évidemment beaucoup le côté relatif de l’estimation. Le but de l’exercice, je le rappelle, est d’obtenir une idée de l’ampleur du carnet de produit.

Certes, avec une estimation rapide l’équipe va faire des erreurs, et c’est normal! D’ailleurs, n’en fait-elle pas lors de l’estimation des User Stories pour une seule itération? Pour abaisser le risque d’erreur, l’équipe choisit des User Stories étalons qu’elle révise et publie chacun dans leur “case” respective au mur. De plus, par expérience, j’estime que les cartes surévaluées compensent globalement les cartes sous-évaluées.

Un élément important à la réussite de l’atelier est de passer à l’équipe le message clair que l’estimation n’est pas définitive. Lorsque les User Stories seront inclues dans une itération, elles seront réévaluées par en fonction des éléments d’information acquis à ce moment là. (Mesdames, Messieurs les propriétaires de produit, ce message est aussi pour vous!)

Une fois les étalons établis et les messages passés sur l’estimation relative et non définitive c’est le moment de s’y mettre.

Prévoyez au moins 2 heures pour l’atelier. Si l’équipe n’a jamais estimé auparavant, prévoyez de passer du temps pour établir les premières estimations et obtenir  ainsi vos étalons. Je vous conseille d’ailleurs, dans ce cas, de séparer l’évaluation “détaillée” d’une première itération de l’atelier proprement dit, l’équipe ayant l’opportunité de construire ainsi ses étalons.

Même s’il est préférable que tout le monde participe simultanément à l’estimation de toutes les User Stories, j’ai remarqué dans la pratique que la constitution d’équipes de 4 à 5 personnes est plus efficace. Pourquoi? Pour les deux raisons suivantes principalement :

  • Les discussions dans un groupe 4 ou 5 personnes sont plus riches et surtout moins longues.
  • La division permet de faire une revue de l’estimation de chacun des groupes par un autre groupe.

Comment se déroule l’atelier?

  1. Constituez des équipes de 4 ou 5 personnes multidisciplinaires et multicompétences. Insistez sur le fait de bien répartir les connaissances et compétences dans les équipes.
  2. Distribuez à chacune des équipes des cartes sur lesquelles vous avez imprimé les User Stories du carnet de produit. Essayez dans la mesure du possible de séparer les cartes en conservant groupés les Épics ou les processus. Cela facilite souvent l’estimation du fait de bénéficier de la vue globale de la fonctionnalité. Pensez à vous assurez que si la boîte de temps achève, les User Stories les plus prioritaires auront été estimées.
  3. Chaque équipe bénéficie du temps préalablement déterminé (prévoir 1h à 1,5h) pour classer les cartes au mur. Dans le cas de plusieurs équipes réalisant l’exercice simultanément, avoir trop de monde près du mur peut être gênant. Dans ce cas proposez aux équipes d’utiliser une table avant de reporter leurs cartes au mur.
  4. Une variante de l’exercice consiste à ne pas affecter de points aux cartes tout de suite. Il est intéressant de classer les cartes par rapport à l’effort relatif pour réaliser la fonctionnalité, puis, une fois toutes les cartes évaluées réaliser le pointage au mur.
  5. Une fois toutes les User Stories estimées au mur, demandez à chaque équipe de revoir les cartes pointées par les autres équipes (donner comme consigne, au début de l’atelier, à chaque équipe d’identifier les cartes qu’elle évalue par un signe distinctif). Chacune des équipes restant bien entendu à la disposition des autres pour expliquer un choix. S’il s’avère nécessaire, après discussion, de déplacer des User Stories, faites-le! L’avantage de cette pratique au delà de permettre un croisement des estimations, est de générer des discussions avec tous les participants et de vérifier que chaque équipe est restée proche des estimées étalons. Prévoyez 30 min à 45 min pour cette partie de l’atelier.
  6. Pour conclure l’atelier, comme pour tout atelier ou pour toute réunion importante, prévoyez 15 minutes pour une petite rétrospective.

Le résultat de cet atelier est spectaculaire. Il donne à l’équipe une vue globale du carnet de produit et permet au propriétaire de produit de planifier les futures livraisons, de construire un roadmap. Il permet aussi d’évaluer la faisabilité du projet par rapport aux dates envisagées et de prendre des décisions éclairées sur la stratégie à mener pour réussir vos projets. Cela est d’autant plus vrai et plus pertinent que vous connaissez la vélocité de votre équipe.

Si vous avez des expériences à partager concernant cet ateliers ou des ateliers similaires, laissez-moi un commentaire ;-)! Si vous avez des questions écrivez-moi (tbalbous à pyxis-tech point com)

Si vous avez besoin d’aide, je serai ravi de venir animer cet atelier dans votre équipe. Contactez moi! 😉

9 Comments »

tous_assis_devant_un_écran VS debout_devant_le_mur_avec_des_Post-it!

AgileGardener : April 1, 2010 12:05 am : Agile

 Le match du jour : tous_assis_devant_un_écran VS debout_devant_le_mur_avec_des_post-it by Dunechaser http://www.flickr.com/photos/dunechaser/

À ma droite "tous_assis_devant_un_écran" et à ma gauche "debout_devant_le_mur_avec_des_post-it"

Le match du jour oppose les tous_assis_devant_un_écran à l’équipe debout_devant_le_mur_avec_des_Post-it!
Le cri de guerre de cette dernière résonne encore!

« Lâchez votre écran lors du découpage en tâches des User Stories! Levez vous et aimez les Post-it! »

Ces dernières semaines j’ai assisté à de nombreuses séances de planification d’équipes Scrum. Après avoir estimé les User Stories, et s’être engagée, l’équipe attaque le découpage en tâches. La constante, pour la plupart des équipes, est le manque cruel d’énergie et l’ambiance morose qui règne pour ne pas dire l’apathie.

À chaque fois j’entends des plaintes ressemblant à la suivante : « C’est long, c’est plate, on bâcle ça pour être débarrassés. Mais du coup, pendant l’itération nous sommes obligés de revoir le découpage, et nos estimations en heure sont souvent mauvaises (sous-estimées) »

En observant le fonctionnement de ces équipes lors de leur séance de planification, je comprends mieux pourquoi « c’est long et plate! ». Les équipes sont assises autour d’une table au milieu de laquelle trônent vidéo-projecteur et ordinateur portable, ce dernier étant piloté la plupart du temps par le ScrumMaster. Tout le monde regarde l’écran projeté diffusant l’interface du logiciel de gestion du carnet de produit dans lequel le ScrumMaster ajoute les tâches en direct.

S’il vous plaît, si vous êtes colocalisés, arrêtez d’utiliser votre outils de gestion de carnet de produit lors de la séance de découpage en tâches des User Stories. Tout le monde s’ennuie pendant qu’une seule personne utilise le clavier. Si en plus, votre outil n’est pas ergonomique et ne permet pas d’accompagner le flux d’idées de façon efficace, la seule chose que vous obtenez ce sont des coéquipiers qui ‘décrochent’ et s’endorment petit à petit.

En plein milieu d’une séance, j’ai demandé à l’une des équipes tous_assis_devant_un_écran de tout arrêter et de d’aller chercher des Post-it puis de faire le découpage à la façon de l’équipe debout_devant_le_mur_avec_des_Post-it!

Vous me croirez ou pas, mais il n’y avait pas de Post-it dans la pièce! Et même une fois les petites feuilles de papier jaune et collantes entre les mains, personne n’avait de stylo pour écrire dessus!

Mais, une fois ses membres équipés de stylos, le résultat de l’équipe debout_devant_le_mur_avec_des_Post-it a été fantastique. L’équipe s’est réveillée. En quelques minutes, tout le monde était autour de la table ou proche du mur et participait activement à la conversation.

En révisant les tâches afin de les (ré)estimer, debout_devant_le_mur_avec_des_Post-it les à réajuster, à trouver des tâches manquantes et à éliminer celles devenues superflues du fait de la réorganisation du travail.

Bref, un vrai plaisir de voir l’équipe debout_devant_le_mur_avec_des_Post-it écraser par KO les tous_assis_devant_un_écran.

Dans votre équipe, comment se passe le découpage en tâchess des User Stories de l’itération? Est-ce un meeting dynamique et plaisant à la debout_devant_le_mur_avec_des_Post-it ou bien un meeting des plus ennuyeux à la tous_assis_devant_un_écran?

Quelles sont vos astuces pour rendre les séances de découpage efficaces et intéressantes.

9 Comments »

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

AgileGardener : February 25, 2010 12:05 am : Agile

Animer une rétrospective d'équipe est une belle opportunité d'intégration. Photo by Béranger Zyla http://www.flickr.com/photos/bzyla/

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

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

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

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

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

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

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

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

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

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

Un poulet et un cochon discute ensemble lorsque le poulet déclare « Démarrons un restaurant ensemble! »
Le cochon y réfléchit et dit, « Et comment allons-nous appeler ce restaurant ?»
Le poulet de dire, « Jambon et œufs!
Le cochon de répliquer, « Non merci, je vais être totalement engagé, et toi seulement impliqué! »

].

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

Avez-vous des expériences semblables à partager ?

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

4 Comments »

Odeurs de mêlée quotidienne – Astuces pour progresser

AgileGardener : February 11, 2010 12:05 am : Agile, Coaching

Odeurs de mêlée quotidienne - Astuces pour progresser

Astuces d'équipe pour améliorer la mêlée quotidienne

Il y a quelques jours j’ai publié « Odeurs de mêlée quotidienne », article dans lequel j’évoquais des symptômes observés lors de mêlées quotidiennes.

Depuis, l’équipe a fait des progrès très intéressants que je souhaite partager.

Les symptômes présentés dans le premier billet sont répétés ci-dessous accompagnés des solutions ou bien des étapes des solutions mises en œuvre.

L’équipe ne répond pas aux 3 questions.

Afficher les 3 questions pour que l’équipe puisse les voir facilement chaque matin. Mais, comme on pouvait s’y attendre, le fait d’afficher les 3 questions, n’a pas eu l’effet attendu. Cette solution ne venait pas de l’équipe qui n’en a donc pas tenu compte. Pour que la mêlée quotidienne s’améliore, il faut aider l’équipe à se l’approprier.

Montrer l’exemple. Dans ce deuxième essai, à la fin de la mêlée, j’ai repris un comportement observé et je l’ai rejoué pour présenter un exemple de l’intervention attendue de chacun des membres de l’équipe. Il peut être bon de répéter le processus de temps en temps pour aider l’équipe à progresser.

L’équipe ne s’approprie pas la gestion du tableau et des graphiques de progression (burndowns).

  1. Éloigner le ScrumMaster pendant un jour ou deux, ou bien, profiter de son absence. Pendant ce temps là, l’équipe continue à faire sa mêlée quotidienne.
  2. Au retour du ScrumMaster, attendre la fin de la mêlée et poser la question suivante : « Êtes-vous confiant en votre engagement? […] Quand je regarde le graphique, je ne suis pas en mesure de le savoir. » La conséquence directe de cette dernière question : une belle discussion, de très bonnes interrogations sur le fonctionnement et l’utilité des graphiques visuels et une prise en charge des graphiques par plusieurs membres de l’équipe.
  3. Reposer  ensuite la question de l’engagement à plusieurs reprises. L’équipe se la pose toute seule très rapidement.

L’équipe rapporte son occupation de la veille au tableau ou bien au ScrumMaster, sans regarder les coéquipiers avec pour effet de bord ‘d’autoriser’ des conversations parallèles.

  1. Éloigner l’équipe du tableau. La première fois l’équipe est déstabilisée, mais les coéquipiers comprennent vite qu’il est préférable de se préparer avant la mêlée et forment un cercle pour se parler.
  2. Proposer au ScrumMaster de sortir du cercle pendant quelques temps. En se positionnant en arrière il bénéficie d’un poste d’observation privilégié. N’étant plus visible  des membres de l’équipe, ceux-ci ne peuvent plus lui parler directement et lui rapporter l’activité de la veille. Inviter le ScrumMaster à intervenir à la fin pour donner de l’information au besoin.
  3. Le respect de la parole est régulé par l’utilisation d’un objet de parole que l’équipe s’approprie et se passe de main en main.

Les effets de ces petites astuces se sont très vite fait sentir dans l’équipe avec pour conséquences immédiates de ramener la mêlée à 10 minutes et à son utilité première, c’est-à-dire, un moment de synchronisation de l’équipe. Il reste alors 5 minutes pour des informations complémentaires, mettre à jour les graphiques d’avancement, ou bien retourner travailler plus vite sur les tâches de l’itération en cours.

Ces astuces ont permis de progresser rapidement vers une mêlée quotidienne beaucoup plus efficace, menée dans un temps plus court.

Un grand bravo à l’équipe pour ses apprentissages.

Et vous, quels sont vos ‘trucs’?

8 Comments »

Odeurs de mêlée quotidienne

AgileGardener : January 28, 2010 12:05 am : Agile, Coaching

Photo de mêlée (attribuée à http://www.flickr.com/photos/cdm/)

Photo de mêlée attribuée à http://www.flickr.com/photos/cdm/

Il y a quelques semaines de cela, après plusieurs jours sans intervenir auprès de l’équipe, j’ai pu observer, lors de mon retour, une mêlée quotidienne[1. Daily Scrum] avec quelques dysfonctionnements.

Avertissement :

Ce que vous lirez n’est pas un jugement, ce que j’ai observé ne constitue pas à mes yeux des erreurs, mais démontre plutôt un apprentissage naissant de la mêlée quotidienne.

Contexte :

  • L’équipe a terminé une première itération et s’apprêtait à commencer la deuxième.
  • Finalement, elle stabilise pendant une semaine l’application pour une release annoncée très tard. Son passé l’a rattrapé et la date ne peut être manquée.
  • De façon autonome, l’équipe a gardé les nouvelles pratiques mises en place dans la première itération et n’est pas retombée dans le mode “panique livraison” du passé.
  • Je suis présent le jour de la mise en ligne et elle a lieu sans que l’équipe n’ai eu à faire de temps supplémentaire.

Symptômes observés :

  • La ScrumMaster(SM) donne la parole à tour de rôle : “c’est à toi Louis”, Louis fait le tour de la table pour venir parler.
  • Une personne fait du reporting face tableau ou tournée vers le ScrumMaster,  et des conversations parallèles ont lieu.
  • Personne ne donne un statut sur le format des 3 questions[2. Qu’ai-je fait hier ? Que vais-je faire aujourd’hui ? Ai-je besoin d’aide ?]
  • Le tableau de l’équipe n’est pas à jour. Le statut des toutes les tâches est mis à jour en direct, le tableau ne reflète l’état d’avancement qu’après l’intervention. Cela fait perdre du temps et provoque des cassures de rythme dans la prise de parole.
  • Il y a par moment des personnes en retrait ce qui donne deux “épaisseurs” au groupe.
  • La ScrumMaster demande plusieurs fois ce que l’on fait de certaines tâches au tableau avant d’obtenir une réponse.
  • Un bureau gêne l’espace devant le tableau, personne ne le déplace.
  • Une personne est occupée pour la mise en ligne, elle n’intervient pas du tout et ne donne pas de statut aux autres membres de l’équipe.
  • Deux personnes sont assises.
  • Finalement, la mêlée dépasse de 5 minutes le temps imparti.

Debrief et plan d’action :

À la suite de la mêlée quotidienne, je prends quelques minutes avec la ScrumMaster pour lui demander comment elle a perçu cette mêlée, comment elle se sent. Ce que je trouve formidable c’est qu’en quelques secondes elle m’a donnée la plupart des observations ci-dessus assorties de commentaires pertinents : “c’est comme s’ils n’avaient pas encore pris la mesure le l’utilité de mettre à jour le tableau” par exemple.

S’en est suivi un dialogue ressemblant à celui ci-dessous :

SM : “Mais comment je peux faire pour changer le comportement de l’équipe pendant la mêlée ?”

Moi : “Quel est le comportement qui te dérange le plus ?”

SM : “Je dois dire aux personnes de venir quand c’est leur tour”.

Moi : “Que pourrais-tu faire le plus simple pour changer cela”

SM : ” Tu m’as déjà dis de ne pas intervenir, de laisser l’équipe faire son daily”

Moi : “Oui effectivement, peut-être pourrais-tu rappeler à l’équipe ce que tu attends pendant le daily : qu’ils fassent un statut vers l’équipe, en répondant aux 3 questions puis les laisser continuer sans intervenir, en laissant des blancs, des silences s’il y en a. Je t’inviterai à le faire rapidement sans forcement attendre une rétrospective.”

SM : “C’est vrai, je pourrais faire ça, mais ils ne répondent pas aux 3 questions”

Moi : “Les connaissent-ils, peut-être ont-ils besoins que quelqu’un rappellele ces questions”

SM : “Pour qu’ils les voient les questions ont pourrait les afficher”

Moi : “C’est une très bonne idée ça, avoir les trois questions affichées ça permet de se les mettre en tête à chaque mêlée”

Et nous avons continué la conversation encore quelques minutes.

Finalement, le bureau qui gêne devant le tableau va être poussé un peu, les questions vont être affichées, la SM va répéter le comportement attendu lors du daily et laisser l’équipe aller. Les résultats dans un prochain billet 😉

Dans vos organisations ou dans vos équipes, comment se passent vos mêlées quotidiennes, observez vous d’autres symptômes ?

Si vous êtes coach ou ScrumMaster, comment intervenez vous pour que l’équipe prenne conscience et règle ces symptômes ?

[Mise à jour]

Pour découvrir la suite voir le billet : « Odeurs de mêlée quotidienne – Astuces pour progresser »

5 Comments »

Une équipe Scrum peut-elle vivre sans ScrumMaster ‘officiel’ ?

AgileGardener : January 14, 2010 12:05 am : Agile

une équipe peut-elle vivre sans ScrumMaster officiel

Une équipe peut-elle vivre sans ScrumMaster 'officiel'?

L’été dernier j’ai rejoint un projet qui avait démarré 15 mois auparavant. L’équipe chargée du développement était répartie entre 3 sites (1 à Montréal, 2 à Bordeaux). Peu après mon arrivée, il y a eu réorganisation des équipes, et dans notre équipe, nous avons proposé de ne pas avoir de ScrumMaster ‘officiel’. La question suivante se posait donc pour nous :

Une équipe Scrum peut-elle vivre sans ScrumMaster ‘officiel’?

Je dois dire tout de suite que nous n’avons pas eu le loisir de pousser très loin l’expérimentation car le projet a été interrompu environ 6 semaines après la réorganisation. Nous avons tout de même travaillé avec ce modèle pendant 2 itérations[1. Itération : Sprint].

Cette équipe était composée de 3 personnes. Deux étaient présentes depuis longtemps : depuis le début pour l’un et depuis 10 mois pour l’autre. Puis il y avait moi, nouveau sur le projet. Le coéquipier leader naturel travaillait depuis plusieurs mois sur le module dont nous avions la charge. Il y avait une bonne cohésion, nous étions à l’aise avec Scrum et nous nous sentions en contrôle!

Nous tenions notre mêlée quotidienne[2. Mêlée quotidienne : Daily Scrum] sans difficultés. Nous allions à tour de rôle à la mêlée des mêlées[3. Mêlée des mêlées : Scrum of Scrums] — cette pratique était déjà en place  bien avant la réorganisation. Nous faisions la maintenance du carnet de produit[4. Carnet de produit : Product backlog] régulièrement avec le propriétaire de produit[5. Propriétaire de produit : Product Owner]. Nous aidions tous à l’organisation de l’équipe, même si une très grosse partie du travail était réalisée par le leader de l’équipe.

Voici les avantages obtenus lors de ce projet

  • Nous nous sentions vraiment autonomes. Nous organisions nous même nos rencontres importantes (mêlée quotidienne, maintenance du carnet de produit, réunion avec les intervenants extérieurs).
  • Nous étions beaucoup plus responsables. Lorsque quelque chose allait de travers, nous ne pouvions pas dire :  «Le ScrumMaster ne fait pas son boulot ».
  • Nous avions une bonne flexibilité, mais ce point relève petut-être du fait que nous n’étions que trois.
  • Contrairement à ce que j’ai vu à maintes reprises, personne dans l’équipe n’était perçu comme ‘supérieur hiérarchique’.

Nous n’avons pas subi d’inconvénients, mais peut-être y en aurait-il eu à long terme.

Cependant je suis convaincu d’une chose : il y a un préalable. Cela peut fonctionner à la condition que l’équipe soit mature, tant sur le plan des personnes qui la compose que  sur le plan de la maîtrise des outils, du processus Scrum et de la communication. Je vous invite à lire, sur un thème similaire, le retour d’expérience d’Isabelle Therrien, où elle fait mention des dérives qui peuvent se produire. Dans les commentaires notamment, il est question de prendre du recul, ce qui n’est pas toujours simple quand on a la tête dans le code pour livrer de la valeur à longueur de journée.

Résumé en quelques lignes, le choix de ne pas avoir de ScrumMaster ‘officiel’ peut paraître rapide ou évident, mais tout ceci ne s’est pas décidé en un jour. De fait, même une fois en place, les questionnements suivants revenaient de façon récurrente dans nos conversations :

  • S’il fait fonction de ScrumMaster, le leader doit-il prendre le titre et s’exposer?
  • Ce rôle peut il être partagé, et dans ce cas, est-ce efficace?

Pour conclure, je dois dire que j’ai aimé cette expérience. Même si cela n’a pas duré bien longtemps, j’ai vu les prémices de quelque chose que je voulais vérifier depuis longtemps : « le rôle de ScrumMaster est un rôle temporaire, il a pour objectif de rendre son équipe capable de se passer de sa présence, et cela peut fonctionner ».

Avez-vous des retours d’expérience similaires à partager ?

7 Comments »

Agile Tour 2009 à Montréal c’est COMPLET

AgileGardener : October 26, 2009 11:53 pm : Agile

La première conférence Agile Tour à Montréal débute dans quelques heures et malheureusement pour les derniers arrivés, c’est COMPLET.

200 heureux participants vont profiter du programme de conférence suivant :

The one thing you need to know
Mary Poppendiek

L’Agilité s’impose dans toute l’entreprise
Jérôme Barrand

Agile et le management : le chaînon manquant
Bruno Collet

An Introduction to Business Value Engineering
Joseph Little

Introduction à Kanban et expérience pratique chez IBM Bromont
Benoit Lapointe

Convergences entre CMMI et les approches Agiles (Scrum, XP, etc.)
Richard Basque

L’Agilité dans des projets d’envergure
Léo Lachance

Le Daily Scrum pour les équipes distribuées
Steffan Surdek

Cartographier votre valeur
Louis-Philippe Carignan

Both sides of the story! Go out and motivate people to make exciting changes
Gino Marckx

Agile Mythbusters: What People Are Really Doing in Practice
Scott W. Ambler

Les 7 péchés capitaux du développeur
Freddy Mallet

Bien testé ou mal testé? Telle est la question!
Ludovic Dubois

Suivez l’événement sur twitter avec les tags #at09mtl et / ou #agiletour ou bien

Au plaisir de vous voir sur place 🙂 car je fais partie de l’équipe d’organisation

7 Comments »
« Page 1, 2, 3, 4 »