jeudi 24 novembre 2011

Mes deux cents : "Prendre 3 minutes pour préparer son daily scrum !"

Jusqu'ici, j'ai participé à des projets Scrum en tant que développeur. Je ne suis ni scrum master, ni product owner, "juste" un membre de l'équipe.

En tant que membre de l'équipe (développeur, testeur ou architecte), vous êtes protégé pendant le sprint des perturbations extérieures par votre scrum master.
Ok ça c'est cool de sa part, mais être une équipe auto-organisée implique aussi que chacun apporte sa contribution. On vote lors des planning poker et on s'exprime pendant les rétrospectives.

Une chose pourtant sur laquelle je voudrais qu'on insiste, c'est la participation et la contribution des membres d'une équipe au daily scrum (ou daily stand-up meeting).

Au premier abord, ce rituel semble facile à appréhender : piece of cake ? Pas tant que ça si on ne se prépare pas un minimum. J'ai connu des daily scrum où des intervenants dépassaient largement un temps de parole raisonnable (autour de la minute normalement), entrainant ainsi un dépassement du quart d'heure alloué en général à cette réunion. Pourquoi ? Et bien parcequ'ils n'avaient pas préparé leur speech en vue de répondre aux trois questions : Qu'ai-je fait hier ? Qu'est-ce-que je compte faire aujourd'hui ? Ai-je des points de blocage ?

Je le redis : si court soit-il, le daily scrum se prépare ! Quand j'arrive à 9h30 et que le daily scrum est à 10h, je trouvais 3 minutes pour préparer ma petite intervention (de préférence avant le café du matin parceque le temps passe vite quand on papote avec les collègues :)

C'est assez rapide : je jette un oeil sur mon cahier pour me remémorer ce que j'ai fait. Si je suis organisé, je tiens à jour une ToDo List de ce que je dois faire. Je peux aussi anticiper un peu et me poser la question de qui aurait une expertise sur les points bloquants. Une anti-sèche est autorisée et tout projet Scrum possède un stock conséquent de post-it. N'hésitez pas à y noter vos tâches. Je ne recommande cependant pas d'emmener un cahier, c'est un peu trop formel pour un stand-up, et on peut y lister trop de choses : vous n'avez qu'une minute pour parler ! :P

Je choisissais aussi à l'avance mes mots, pas grand chose mais juste ce qu'il faut pour avoir un discours fluide non pollué de "euh... et puis après je euh...". Ca a l'air évident et de bon sens ainsi présenté (comme tout ce qui touche à l'Agile :) mais ce n'est pas appliqué par tout le monde. Scrum est sympa à suivre mais chacun doit y mettre du sien pour que ça s'écoule facilement.

Une bonne pratique que j'ai depuis pas mal d'année maintenant est de m'imprimer un calendrier chaque mois avec des cases suffisamment grandes pour y inscrire de façon succinct ce que je fais chaque jour : pas sous la forme "j'ai travaillé sur le module de recherche des clients" mais plutôt "US 79 - rech. client". Ca vous remet en tête en un clin d'oeil ce que vous avez fait tel ou tel jour !
Une façon rapide de s'imprimer un calendrier est de le faire depuis Outlook :)
Autre avantage : il s'avère que sur mon premier projet Scrum, chaque développeur effectuait la démonstration de ses user story en fin de sprint. Le calendrier me donnait une vue rapide des user story que j'avais traitées pendant le sprint, donc celles que j'aurais à montrer au product owner.

mercredi 23 novembre 2011

Evénements : "En route pour l'Agile Tour Paris 2011"

Le mardi 6 décembre 2011 aura lieu à Issy-les-Moulineaux sur le campus Microsoft l'étape parisienne de l'Agile Tour 2011.

Au menu, des conférences sur l'Agile : Scrum, Kanban, des retours d'expérience, des serious games, etc...

Je ne pourrai pas assister à toutes les conférences et c'est bien dommage... :(

En tout cas, vous pourrez me suivre au fil de cette journée sur mon twitter @HingCChan !

mardi 22 novembre 2011

Mes deux cents : "Scrum is fun"

Un côté de Scrum que je tenais à aborder est le fun que j'ai eu à appliquer cette méthode au sein des projets auxquels j'ai pu participer.

