The Next Step

Avez-vous déjà assisté à une réunion où plein de belles décisions sont prises. La réunion a débordée un peu... les participants sont pressés et fatigués... La réunion se termine... Chacun repart de son côté et retourne a ses occupations puis.... puis... puis... plouf:

Rien ne se passe. 

J'ai déjà assisté à quelques de ces reunions... Si toi aussi tu te sens concerné tu peux lire la suite de l'article sinon... heu... tu peux aussi lire le suite de l'article :-)

Une seule solution pour te sauver :

L'idée derrière le next step est de ne pas attendre après avoir décidé quelque chose pour commencer sa mise oeuvre. 

Il faut battre le fer tant qu'il est encore chaud!

Il faut amorcer la pompe!

Il faut mettre la machine en route!

Il faut passer la première!

C'est marrant de voir que plein d'expressions sont "Next Step"!

A minima, il s'agit juste de définir la prochaine étape après une décision : quoi/qui/quand. Il n'est pas nécéssaire que cette prochaine étape soit conséquente. Plus elle est petite moins elle prendra de temps. Une fois de plus l'idée est d'amorcer le travail.

La difficulté du next step est qu'à la fin d'une réunion intense, les participants oublie/n'ont pas forcément envie de penser au next step.

Ok et après je fais quoi?

Si tu as compris, c'est très simple, il faut définir le next step du next step!

Tips :

• Toujours prévoir un peu de temps à la fin d'une réunion pour définir le next step.
• Parfois il s'agit s'implement de poser la question (parfois suivi d'un blanc) : "Ok, super, on commence par quoi?".
• Si le next step peut se faire dans la foulée ou simplement être commencé, c'est encore mieux.
• Parfois, résumer et reformuler le contenu de ce qui vient d'être d'être décidé et des actions liées suffit au next step.

Ce qui est sympa avec le next step, c'est qu'il est simple à mettre en oeuvre. En revanche, il ne faut pas l'oublier!

Après avoir lu cet article, tu es officiellement "Next Step Certified". Ce qui te donne le droit d'utiliser et de former au Next Step! Quel chanceux tu fais!

Agilité par contamination

Lorsqu'on souhaite mettre en oeuvre Scrum la première fois, il est souvent dit de mettre en place la totalité du framework et dans un second temps de l'adapter quand l'ensemble des acteurs possèdent le recul nécessaire (pour justement l'adapter favorablement). Cette mise en place totale a pour but de ne pas tomber dans les fameux "Scrum But", souvent cause de l'échec de la mise en place de Scrum. Les "Scrum But" pour simplifier représentent les entorses au framework (Exemple : c'est le ScrumMaster qui fait les estimations et affectent les tâches, oui ça c'est de la très grosse entorse ;-)).

Je vous propose ici de vous raconter un de mes retours d'expérience sur le sujet qui est très différent de l'approche dont je viens de vous parler.

Il y a bientôt un an, j'ai intégré une équipe de développement chez un éditeur logiciel qui ne pratiquait pas "l'agilité". Ce nouvel environnement me paraissait idéal pour mettre en place Scrum couplé avec un peu d’Extrême Programming pour plusieurs raisons :

• une petite structure (moins de 25 personnes).
• une équipe de développement de moins de 6 personnes.
• une forte croissance.
• la volonté de développer une nouvelle version d'un produit.

Il faut avouer que Scrum est très déroutant dans ces pratiques quand on ne les a jamais mises en oeuvre. Comme je ne m'appelle pas Jeff Sutherland (un des papas de Scrum) et que je ne suis pas un extrémiste (enfin j'estime ne pas l'être, ce qui est différent, je vous l'accorde), je n'ai pas forcé pour la mise en place de Scrum.

