Agile Gardener

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¹ é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’².

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 ?

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’?

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¹ 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²
• 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 ?

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

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² sans difficultés. Nous allions à tour de rôle à la mêlée des mêlées³ — cette pratique était déjà en place  bien avant la réorganisation. Nous faisions la maintenance du carnet de produit⁴ régulièrement avec le propriétaire de produit⁵. 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 ?

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

Retrouvez les Pyxissiens lors des étapes canadiennes de l’Agile Tour, le lundi 26 octobre à Québec et le mardi 27 octobre à Montréal ou l’événement se tiendra à guichet fermé et rassemblera 200 personnes.

Retrouvez toutes les présentations des Pyxissiens sur le site

http://sedevelopperagilement.com/

Profitez de l’événement pour vous offrir le timer _agilely pour Ipod/Iphone et le T-shirt “What did you stand-up for today ?” en vente sur place.
La totalité des recettes de la vente des T-shirts et des applications Ipod/Iphone va à FIAN
(pour en savoir un peu plus sur l’implication de Pyxis auprès de FIAN)

Au plaisir de vous rencontrer à Montréal

UPDATE [17th august 2009] : english version available Can you grow a business profitably while improving the lives of people?

François et Martin se sont livrés à un exercice très intéressant dont vous pouvez lire le résultat : Peut-on faire croître une entreprise de manière profitable tout en améliorant la vie des gens et en s’amusant

Les personne qui se posait la question, “Pourquoi Tremeur a-t-il traversé l’Atlantique pour aller travailler à Pyxis ?”, auront une partie de la réponse et comprendront je l’espère que ces choses font du sens pour moi. Les mots qui sont écrits là ne sont pas du vent. Tout n’est pas encore parfait, mais les choses avances, j’aime (et je suis fier) y participer. Mon travail prend sens !

Ce long dialogue entre Martin et François va d’ailleurs bien au delà de Pyxis et propose une voie (et voix) différente et bien plus large que la seule organisation Pyxis

J’ai bien hâte de lire vos commentaires en bas du billet sur le blog de Pyxis, abonnez-vous au fil RSS

J’attends vos commentaires sur mon nouveau billet sur le blog Pyxis

Éric Mignot dans son billet intitulé “Qu’est ce que Scrum ?” définit Scrum par la phrase suivante :

Scrum est un processus empirique qui se concentre sur lalivraison d’incréments de logiciel développés dans des blocs de temps par une équipe auto-organisée qui choisit itérativement son engagement dans un carnet de produit priorisé par un Product Owner.Celui des quatres piliers de Scrum qui a mon avis représente un défi technique pour les développeurs est “livraison d’incréments de logiciel développés dans des blocs de temps”
Mais pourquoi est-ce un défi ?

Faisons le point

Répondez par oui ou par non aux questions suivantes :

Lire la suite : http://pyxis-tech.com/blog/index.php/2009/06/08/scrum-est-un-defi-pour-le-developpeur

I use write my blogs using XMind. More and more people at Pyxis use XMind or MindManager daily, and the group of bloggers is slowly growing . As there is a great prize for bloggers next month, I want to share some “tricks”, maybe that will help you to write more blogs and to pick a chance to win !

What is coming next

• How do I create content ?
• How do I organize that content ?
• How do I write the post ?
• How do I publish it ?

How do I create the content of a blog ?

The first step is to produce the content that will be write down as core text of the post

Put the idea as the root

I rarely choose the title of my blog up-front.
Most often I just write an idea as the root of my map.
I’ll rename it later to mirror the title of that blog.

Brainstorm on this idea

At this step I put all my ideas on the map. I never try to organize them in a reading / writing manner.
I want to let most my ideas on the topic to flow out of my brain. I’ll have time later to reorganize content.

How do I organize that content ?

You now have a lot of ideas, it’s time to select the best ones !

Choose the hot topic for the post

After the first brainstorm, I usually have more idea than I need. Some are fakes, some are far from my initial ideas, some are grouped as whole topic.
At this step, I make a choice ! I reduce the whole tree map to a sub-group of branches on which I’ll concentrate my effort.
Usually it’s the “hot topic”.

Organize ideas from the brainstorming phase

I do not throw away the whole map, I just pick a part of it that I reorganize. I group, split, reorder branches and ideas.
At the end of this step, I still have words or small groups of words, and I usually have about 3 to 5 words as a primary branches, the main topics of the post.

Develop the plan

Each primary branch will be the title of post’s section in the blog.
At that moment I begin to rewrite words to a more “title-ish” way. Words become sentences, my blog is on the way !

How do I write the post ?

Blog posts are not only a following of sections’ titles. You need to create concrete content. Now that I’ve a great plan, it’s time to fill the holes !

Some months ago I used to proceed as follow :

1. Export ideas as a plan
2. Complete the text in my blogging tool

Recently, I moved a bit futher using XMind

Complete paragraphs using notes

For each primary or secondary branches I’ve previously created, I now add the body of the paragraph as a note.
I can also link to images, to files or whatever attachment available with XMind.

Choose a title

On the “last” iteration I have enough content to choose a relevant title for the blog. However, sometimes, I already have the title at this step. It has popped-out during one of the iteration.

How do I publish it ?

XMind allows you to export in a variety of differents formats. I used to export my blog either in plain text or HTML but for other purpose you can use PDF (XMind Pro).

Export as plain text

Plain text is my format of choice.
I prefer to export the map as plain text since I found easier to manually format the text in HTML.
I also use it when I want to insert my content in a Wiki or save it in Wiki Markup format.

Export as HTML

HTML is easy to insert in blogging tools (Dotclear or Wordpress). You can just open the HTML source code exported, and copy-paste the body part as your post.
But you have to know that the HTML generated by XMind is not really clean. If you want to have a clean HTML, you will have to do some work.

Tune it and press ‘Save’

It’s time to read the whole text and to adjust the prose.
I still have to press ‘Save’ !
Now I’m done !

All of this is done incrementaty and iteratively

All of this seems to be a bit to “Waterfall”. In fact, it is more like iterative and incremental waterfall ! I write things in a step by step manner, and I usually, make at least 4 to 6 iterations, increasing incrementaly the content. Each iteration is the place for refactorings, enrichments… But at the end of a “sprint” the whole text is in a “potentially shippable” state.

Hopes it will help !
Have fun blogging

The power of Pair Programming is neglected at Pyxis!

Par tremeur balbous, mardi 12 mai 2009 à 08:47 :: Développement logiciel

Promoted by eXtreme Programming, Pair Programming (PP) has always been one of the most discussed practice. Most successful Agile teams report they use pair programming as a daily work habit. Other teams may have success even when not using PP, but they would probably do a far better job using it.

As developers often recognize some benefits, they more often have great arguments to stay away of that powerful technique.

Widely recognized benefits are that PP : …

via The power of Pair Programming is neglected at Pyxis! – Pyxis Technologies.