Il y a de nombreux avantages dans l'Agile et Scrum : l'auto-organisation de l'équipe qui motive et responsabilise ses membres, la relation forte et de confiance avec le client, l'amélioration des livrables et tout le tralala... En tant que développeur, mon travail est valorisé (en démo et en rétrospective), je suis motivé parcequ'on m'écoute (daily scrum), on me laisse faire des choix et donner mon avis (planning-poker, vote de confiance, note d'itération). C'est clair : travailler sous pression constamment, ça ne me fait pas plaisir. Qu'un chef ne pointe que mes erreurs, ça me démotive. Avoir une relation conflictuelle avec mon client ne me fait pas me sentir utile.

Mais sérieusement, si Scrum était une méthodologie ennuyeuse et lourde, je ne pense pas que j'aurais été autant réceptif à l'époque où je la découvrais, malgré les avantages annoncés.

En débarquant sur mon premier projet Scrum, j'ai découvert un monde peu commun. On m'a raconté l'histoire du poulet et du cochon, on m'a parlé de concepts comme les pizza team, j'ai participé à du planning poker... Des concepts rigolos à intégrer pour participer à des rituels un peu bizarres. En tant que novice, j'étais amusé. Et c'était là que ça s'est joué : tout ceci était vraiment fun, d'où mon envie d'en connaitre toujours plus sur la méthode et d'en débattre avec tous les membres de l'équipe et au-delà !

Conclusion : le fun est un facilitateur (haha ! on l'aime ce terme ! :)
Le fun est une force. Mais ne vous méprenez pas : je ne parle pas de s'amuser au lieu de travailler, je parle de travailler dans une bonne ambiance et une émulation de tous les jours car on en a envie. Il n'y a pas besoin de faire cela par la contrainte et la pression. Si c'est fun de bien travailler et de produire de la qualité, ce sont les membres de l'équipe qui auront envie de progresser et c'est le projet qui avancera.

jeudi 17 novembre 2011

Mes deux cents : "Lean/Scrum/XP"

Pour préparer ma première présentation Scrum, je m'étais mis à la recherche d'un schéma situant Scrum par rapport au Lean et à l'eXtreme Programming (XP).
Voici celui que l'on trouve généralement (enfin celui-ci est dessiné par mes soins) :
Ici, XP est contenu entièrement dans Scrum.
Cependant, à la suite de discussions (plus ou moins animées) autour de Scrum et Agile avec des collègues, je représenterais plutôt Scrum comme dans le schéma ci-dessous :
Scrum intègre des outils d'eXtreme Programming comme les sprints (itérations en XP) ou le planning poker. Par contre, le pair programming par exemple n'était pas systématiquement employé sur les projets Scrum auxquels j'ai participé.

samedi 12 novembre 2011

Lecture : "Scrum et XP depuis les tranchées" d'Henrik Kniberg


Ce livre est clairement un must-have.
D'ailleurs il est gratuit et téléchargeable ici donc vous n'avez aucune raison de ne pas le posséder :)

A qui s'adresse-t-il ? Je dirais à un développeur qui va intervenir sur un projet Scrum mais est débutant dans cette méthodologie (en fait c'était moi là).
D'ailleurs, quand un développeur qui ne connaissait pas Scrum rejoignait notre équipe, je recommandais systématiquement la lecture de ce livre, avec le sourire en coin amusé du Scrum Master.

La lecture de "Scrum et XP depuis les tranchées" se fait en un weekend (je l'ai lu dans le RER paresseusement en 1 semaine, c'est dire...).
Cependant, il contient ce qu'il faut savoir pour comprendre les concepts et rituels pour ne pas être perdu lors d'un démarrage.

Comme je le disais : la lecture est rapide. Ceci est facilitée par le style d'Henrik Kniberg tout en humour et en exemple.

A l'origine, il m'a été recommandé par Thierry Leriche quand je ne connaissais Scrum et Agile que de nom.
C'est via ce livre que j'ai découvert Scrum et j'en profite pour en faire le kick-start de mon blog dédié à Scrum et au monde de l'Agile.

A mon tour de vous recommander cette lecture ! :)