En revanche, je travaillais sur un sujet isolé et avec une liberté totale sur ma façon de travailler. J'ai donc fait du Scrum et de l'Xp seul (ok ce n'est pas vraiment du Scrum). Tiens ça me fait penser à Jean Jacques.

Hey hop, c'est parti, je récupère un tableau en carton, j'ai un mur juste derrière moi, impeccable,  ça sera mon scrum board. Un petit tour par la compta : "Heu, vous auriez des post-its? Ha, vous n'avez que cette couleur, ok ça ira très bien pour commencer. Vous pouvez en commander d'autres? et de plusieurs couleurs?".

Un ou deux jours passent...

Réaction 1 : "Ha c'est comme ça que tu travailles?"
Réaction 2 : "C'est jolie tous ces post-its derrière toi, c'est quoi, ça marche comment?"

Côté pratique d'ingénierie, pas d'intégration continue, pas de DVCS (en tous cas pas celui que je voulais :-)), pas de suivi de qualité, pas de déploiement continu. Ok, qu'à cela ne tienne, "Just Do It". C'est parti pour mettre en place une forge logicielle complète sur une machine virtuelle dans un coin de serveur (apache, jenkins, git, sonar, maven, ...).

Réaction 3 : "C'est quoi l'intégration continue?"

J'avais maintenant tous les outils que je souhaitais pour développer. C'est parti. Les semaines passent, les post-its s'entassent...

Réaction 4 : "C'est pas mal ton tableau avec les post-its pour voir l'avancement du travail"

A force de question et de discussion autour de Scrum avec l'équipe de développement, je me propose de leur faire une présentation de Scrum. C'est parti pour une présentation de 2h très conviviale. L'objectif est de faire découvrir les principes du framework. Rien de plus.

Réaction 5 : "C'est vraiment très différents, ça n'est pas du tout aujourd'hui notre façon de travailler, ça fait un peu peur"

Les semaines passent... et qu'est-ce que je vois sur le bureau du collègue à côté de moi, le livre "Scrum" de Claude Aubry. Je lui dis que c'est un super bouquin qu'il a bien fait de l'acheter.

Réaction 6 : "C'est ma compagne qui me l'a acheté car je lui avais parlé de la présentation que tu avais faite"

Alors là je suis scotché!

Les semaines passent... et un gros sujet à traiter par toute l'équipe nous tombe dessus. On ne sait pas par quel bout le prendre. Je propose aux membres de l'équipe qui connait le mieux le sujet de faire un mind map pour modéliser le travail à effectuer ainsi qu'une réunion tous ensemble où l'on ajuste le Mind Map pour tous obtenir une bonne vision de ce qu'on va devoir faire.  J'extrais ensuite le contenu du Mind Map dans un fichier Excel.

Réaction 7 : "C'est un peu comme un Backlog ce fichier Excel, non?"

Je l'ai ensuite renommé en "Backlog".

Réaction 8 : "Par quoi on commence?"

Je propose de refaire une réunion avec toute l'équipe pour qu'on priorise les sujets/tâches tous ensemble pour traiter les tâches les plus urgentes.

Réaction 9 : "On priorise tout, tout de suite?"

Je propose alors de faire un point tous ensemble toutes les semaines et de prioriser/reprioriser les sujets.

Réaction 10 : "On migre les applis existantes sur git"?

Yes!

Réaction 11 : "Comment on fait pour rajouter un Job dans Jenkins"?

Yes! Je te montre!

Les semaines passent... et je discute avec le directeur général. Il m'apprend qu'il s'est documenté sur Scrum et les méthodes Agiles qu'il trouve ça très intéressant et qu'il souhaite qu'on fasse des petites réunions tous les matins.

Aujourd'hui, nous ne pouvons pas dire que nous "faisons du Scrum" mais tous ce qui est mis en place nous aident réellement au quotidien. L'utilisation d'un backlog et la réalisation du Daily Scrum du matin sont maintenant une évidence. J'espère que cette démarche (non préméditée) de contamination va se poursuivre.

Alors que je pensais que Scrum ne pouvait fonctionner sur le principe du tout ou rien, je me rends compte que l'agilité progressive est un succès dans notre cas.

Vous en pensez quoi?

Intégrer un nouveau membre dans une équipe projet

On m'a récemment demandé si j'avais des suggestions ou des idées sur l'intégration d'un nouveau membre dans une équipe projet.

J'ai évidemment directement suggérer de faire du Pair programming. Le pair programming est une des pratiques de eXtreme Programming

Les bénéfices du pair programming ne sont plus à démontrer mais cette pratique est particulièrement intéressante dans le cadre de l'intégration d'un nouvel arrivant dans une équipe :

