Archive

Archive for the ‘Agile’ Category

Construire des règles d’équipe

April 16th, 2010 1 comment

Lors d’une rétrospective, que j’ai animé à la demande d’une équipe1 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 icon wink Construire des règles déquipe . 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
26032010572 225x300 Construire des règles déquipe

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!
26032010573 225x300 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 icon wink Construire des règles dé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.

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

April 8th, 2010 2 comments

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.

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’exeercice, 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 icon wink Estimer un carnet de produit complet en 2 heures : Wall Planning Poker ! 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! icon wink Estimer un carnet de produit complet en 2 heures : Wall Planning Poker

  1. time-box

tous_assis_devant_un_écran VS debout_devant_le_mur_avec_des_Post-it!

April 1st, 2010 3 comments
le match du jour 300x225 tous assis devant un écran VS debout devant le mur avec des Post it!

À 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.

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

February 25th, 2010 Comments off
photo bordeaux 300x199 Animer une rétrospective déquipe est une belle opportunité dintégration.

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 produit1 é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 icon wink Animer une rétrospective déquipe est une belle opportunité dintégration. .

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’2.

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 ?

  1. Propriétaire de produit : Product Owner (PO)
  2. 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é! »

Categories: Agile Tags:

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

February 11th, 2010 Comments off
odeur de melee astuces pour progresser 300x300 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’?