• L'intégration se fait par l'exemple mais dans des conditions réelles.
• Le nouveau membre a tout de suite une vision de comment faire concrètement.
• Le risque de "laisser" le nouveau travailler seul n'existe plus. (Principe du "je ferme les yeux, ça va passer, ça va passer...")
• Pour le membre de la paire qui fait déjà parti du projet, il va devoir reprendre du recul par rapport à ce qu'il fait pour pouvoir répondre aux questions. Prendre du recul, c'est toujours favorable.
• Le nouveau membre se sentira membre de l'équipe beaucoup plus rapidement.
• Le nouveau membre sera "opérationnel" beaucoup plus rapidement.
• Cela permet de ne pas se retrouver avec le nouveau membre, le jour de son arrivée, assis à un bureau sans rien faire sans login mot de passe et sans poste de travail... (si si, je vous vois sourire, ça arrive tout le temps, il doit d'ailleurs y avoir une "loi" derrière tout ça, c'est à creuser :-)).

Le principal argument qu'on peut entendre en général pour ne pas faire du pair programming : 

"Ça va me couter du temps et donc de l'argent car ça va monopoliser un membre de l'équipe."

La réponse à cela est "c'est pas faux" pour ne pas dire "c'est pas vrai" :-) :

• L'intégration d'un nouveau membre dans une équipe à un coût. Il faut l'accepter. Cela n'a rien à voir avec le fait de faire du pair programming.
• Ce coût est beaucoup moins facile à quantifier quand on laisse le nouveau membre se débrouiller car il est dilué (qualité moyenne des premières réalisations, temps de "parasitage" du nouveau membre envers l'équipe lorsqu'il aura besoin de savoir quelque chose, temps passé à corriger les anomalies découvertes des premières réalisations, ...)
• Le membre de l'équipe qui va travailler en pair programming avec le nouveau n'arrête pas de développer, il va juste développer un peu moins vite (mais à contrario c'est directement quantifiable :-)).
• Faire du pair programming, ne veut pas dire de faire que du pair programming. Il peut être intéressant d'alterner pendant la durée d'intégration les phases de travail en paire et les phases en autonomie. Cela peut permettre au nouveau membre de monter sa plateforme de développement, de "digérer" la phase de travail en paire, de lire des documentations, de trouver une date pour payer son coup...

Pair programming se dit en français programmation en binôme.

Coding Dojo en entreprise

x

x

x

J'organise avec Thomas, Guillaume et Jay (amis, collègues et membres de la direction technique de Norsys) des Coding Dojos en interne. J'ai réalisé avec Guillaume un document descriptif / retour d'expérience sur l'organisation de ce type d'évènement. En voici une adaptation :

Un Coding Dojo, Qu'est-ce que c'est ?

Un Coding Dojo est une réunion où un ensemble de personnes se retrouvent pour travailler sur un défi de programmation de façon collective. Un défi de programmation est un problème à résoudre ou un besoin à implémenter.

Chaque coding DOJO se porte sur un sujet particulier qui est décliné en un exercice à réaliser. Il représente le challenge de programmation du DOJO.

Un Coding Dojo permet de mettre en œuvre différentes techniques de programmation notamment lié à l'extrême proggramming :

• Pair Programming.
• TDD.
• …

On pourrait assimiler un Coding Dojo à un Coding party. Ce n'est pas le cas. L'objectif n'est pas de réussir à résoudre le défi de programmation mais plutôt de d'apprendre de façon collective sur la manière d'y arriver.

Un Coding Dojo, Pourquoi faire?

"Si je veux apprendre le Judo, je vais m'inscrire au dojo du coin et y passer une heure par semaine pendant deux ans, au bout de quoi j'aurai peut-être envie de pratiquer plus assidument. Si je veux apprendre la programmation objet, mon employeur va me trouver une formation de trois jours à Java dans le catalogue 2004. Cherchez l'erreur. "

Laurent Bossavit, président de l'association XP-France (Extreme Programming).

Le constat de départ est que trop de développeurs utilisent uniquement leur travail (et leurs réalisations professionnelles) comme terrain d'entraînement pour parfaire leurs techniques. Le principe d'un Coding  dojo est de proposer un espace sûr pour que les développeurs puissent expérimenter, tester et apprendre en dehors du cadre d'un projet.

Les personnes qui participent à ce type de réunion doivent le faire par envie et pour améliorer leurs compétences en programmation.

Les principales motivations qui doivent pousser les personnes à participer à un Coding Dojo sont :

• l'envie d'apprendre.
• l'envie de partager.
• l'amélioration continue.

Les caractérisitiques d'un Coding Dojo
Le coding DOJO doit être "un lieu sûr " :

• Tous les niveaux de compétences en programmation sont acceptés.
• Seule une personne volontaire peut participer à un Coding Dojo.
• Ce n'est pas une compétition.
• L'erreur est humaine.
• Il n'y a pas de jugement.
• Le Coding Dojo doit être un moment convivial.
• Tout le monde doit participer.

Voici un ensemble de points qui caractérisent un Coding Dojo :

• Chacun doit pouvoir s'améliorer à son rythme.
• Le but n'est pas de terminer l'exercice mais bien d'apprendre.
• Il permet un apprentissage continu/régulier.
• Il permet un apprentissage par petits pas.

Il existe 2 types de Dojos :

• le kata.
• le randori. 

Qu'est-ce qu'un Kata?
PRINCIPE :

Le kata est une des formes de Coding Dojo. C'est une démonstration en live de la réalisation d'un défi de programmation en partant de zéro.

image provenant de Dojo@SP (São Paulo)

Un présentateur (un seul programmeur ou un binôme) présente sa solution du défi. Il explique continuellement son cheminement et il affiche sa progression en déroulant continuellement les tests. Le défi est réalisé en entier en TDD (Test-Driven Development). L'interactivité avec le reste du groupe est primordiale.

Le but n'est pas de trouver la meilleure solution mais de comprendre la solution proposée par le présentateur.

CHARTE :
La pratique du TDD appliquée au Kata pour le présentateur (ou binôme) est la suivante :

• Rédaction d'un test.
• Le test est au rouge (en echec). Si le test ne passe pas, le présentateur doit expliquer aux participants la raison de l'échec. il doit mettre en œuvre le code permettant de réussir le test. 
• Le test est au vert (réussite). Le présentateur peut souligner de bonnes ou de mauvaises pratiques. La salle peut interrompre le présentateur dans le seul cas où il ne comprend plus le déroulement de la solution.…
• Refactoring du code.

Toute restructuration doit être expliquée
et ainsi de suite…

Qu'est ce qu'un Randori
PRINCIPE :

Le randori est l'autre forme de Coding Dojo. L'objectif est d'implémenter une solution de façon collaborative pour un défi. Le principe de base est que tout le monde effectue les rôles de pilote et co-pilote pendant la session.

 image provenant de Dojo@SP (São Paulo)

Le binôme de développement est composé d'un pilote qui a le clavier et d'un co-pilote qui implémentent une solution pour le défi en respectant la démarche TDD (Test-Driven Development). Le binôme est changé toutes les 5 à 7minutes par une rotation :

• le pilote retourne parmi le reste du groupe.
• le co-pilote devient pilote.
• une personne du groupe devient co-pilote. 

CHARTE :

La pratique du TDD appliquée au randori pour chaque binôme (durée 5 à 7 minutes) est la suivante :

• Rédaction d'un test.
• Le test est au rouge (en echec). Le binôme de développement à la main. Si le test ne passe pas, le pilote doit expliquer aux participants la raison de l'échec. Les participants n'interviennent que si le binôme le demande. Le binôme doit mettre en œuvre le code permettant de réussir le test.
• Le test est au vert (réussite). Les participants peuvent intervenir pour proposer des améliorations, faire des remarques, poser des questions…
• Refactoring du code.

Toute restructuration doit être discutéé et avoir l'accord de la majorité des participants.

et ainsi de suite…

Du coté de l'organisation...
QUI PEUT PARTICIPER?
Toutes les personnes qui adhèrent aux principes d'un Coding Dojo.

QUI PEUT ORGANISER?

Toutes les personnes qui adhèrent aux principes d'un Coding Dojo qui ont envie d'organiser ce type d'évènement.

LES CONTRAINTES D'ORGANISATION :

Pour organiser un Coding Dojo, il faut :

• Un lieu.
• Une date.
• Une durée fixe est définie avant le Coding Dojo.
• Un sujet + langage de programmation.
• Un mode de fonctionnement kata ou randori.

LA LOGISITIQUE À PRÉVOIR:

D'un point de vue logistique il faut :

• Que les participants possèdent une adresse mail pour les communications qui précédent et suivent une session.
• Une salle.
• Une table (au moins).
• Des chaises pour l'ensemble des participants
• Un video projecteur.
• Un ordinateur portable.
• Un paper board ou white board.
• Des post-its.
• Des stylos.
• Un appareil photo (optionnel)
• Une Caméra (optionnelle)

Exemple : Un Dojo à Norsys
AVANT :
Il faut :

• Choisir une date.
• Choisir le lieu.
• Choisir le sujet (soit par un vote public, soit par un choix au niveau des organisateurs).
• Réserver les éléments logistiques nécéssaires (video projecteur, salle, …).
• Préparer un système d'inscription en ligne et de choix de sandwich(doodle ou formulaire google docs).
• Envoyer l'annonce du Dojo (date, lieu, contenu, lien vers le système d'inscription.
• Solliciter les personnes qui doivent préparer des choses pour la session pour s'assurer qu'il n'y ai pas de malentendu.

JUSTE AVANT :

• Envoyer un mail de rappel aux inscrits avec le choix de leur sandwich.
• Gérer la commande de sandwich.
• S'assurer que les éléments logistiques réservés sont bien disponibles.

PENDANT :

• 12h00-12h30 :  arrivée progressive des participants. Préparation de dernière minutes. Distribution des sandwichs et récupération de l'argent.
• 12h30-13h30 : Coding Dojo.
• 13h30-14h00 : Discussion autour du Dojo. Rangement . Départ progressif des participants.

APRÈS :

• Mettre à disposition le code de la session.

Difficultés

Un coding Dojo réprésente malgré tout un défi d'organisation :

• Cela prend du temps.
• Il faut résoudre les difficultés logistiques en amont d'une séance.
• Il faut se mettre d'accord sur un sujet et ça n'est pas toujours évident.
• Durant la séance : Ne pas oublier que l'ojectif premier est d'apprendre et non pas de terminer l'excercice. Il faut trouver un bon equilibre entre le développement l'échange.
• 1 heure, c'est très court. Le souhait de de développer le plus possible et de faire participer tout le monde.
• Travail collaboratif. Il faut faire des choix dans un temps restreint et dans le cadre d'une rélfexion commune.

Quelques références :

• http://www.slideshare.net/ehsavoie/agile-tour-2009-coding-dojo-kata-atdd (Merci à Emmanuel de m'avoir m'autoriser à réutiliser ses schémas et photos) 
• http://codingdojo.org/
• http://linuxfr.org/2008/12/19/24813.html
• http://clubagile.org/
• http://groups.google.com/group/nord-agile/

A vous de jouer :-)

Norsys, une réunion d'agence "Agile"

Hier soir a eu lieu la classique réunion d'agence de Norsys Région Nord dans les locaux d'Ennevelin.

La réunion avait l'originalité d'être présentée comme une réunion d'agence "Agile". Ça mérite bien un billet pour en parler.

Pour bien repréciser le sujet, il n'existe pas réellement de réunion "Agile" c'est pour cela que dans le titre du billet Agile est entre guillemet... En revanche, l'originalité de la réunion réside dans la réutilisation de certains concepts et de certaines méthodes Agiles pour organiser son déroulement.

Voici les différents points d'organisations intéressants :

• Ce sont les salariés qui ont choisi parmi un ensemble de thèmes (business, stratégie 2009, les méthodes Agiles, RH, informations sur le groupe Norsys...) ceux qui allaient être débattus pendant la réunion.
• Chaque thème devait être présenté en 10 minutes, pas plus, pas moins.
• L'utilisation du powerpoint pour présenter un thème était quasiment interdit pour favoriser d'autres modes de restitution visuels et originaux.

L'ensemble des salariés a donc été sollicité par mail en amont de la réunion pour choisir des thèmes. Lors de la réunion, pendant un premier "sprint", les thèmes retenus par mail ont été abordés et 2 thèmes ont été retenus en live pour être présenté dans un second sprint. Un pot convivial a été organisé après la réunion.



Les présentateurs ont utilisé des moyens originaux pour rendre fun la restitution des thèmes abordés (rappelons que le coté fun fait évidemment parti des méthodes Agiles) :

• interview.
• proposition de sujets par paper board/post-it.
• réutilisation du principe de "TODO", "IN PROGRESS" et "DONE" sur un tableau pour présenter l'avancement d'un thème.
• réalisation d'un "Dessinez c'est gagné" numérique "videoprojeté" (cf photo) pour trouver les sujets d'un thème.
• Diffusion d'une vidéo pour présenter un thème.
  
• réalisation d'une petite exposition dans une salle annexe pour présenter un thème.

remarques diverses :

• La réunion a rassemblé une grande majorité des salariés hier soir.
• Nos chers commerciaux n'ont pas réussi à respecter les 10 minutes pour présenter la partie business :-).
• La réunion était très vivante et participative.
• La réunion a été Fun!
• L'agence est maintenant en rupture de stock de paper board et de post-it :-).
• Les modes de restitutions des thèmes ont été très originaux.
  

Dans tous les cas, ça changeait de l'ordinaire et il fallait le souligner.

Scrum fait peur

Et plus largement les méthodes Agiles.

C'est le constat que je peux faire dans le contexte dans lequel j'évolue.

Je me suis longtemps dit qu'en effet, se lancer dans un premier projet en Scrum peut faire peur alors que l'on n'a jamais fait cela auparavant. En revanche, lorsque le contexte le permet, que des gens compétents sur le sujet y participent et qu'il n'y a pas réellement de risques à faire "un essai" ( :-) les experts comprendront...) , j'ai plus de mal à comprendre...

Une des grosses évolutions par rapport à des méthodes de gestion de projet dites "traditionnelles" (ou plutôt celles qui ne fonctionne pas ou peu) concerne le métier de chef de projet qui n'existe plus car il est remplacé/transféré par le rôle du ScrumMaster.

En se mettant un peu à la place d'un chef de projet, il est plus facile de comprendre (mais pas forcément d'accepter) leurs points de vue. Imaginons qu'on vienne vous dire que votre façon de travailler depuis des années soit totalement remise en questions, que des retours d'expériences vous démontre que c'est presque une évidence et que vous n'y avez pas pensé. Cela ne doit pas être évident à encaisser...

Messieurs les chefs de projets, je vous le dit :
Scrum ça n'est pas l'avenir, c'est tout de suite! Allez-y!

Juste pour le fun, une petite tendance à la google :


en bleu : rational unified process
en rouge : Scrum agile

Comme le précisez Claude Aubry sur son blog dans ce billet en 2007, il faut faire attention à ne pas créer un Buzz autour de Scrum et le transformer en une méthode un peu originale et à la mode. Scrum c'est avant tout un ensemble de pratiques simples et pragmatiques à mettre en œuvre pour réussir un projet.

Une métaphore de Scrum

Le Touilleur Express vient de publier une métaphore permettant d'expliquer les grands concepts autour de Scrum.

Pour Simplifier, Scrum : c'est une machine à laver. J'adore.

Je vous laisse aller lire le billet du Touilleur Express sur le sujet pour avoir plus d'infos.

Retour sur... l'Agile Tour 2008 à Lille

L'Agile Tour 2008 à fait escale mardi dernier à Lille.

Pour résumé :
- les locaux de l'école d'ingénieurs Telecom Lille1 était impeccable pour l'évènement.
- l'organisation était sans faille.
- les sessions (soit orientées "présentation" soit orientées "atelier") étaient de grande qualité.

J'ai été surpris de voir que le public semblait majoritairement connaître les grands principes autour des méthodes Agiles. Ce n'est peut-être qu'une impression liée au public des sessions auxquelles j'ai assisté...

Le seul reproche que je puisse faire : c'était trop court! En même temps, ce n'est que la première édition. Il ne faut pas être trop gourmand...

En tous cas pour une première, c'était vraiment bien!

Vivement l'année prochaine! Enfin je l'espère.

Agile Tour 2008

Un grand rendez-vous à ne pas manquer!!!

L'Agile Tour "Le rendez-vous francophone de l'agilité" (http://www.agiletour.com/) passe par Lille le 14 Octobre Après-midi.

Pour ceux que ça intéresse (débutant, amateur ou professionnel), il est possible de s'inscrire sur le site.

Voici le wiki de la session de Lille : http://wiki.agiletour.com/At2008Lille