Manager une équipe de développement Web

Le piège du Concorde

Si vous avez un espace temps de lecture, que vous avez envie de combler en dehors des sentiers battus, je vous conseille de lire le fabuleux ouvrage de Laszlo Mero "Les aléas de la raison : de la théorie des jeux à la psychologie".

Citons Laszlo quand il nous décrit si bien le "piège du Concorde".

Le coût du Concorde, avion supersonique développé conjointement par les Français et les Britaniques, crût tout au long de l'avancement du projet. Il devint vite évident qu'il n'avait aucune chance d'être rentable, alors que seule une faible part de l'investissement initialement prévu avait été engagée. Néanmoins, les deux gouvernements s'enferrèrent de plus en plus et, en fin de compte, dépensèrent pour leur projet une somme plusieurs fois supérieure à celle prévue au départ. Tant que le dernier boulon n'était pas serré, il aurait été moins onéreux de stopper toute l'entreprise, le Concorde n'étant appelé qu'à provoquer de nouvelles pertes. Mais il était devenu un investissement de prestige. Et fut longtemps considéré comme tel par les deux gouvernements, dont il faisait la fierté.

Le Piège du Concorde, ou l'anti pattern de l'impossibilité d'abandonner quand on a tant investi, qui amène tous les joueurs du monde, enfermés dans leur martingale, à la faillite et au désespoir.

La réalité psychologique de ce phénomène est d'ailleurs tout aussi opérationnelle dans bien des projets de développements informatiques. On dépense sans fin, malgré les retards, pour suivre à la lettre des jalons hypothétiques gravés une fois pour toute dans le marbre des plannings.

Avec scrum, tout cela part à la poubelle!

Chaque matin, lors des scrums quotidiens, on se repose tous ensembles les mêmes questions : doit-on poursuivre sur ce chemin, ou prendre celui d'à côté, ou revenir en arrière, rebrousser chemin un temps pour mieux repartir sur une pente plus douce, ou même s'arrêter...

Avec un bon Product Owner, le piège du Concorde ne se serait pas refermé. Un autre avion aurait pu voir le jour, plus rentable, plus efficace...

Au sein de l'un de nos projets, nous venons de rencontrer un problème qui aurait pu prendre l'allure du piège du Concorde. Nous étions sur une voie en tout point interessante, alléchante, nous en rêvions tous...au début, nous étions confiants, mais au bout de trois, quatre scrums, je sentais que l'équipe se bloquait sur ce point précis, elle n'avançait plus ... si bien que cette tâche technique devait continuer sur le sprint suivant. Lors du sprint planning, j'avais remis en estimation cette "tech user story", les cartes de planning poker étaient dstribuées, il n'y avait plus qu'à ... l'un des membres de l'équipe m'arrête et me dit "non, pour cette story, nous devons faire autrement, nous ne devons pas l'estimer, car nous savons maintenant, après trois jours de travail intensif, qu'un risque important d'échec subsiste. C'est à toi de nous dire combien tu es prêt à payer, en terme de temps de l'équipe, sur cette tâche." Oui, cela était tout à fait juste. J'ai donné deux jours, ou plutôt dix heures effectives. On s'est dit : "on essaye encore pendant dix heures, si on y arrive, tant mieux, sinon, on passe à autre chose, on prend le problème différemment." Ce que nous avons fait. L'équipe n'a pas pu résoudre le problème tel que nous le souhaitions, car cela n'était pas possible techniquement, mais nous avons volontairement limité les frais. Et notre agilité nous a permis de trouver deux solutions de rechange, parmi lesquelles nous avons ensuite tranché.

Non, dans un vrai projet scrum, c'est-à-dire un projet qui passe le Nokia Test, vous ne serez jamais confrontés au Piège du Concorde. Ailleurs, si!

Partie de planning poker géante

L'été, sur les plages, au soir, quand le soleil a bien chauffé les corps, les coeurs et les sables, j'aime les sardinades géantes...à défaut, chez nous, dans la moiteur des locaux non climatisés, nous avons l'idée de monter une partie de planning poker géante. Ce sera après l'été, quand les corps, les coeurs et les sables auront un peu laissé de leur chaleur. Christophe et moi, Product Owner pour l'un et Scrum Master pour l'autre, avons eu l'idée de réunir fin août, début septembre, l'ensemble des collaborateurs qui de près ou de loin travaillent sur les différents chantiers de nos sites web.

Le but? Estimer avec agilité les différents pojets qui sont tombés dans notre besace, et les planifier dans les différentes releases des douze mois à venir. Oh! l'exercice n'est pas neuf. Nous sommes habitués, années après années, à s'échanger par voie d'email (niveau 0 de la communication sur l'échelle de Jeff Sutherland, rappelons-le), de volumineux fichiers excel, onglets nombreux, colonnes infinies et lignes multicolores. Des dates, des ressources aléatoires, de l'ambition, peu de budget, et surtout, pas de partage.

Cette année, après plus de huit mois d'agilité, nous allons donc nous réserver une jolie time-box de 3 heures et réunir chefs de projets, développeurs, designers, gestionnaires de contenu, etc...pour un super planning poker. Objectif : estimation relative de notre backlog annuel. Puis décomposition en tâche d'un ou deux projets, parmi les plus prédictibles, et nous pourrons, à cette aune, planifier le possible sur l'année à venir.

A suivre, donc, dans un prochain billet. Voilà que je fais du teasing, maintenant.

J'ai hâte, comme dirait Omar, d'Omar et Fred (private joke!)... 

Un américain à Paris

Je sors juste de ma formation Scrum Master chez Xebia, animée par Jeff Sutherland. Je reviendrai dans d’autres posts sur ces deux jours, mais je souhaite vous en donner à chaud, juste quelques éléments. Ce qui m’a le plus marqué.

Pour commencer, juste un mot sur la qualité d’animateur de Jeff. Il nous donne cinq minutes, pas une seconde de plus (time boxing oblige) pour expliquer à notre voisin qui nous sommes, ce que nous sommes venu faire à cette formation, etc… puis, échange de rôle, écouter ce que notre voisin nous dit sur lui-même. Les cinq minutes passent. Jeff nous arrête, et nous demande, tour à tour de présenter son voisin. Comme il y a des gens de toute nationalité (allemand, danois, polonais, français, sans compter Jeff), nous nous exprimons tous en anglais, ce qui permet, dès les dix premières minutes de formation, d’avoir brisé toute contrainte linguistique entre nous.

Autre fait marquant (mes pensées s’enchaînent sans ordre…), la grande maturité de l’ensemble des participants. Nous étions tous persuadés de l’inefficacité des méthodes traditionnelles, des projets en mode waterfall et du couple infernal commande-contrôle. D’ailleurs, concernant l’impossibilité du management de projet par commance-contrôle, Jeff nous a proposé un petit jeu assez édifiant. Par deux, l’un joue le chef, l’autre l’ouvrier. Le chef commande : avance, stop, gauche, droite, tout droit. L’objectif était de traverser la salle de cours dans un sens puis dans l’autre. Imaginez trente bonhommes (oui, nous étions entre hommes, cette session ne comportait aucune femme, hormis l’épouse de Jeff, qui nous a accompagné le premier jour), imaginez donc trente bonhommes en tous sens, des droites, gauches, stop, sans trop savoir à qui ils s’adressent…le test de ce pur commande-contrôle ne fut guère concluant, aucune équipe n’a tellement avancé. Alors, on a supprimé les chefs. Au lieu de 15 chefs et 15 ouvriers, nous étions 30 ouvriers, et là, ce fut le bonheur, quelle fluidité dans notre marche, chacun allait son rythme, le plus naturellement possible. Bel exemple, en tout cas, à méditer…

Bien entendu, il n’y avait pas que des exercices de ce genre, il y avait aussi quelques slides, avec force chiffres, destinés à convaincre tous les DSI de la terre. Certains cas étudiés méritent de s’y arrêter, car ce sont des gains de plus de 400% de productivité qui sont en jeu !

Une autre chose très intéressante : je me suis amusé à compter le nombre de personnes avec qui j’avais parlé pendant ces deux jours. Pour tout dire, je suis d’un naturel plutôt taiseux. J’ai compté : avec au moins 16 personnes. Dans ce genre de formation, sur deux jours, avec déjeuner et pause inclues, en général, c’est bien un malheur si je dépasse, disons, huit personnes ! Le double, donc. Jeff, le premier jour, nous avait demandé, ce citer les trois principaux facteurs clé de succès d’un projet, et les trois principales causes d’échec. Nous avions cité la communication d’un côté, et le manque de communication de l’autre. Scrum vous oblige à communiquer. Et à vraiment communiquer. D’ailleurs, l’un des slides rappelait que l’email était un moyen de communication tout à fait nul, que le téléphone, c’était déjà mieux, mais le top du top était la communication face à face, avec paper board pour noter les idées, les points de divergence, etc … depuis que je pratique scrum, je n’envoie en effet presque plus jamais d’email, si ce n’est pour rappeler l’heure et le contenu de la prochaine démo de sprint, après avoir convenu, en communication directe, de la date et heure du rendez-vous avec les principaux intéressés.

Autre exercice : après avoir dresser la liste des trois obstacles les plus importants à la mise en place de scrum, Jeff nous a donné 59 minutes pour les traiter. Nous étions par équipe de 6, dont un product owner et un scrum master désigné de manière tout à fait démocratique. Je me suis abstenu du rôle de scrum master, afin de vivre par moi-même ce que cela fait d’être team member. Première impression, c’est tout à fait reposant ! Je devrais tenter de nouveau cette expérience dans la vraie vie, me laisser porter par mon scrum master. Bon !

D’autres expériences de la même veine : la création d’un backlog à partir de quelques fonctionnalités et prérequis techniques, time boxés, en utilisant ce fameux planning poker dont je sais depuis 6 mois que c’est un outil génial, avec échange culturel, car nous étions deux .Net au milieu de la bande des furieux javaïstes de Xebia. Et enfin, pour la deuxième partie de l’après-midi : la mise en pratique d’un enchaînement de sprints, avec priorisation et repriorisation au sein du backlog, en fonction des degré de complexité et des business values. Il s’agissait entre autre de gonfler des ballons, faire rouler des dés, construire des châteaux de cartes ou encore, de plier des chapeaux en papier.

Et pour clore la journée, la partie de question-réponse la plus originale que je connaisse. Jeff nous avait demandé hier soir d’écrire sur des post-it nos questions. Elles étaient accrochées au mur. Il a commencé à répondre aux trois premières, puis il a distribué les post-it restant à chaque table, et nous devions y répondre selon son tour. Très bel échange !

Ne me parlez pas de ressources

Une fois n'est pas coutume, j'avais pris le 01 Informatique de la semaine pour lire pendant mon voyage de retour. Je suis tombé sur cette petite citation d'un responsable informatique "On trouve toujours une solution aux soucis techniques. Le succès ou l'échec d'un projet dépend des hommes.".

Cette citation me fournit l'occasion de reparler un peu du premier principe du Manifeste Agile, le plus important d'ailleurs à mes yeux : "Les individus et les interactions doivent primer sur les processus et les outils", qui dit donc bien la même chose que ce responsable informatique.

Il y a peu, j'ai été très énervé lorsque l'on m'a demandé "si j'avais des ressources qu'il était nécessaire de former". Des ressources? Quelles ressources?

Avant, on parlait de "Service du personnel". Ce terme au passif un peu difficile, on l'a renommé en "Service des ressources humaines". Cela faisait "plus humain". Le problème, aujourd'hui, c'est que l'on a enlevé le mot "humain". On ne parle plus que de "ressources". Combien te faut-il de ressources pour l'année prochaine? Cette ressource est-elle valable? On peut mettre cinq ressources dans ce bureau, huit dans celui-là. Je ne suis plus manager, je deviens gestionnaire de ressources.

Donc, n'oublions jamais que "Les individus et les interactions doivent primer sur les processus et les outils". Je vais d'ailleurs de ce pas le rajouter en entête de mon blog.

Un agile été

21 juin! C'est l'été, la fête de la musique, les plages ensoleillées, les corps qui se détendent, les esprits qui se délassent.... C'est l'été, et son cortège de casse-têtes pour tout manager de projet, avec cette période de vacances qui va s'éterniser. Comment planifier quelque chose dans ces conditions là?

C'est certain, avec un planning traditionnel, l'été est propice aux suicides des chefs de projets! Un planning établi à l'automne, avec un découpage en tâches très précis ne peut qu'exploser avec les acances. Bien sûr, le chef de projet aura pris soin d'anticiper tout cela en demandant aux membres de son équipe de remplir en décembre un volumineux fichier Excel des congés, de décembre à septembre. Mais, outre le fait que l'équipe l'aura pris pour quelqu'un de très rasoir et de bien psycho-rigide, ce volumineux fichier ne sert pas à grand chose, car, nous le savons tous, les vacances se décident de plus en plus tard...appartenant au domaine des vacances et du loisirs, je suis bien placé pour en savoir quelque chose, et le succès de lastminute.com nous démontre bien qu'au delà d'un horizon de 15 jours, il est tout à fait illusoire de croire que l'on puisse connaître les absences de ses collaborateurs. Tiens, d'ailleurs, je ne sais pas moi-même encore quand je prendrais mes vacances...

Comment ça se passe, avec scrum? Avec scrum, nous avons une planification en pelures d'oignon :

• premier niveau de planification : la journée. Pendant le scrum, chaque membre de l'équipe planifie sa journée, de manière consensuelle avec le reste de l'équipe. En général, sauf accident ou indigestion, il n'y a pas de risque d'absence innattendue : les personnes présentes au scrum du matin savent parfaitement si elles sont présentes tout ou partie de la journée.
• second niveau de planification : le sprint. Nous avons choisi une durée de sprint de 15 jours, ce qui correpond, dans mon esprit, à la période de prévision minimale crédible des congés et RTT. Donc, lors de la phase d'élaboration du sprint, nous savons tous quelle sera la capacité de l'équipe sur le sprint à venir. Donc, l'engagement de l'équipe sur le contenu du sprint est cohérent avec les absences éventuelles de ses membres.
• troisième niveau de planification : la release. La release correspond au contenu d'un ensemble de user stories que le Product Owner souhaiterait voir mis en oeuvre. Techniquement, il s'agit donc d'un plan de développement qui recouvre un certain nombre de sprint. Ce plan de développement est établi par le Scrum Master, à partir des demandes du Product Owner. Le Scrum Master doit donc répartir ces demandes dans le temps, en tenant compte de la vélocité de l'équipe. Et les congés, alors, me direz-vous? Pour moi, la vélocité tient compte des congés. En effet, dans une équipe qui tourne depuis un certain temps, il y aura déjà eu des collaborateurs absents, en congés, en RTT, etc... la vélocité intègre donc une certaine part de congés, et, puisque le plan de développement est une vision à moyen terme de planification, globalement, les absences seront lissées sur la durée du plan. Bien entendu, un plan de développement est, par nature, amené à se préciser sprint après sprint, en fonction des problèmes techniques rencontrés, d'éventuelles nouvelles priorités à intégrer ou des user stories à retirer, des solutions techniques permettant d'aller plus vite...et des congés. Mais ces ajustements resteront assez marginaux, et à un ou deux sprints près, la release devrait se dérouler sans difficulté particulière.

Vive l'été!

Attention à la griserie des challenges!

Rétrospective de sprint avec l'équipe du haut. Pour ceux qui suivent, cette équipe, montée le 5 mai est composée d'Omar, l'Expert, de Zahira, la Testeuse, et d'Anthony, Monsieur Web. Le sprint s'était terminé vendredi soir, avec une démo qui s'état, vu de l'extérieur, plutôt bien passée. Les user stories sur lesquelles l'équipe s'était engagée avait été effectuées. Et surtout, ce sprint comportait un gros challenge, un défi technique comme on les aime. Sans entrer dans des détails inutiles, il s'agissait d'un Web Service assez pointu, sur la réalisation duquel nous avions pas mal d'interroation de faisabilité. Le challenge en valait la peine : on réussit et on fait avancer d'un pas de géant cette partie de SI sur laquelle nous nous affairons, on rate, ben...tant pis, on reste comme on est. Omar a tout donné. Un grand coup de chapeau à lui! Challenge réussit.

Mais...

Il y avait un "mais", mais je ne l'avais pas vu. Nous nous en sommes aperçu ce matin, lors de la rétrospective, lorsque Zahira annonce "ce qui s'est mal passé dans ce sprint, et qu'il faut abolument corriger, c'est le manque de communication au sein de l'équipe!". J'étais un peu étonné. A première vue, j'avais bien fait mon boulot de Scrum Master. Les scrums quotidiens s'étaient tous déroulés comme il fallait, avec de bons échanges, une bonne ambiance. Puis, après quelques explications entre nous, je comprends soudain, comme une évidence!

Le challenge "individuel" dans une équipe Scrum! Difficile, voire impossible à gérer, car antinomique, en quelque sorte. Dans un autre monde, j'avais l'habitude de manager par défis. Un principe d'ordre de mission assez efficace, qui motivait individuellement mes collaborateurs à se surpasser, pour atteindre la mission que j'avais concocté pour eux. Mais c'était avant, dans ma vie avant scrum...

Ce qui s'est donc passé, et qui nous a un peu échappé à tous, c'est que le défi était devenu individuel. Forcément, un impact négatif s'en est ressenti au sein de l'équipe. 

Mais la beauté de Scrum, c'est que ce genre de problème est détecté tout de suite, dès la première rétrospective, ce qui nous permettra de corriger le tir dès la prochaine fois.

Merci Zahira!

Démo en chemises roses

C'était la première démo de l'équipe du haut, la nouvelle équipe. Le matin, quand je monte les voir pour mettre au point ensemble les différents scénarios de la démo, Omar et moi, nous nous sourîmes, car, sans concertation réalable, nous avions l'un et l'autre enfiler une chemise rose. Sauf qu'Omar, en plus, l'avait ornée d'une jolie cravate, mais, ça, c'est une autre histoire.

Pour cette démo, j'avais invité beaucoup de monde, et certaines personnes en avaient elles-mêmes invitées d'autres, ce qui faisait que nous avions un bel auditoire.

Au début, lors des premières démos faites avec l'équipe du bas, j'étais l'unique animateur. Je conservais jalousement la souris, la parole et le projecteur. Comme un ersatz de projet à l'ancienne, dont j'avais un peu de mal à me défaire. Moi, Frédéric Doillon, THE Chef de Projet, je parle, j'expose, je montre...

Petit à petit, j'ai laissé la parole à l'équipe. Et maintenant, cela nous vient à tous naturellement, les démos, c'est le travail de l'équipe. Il ne nous viendrait même plus à l'idée, d'ailleurs, qu'il n'en soit pas ainsi.

Oh, bien sûr, cela ne m'empêche nuellement de prendre la parole, mais pas de la même manière. Comme un Scrum Mater, finalement. J'anime, je fais des transitions. J'insiste sur un point de méthodologie, ou un problème rencontré et réglé. Mais le coeur de la démo, la chair du travail exposée, le rôle en est dévolu sur l'équipe, et sur elle seule. Car ce travail lui appartient. C'est elle qui l'a effectué, de manière collective.

Mine de rien, ce jour là, nos chemises roses ont fait de l'effet. Je crois que c'était la plus belle démo que nous ayions organisé. Notre auditoire était conquis. Maintenant, cela veut dire aussi qu'il faudra donc être encore meilleurs la prochaine fois!

Mon métier sans parler chinois

Une amie, à la lecture de mon blog, m'a rétorqué : "j'y comprends rien".

Comme quoi une petite prise de recul fait toujours du bien, je vais tenter, sans parler "chinois", d'expliquer mon métier aux visiteurs se promenant ici par hasard.

Je suis donc Chef de Projet Technologie Web, Scrum Master, voire Product Owner, bon, ça commence mal! Je barre tout ça, et je recommence.

Je suis animateur d'équipes. J'ai mis en place un cycle de travail de deux semaines.

Le premier lundi

Le premier lundi, notre commanditaire nous expose les différentes nouveautés qu'il souhaiterait voir aparaître sur nos sites Internet, selon un ordre de priorité. Il peut s'agir d'un nouveau service proposé à nos internautes, d'une nouvelle rubrique, d'une correction d'un dysfonctionnement ou l'amélioration d'une rubrique existante, mais qui ne fonctionne pas très bien.

Avec l'ensemble de l'équipe, nous évaluons la charge de travail nécessaire à la mise en place de chaque nouveauté, de manière relative. C'est-à-dire que ce qui est important, ce n'est pas de savoir qu'il faille 2 jours pour modifier un menu du site et 4 jours pour reprendre le design de la home page, mais c'est de se dire il faut deux fois plus de temps pour reprendre le design de la home que pour modifier un menu.

Ensuite, je demande à l'équipe de s'engager, collectivement, sur un ensemble de nouveautés à mettre en place pendant la quinzaine. Ce n'est pas moi qui impose "vous me ferez ça et ça et ça, et si c'est pas fait, vous êtes tous virés!". Non, c'est collectivement que l'équipe choisit de faire "ça et ça et ça" et s'engage sur cet ensemble de nouveauté à mettre en place. La seule contrainte, c'est de suivre les priorités du commanditaire.

Une fois que nous avons un ensemble de nouveautés à traiter, nous les décomposons en petite tâche, dont il est aisé d'évaluer les nombre d'heures nécessaire à leur réalisation. Celà nous donne donc le plan de développement sur lequel l'équipe va travailler pendant la quinzaine. Mais pour l'instant, personne n'a dit qui va faire quoi. En effet, dans une méthode traditionnelle, je dirais "toi, tu fais ci. Machine, tu fais ça. Truc, tu t'occupe de ceci et celà." Non, je ne dis pas ça. J'anime l'équipe, mais je ne commande rien. C'est l'équipe elle-même qui s'auto-organise. Comment ça marche? Nous écrivons l'ensemble des tâches sur des post-it colorés, avec le temps estimé pour leur réalisation, et nous les collons au mur!

Tout les matins

Je réunis toute l'équipe autour de moi et nous faisons face au tâches collées sur le mur. Et à chacun, tour à tour, je pose ces trois questions immuables : "Qu'as-tu fait hier? Que feras-tu aujourd'hui? As-tu rencontré un problème?". Et chacun répond, non pas à moi spécialement, mais à toute l'équipe. Ainsi, chacun sait ce que chacun a fait et fera. Et comme les tâches sont accrochées au mur, il m'est facile, pendant que chacun s'exprime, de modifier les temps des tâches. Je barre les tâches qui sont terminées. Je modifie les temps restant selon les indications de chacun. Parfois, quelqu'un s'aperçoit qu'une tâche avait été oubliée. dans ce cas, on l'écrit sur un nouveau post-it, et on la colle sur le mur.

Comme ceci se passe tous les jours, on sait tous l'avancement global des choses à faire, ce que chacun fait et compte faire.

Le dernier vendredi

C'est le jour de la démo. Je convie notre commanditaire, voire d'autres managers ou collègues interessés, et les différents membres de l'équipe exposent le travail effectué lors de cette quinzaine. Des échanges ont lieu, des demandes de modification peuvent avoir lieu...

Puis, je réunis l'équipe une dernière fois, pour faire une rétrospective de la quinzaine. En posant à chacun trois questions : "as ton avis, qu'est-ce qui s'est bien passé? qu'est-ce que nous pourrions améliorer? qu'est-ce qui n'a pas fonctionné et que nous devons changer?". Chacun s'exprime, moi compris, et de cet échange, nous batissons un avenir meilleurs.

Et ainsi de suite...

La révélation TDD

J'évoque beaucoup sur ce blog notre (r)évolution vers l'agilité en générale, et scrum en particulier. Mais si nous commençons à avoir une bonne assise dans la méthodologie de gestion de projet, nous sommes encore un peu "light" du moins de vue technologie agile. Afin de mettre en place une usine de développement solide, j'ai conçu une avancée en quatre ou cinq phases :

1 - une amélioration de notre gestion de code source, puisque jusqu'à maintenant, nous ne fonctionnions qu'avec une seule branche, (Team Foundation Server)
2 - la mise en place de l'automatisation des tests unitaires, (j'avais pensé à NUnit)
3 - la mise en place des builds automatiques et d'un environnement d'intégration, (MSBuild)
4 - la mise en place de tests fonctionnels automatisés, (j'en ai déjà parlé, j'ai pensé à Fitnesse)
5 - et pourquoi, pas, cerise sur le gateau, les tests de scénarios web, étant donné que nos développements sont essentiellement tournés vers le web (a priori, Selenium tiendrait la corde

Sur les étapes 1 à 3, j'ai missionné Winwise pour nous proposer une mise en place progressive en plusieurs rendez-vous.

Jeudi dernier, c'était la phase des tests unitaires. Notre consultant était Vincent Labatut, de Winwise, donc. D'emblée, il écarte NUnit, dépassé aujourd'hui par MBUnit. Après un petit cours d'une heure sur la philosophie Test Driven Development, ce fut l'installation des outils : MBunit et TestDriven.net. Et le reste de la journée fut consacré à une double prise en main : à la fois des outils, des classes de tests, mais surtout de la méthodologie TDD. Une révélation! Que d'implications en perspective, que de problèmes rencontrés dans le passé nous pourrons maintenant solutionner de manière naturelle.

Cette journée fut pleine d'enseignements. Et la très grande pédagogie avec laquelle Vincent nous faisait petit à petit comprendre l'ensemble de ces concepts nous a permis de complètement modifier notre vision du développement.

Si j'ai un conseil à vous donner : mettez-vous aux Test Driven Developpements, et demander à Winwise de vous confier aux bons soins de Monsieur Labatut pendant un jour ou deux. Vous verrez le monde d'une autre manière!

Rétrospective en terrasse

C'était aujourd'hui la première rétrospective de sprint de ma seconde équipe,(vous savez, mon équipe de tueurs). Il faisait beau. C'était vendredi. La fin du sprint (forcément!). D'un premier sprint ambitieux, avec des contenus à risques potentiels, pour de nouveaux collaborateurs qui montaient en marche dans le train de nos "vieilles" applications. D'un sprint plutôt bien réussi, pleinement agile, sans cahier des charges. Et même une user story qui reste sur le carreau, après une phase d'analyse qui s'avère amener peu de plus value, remplacer par l'ajout d'un peu plus de contenu à une autre. Toujours aller vers l'efficacité. Ne pas se perdre dans les méandres des bois du cerf, mais bien suivre la corne de la licorne. 

Il faisait beau, disais-je...Je proposai donc de mener cette rétrospective de sprint en terrasse, plutôt qu'au sein de la War Room un peu surchauffée de ces derniers temps par nos neurones en ébullition. Et nous voilà donc tous partis, vers les 15 heures, moi, avec mon bloc note sous le bras et le team, les mains dans les poches. Nous nous sommes installés confortablement, à la première terrasse avenante, rapprochant les tables et les chaises. La commande prise, j'animai la rétrospective, ponctuée de quelques petits commentaires sur scrum en général et notre projet en particulier.

L'un des "What Went Well" évoqués fut l'usage de la méthodologie scrum, justement. Et sa pratique au quotidien. La découverte de l'intérieur d'une équipe scrum. Un autre WWW était aussi relié à scrum : il s'agissait de l'impression de confiance donnée à chacun. Ce qui me permettait de faire quelques comparaisons entre un projet traditionnel, avec son chef de projet qui place son équipe sous contrôle, un peu à la manière des usines d'autrefois où le contremaître surveillait les ouvriers à la baguette. Et un projet scrum, dans lequel le chef de projet s'est effacé pour laisser place au scrum master, qui ne contrôle pas, mais permet à l'équipe de s'auto-organiser, qui ne dirige pas mais anime, fluidifie les échanges entre collaborateurs, tente d'aplanir les obstacles et difficultés qu'ils peuvent rencontrés, bref, cherche à amener chacun naturellement vers le maximum de ses capacités. En effet, quand un chef de projet affecte les tâches aux membes de son équipe, il le fait en se basant sur ce qu'il croit que chacun est capable de faire. Et si un collaborateur peut faire plus? Comment le saura-t-il, puisqu'il ne lui aura rien confié qui dépasse les compétences supposées?

Pour ma part, j'avais un petit "What We Can Do Better" sur mon organisation personnelle : scrum master sur la première équipe, scrum master et product owner sur la seconde, ce n'est pas si facile tous les jours, surtout au ddébut, et cela demande, outre une bonne dose d'énergie, quelques règles de fonctionnement individuel que je me mets moi-même en place au fur et à mesure.

Sources Scrum

On me demande souvent mes sources Scrum, s'il n'y a qu'un livre à lire, lequel? par où commencer? Scrum pour les nuls, ça existe? c'est quoi, un bon scrum master? etc ... j'avais écrit une page à cet effet, mais j'ai l'impression que rares sont mes lecteurs qui s'aventurent sur la rubrique Articles. Alors voilà, je redonne toutes mes sources.

Bien sûr, le manifeste Agile, c'est la première étape. Le lire, le comprendre, l'imprimer sur du papier A3, l'afficher au mur, en discuter avec son équipe, avec d'autres collègues, avec ses managers les plus proches, puis un jour, se décider, quand on a atteint la maturité nécessaire, le signer. La signature du manifeste Agile est un sacré engagement, et cela vous change votre vie professionnelle de développeur. Plus rien n'est comme avant. La vision devient différente.

Puis le livre Agile Project Management with Scrum, de Ken Schwaber. Le lire. Le comprendre. Ce sont les bases de la méthode, d'un côté, mais aussi, de nombreuses histoires de projets de développement, sur les quels Ken est intervenu. A la fin de la lecture, on sait ce que c'est que la méthode Scrum. On sait aussi comment l'implémenter. On croit savoir. Mais cela ne suffit pas. C'est là tout le truc de Scrum. C'est très facile. Les concepts sont très simples. Les trois rôles : le responsable produit ou Product Owner, le Scrum Master, et l'équipe. La notion de Sprint : période de temps limité (15 jours, un mois, par exemple, mais pas plus) pendant laquelle l'équipe met tout en oeuvre pour développer les user stories sur lesquelles elle s'est engagée de manière collective. Les différentes réunions qui rythment les projets Scrum : les Scrums ou points quotidiens où chaque membre de l'équipe expose aux autres ce qu'il a fait la veille, ce qu'il fera aujourd'hui, et les éventuels obstacles qu'il a rencontré, charge au Scrum master de les régler. Les Sprint Reviews, lors desquels l'équipe exposent aux commanditaires, et toutes autres personnes de l'entreprise, d'ailleurs, les développements terminés lors du Sprint. Les Sprint Planning, pendant lesquels le responsable produit expose à l'équipe les user stories priorisées en attente. L'équipe estime et s'engage sur un certain nombre de user stories. Mais la vrai compréhension intervient petit à petit, dans la pratique de tous les jours.

Ensuite, c'est le livre Agile Estimating and Planning, de Mike Cohn. Le lire. Je conseille d'ailleurs de lire en même temps le livre de Ken et celui de Mike. Cet ouvrage de Mike Cohn se lit comme un roman. On apprend comment écrire une user story. Comment estimer de manière retlative une user story en user story point avec un planning poker. On comprend les différentes "peaux d'oignon" de la planification : la planification sur l'horizon de la journée lors du scrum quotidien, la planification sur l'horizon du sprint, puis les releases, puis la roadmap produit, et enfin la planification à horizon stratégique.

Une fois tout ceci dans la tête, il est indispensable de s'abonner au groupe de discussions du développement Scrum sur Yahoo, une mine d'or. Mike et Ken y participent régulièrement. Certain fil de discussion sont passionnant. AU début, l'oeil du débutant y fait un tri naturel. On ne comprend pas tout. Puis, petit à petit, à force d'avancée dans les projets, on s'aperçoit que d'autres, à travaers le monde, rencontrent les mêmes interrogation que soi-même, posent des questions que l'on se pose aussi, ou exposent comment eux, dans leur cas, ont résolu un problème de cette manière-là. Une source d'inspiration inépuisable.

Puis installer un framework de gestion de projet Scrum. Comme nous sommes en .net et que nous utilisons Team Foudation Server, j'avais deux options possibles : eScrum et Scrum for Team System de Cochango. J'ai choisi ce dernier, qui s'installe en 1 clic! Il faut en lire le Process Guidance, une ressource excellente de Scrum, avec quelques vidéos de Ken Schwaber.

Sans oublier THE French Blog about Scrum tenu par Claude Aubry, consultant de son état (le Jeff Sutherland français?), qui a mis à disposition une remarquable documentation de la méthode au format EPF.

Après la lecture de toutes ces ressources, il faut plonger. Evangéliser son équipe. Evangéliser son boss. Evangéliser le boss de son boss. Evangéliser le boss du boss de son boss, par l'intermédiaire de son boss... Evangéliser ses partenaires transverses à l'intérieur de la structure. Expliquer, avec agilité. En effet, il faut savoir être agile dans son discours, quand on prône l'agilité!

Lire. Evangéliser. Puis pratiquer. C'est là où l'on s'aperçoit que l'on est loin d'avoir tout compris. Chaque jour se poser la question du pourquoi de ses erreurs. S'améliorer. Feedback permanent avec l'équipe.

Le Skinning DotNetNuke et les alexandrins

C'est venu lors de notre rétrospective de sprint, cet après-midi. Un sprint dont 100% des user stories concernaient le développement et le skinning DotNetNuke. Nous en étions tous contents car le partage de connaissance avait porté ses fruits, et au bout d'un sprint et demi, toute l'équipe était devenue opérationnelle en Dot Net Nuke. Je leur ai même dit que j'avais été assez surpris de cette rapidité, me rappelant du temps passé, au tout début, il y a deux ans, quand nous faisions nos premier pas : que de temps passé! La prise en main avait été assez longue. Mais une fois la maîtrise acquise par un développeur, il peut la transmettre assez vite, à condition de travailler de manière agile, et de ne pas hésiter, en tant que scrum master, à accepter de voir l'ensemble de l'équipe massée derrière le seul développeur "DNN fluent". Même si le troupeau reste longtemps ainsi, le résultat est garanti!

Vincent, lors de cette rétrospective de sprint, nous fait remarquer que le framework un peu contraignant de DotNetNuke amène finalement plus de rigueur dans la conception et la réalisation des CSS. Et c'est une bonne chose. Jerry renchérit avec cette comparaison imagée, un peu osée, mais ô combien vraie : le skinning DotNetNuke est aux feuilles de style ce que les alexandrins sont à la littérature.

Essayez! Vous verrez.  

Elle est arrivée, ma seconde équipe!

Petit déjeûner réglementaire, une tradition à laquelle je reste attaché depuis mon premier recrutement, et que je maintiens au fur et à mesure des nouvelles arrivées. Pour un premier partage avec le reste de l'équipe, et avec l'ensemble des collaborateurs des autres services. Un petit rite tout simple qui a le mérite de placer tout nouvel équipier dans un contexte favorable. Mettre l'humain avant le process, comme nous l'enseigne le manifeste agile. Et cela commence dès le premier jour. Mettre en place une relation humaine, avant de parler projet, méthode et développement. Je trouve toujours dommage, ces nouveaux venus que l'on nous a mal présenté, au détour d'un couloir, le nom à peine murmuré, la main à peine serrée.

Sauf que cette fois, c'est une équipe entière qui arrive le même jour. Pas une équipe de rugby, bien sûr, juste une petite équipe scrum de trois collaborateurs. Mais c'est déjà énorme. Une seconde équipe, en complément de l'équipe déjà présente, recrutée pour une opération "coup de poing", afin de développer rapidement de nouveaux outils.

La génèse de cette arrivée est assez emblématique de ce que l'adoption d'une méthodologie agile en générale et de scrum en particulier peut apporter. Il y a quelques mois, avant d'évoluer en scrum, j'avais "refusé" de m'attaquer à un projet un peu similaire, sur lequel j'aurais du concentrer 80% de mon énergie et ne garder que 20% de mon temps sur le "pilotage" de l'équipe actuelle. Je me souviens d'un comité assez animé où j'avais posé cette question : "et que deviendrait l'équipe de France sans Raymond Domenech?". Pas du plus heureux, sans doute, mais c'était une sorte d'aveu d'impuissance, je ne savais que faire, en fait : abandonner mes collaborateurs actuels ou refuser un projet somme toute intéressant.

C'est ce jour-là, finalement, que j'ai pris la décision de sauter le pas. Devenir agile, et accompagner mon équipe à réussir ce challenge.

Quelques mois plus tard, nouveau projet. Nouvelle étude de faisabilité. Et j'ai apporté la réponse suivante : banco, j'y vais, avec une seconde équipe scrum. Je ne déshabille pas Pierre pour habiller Jacques. Je reste scrum master de la première équipe, qui poursuit ses itérations sur les projets actuels. Et je deviens en parallèle scrum master d'une seconde équipe, pour mener à bien ce nouveau projet, piloté par les délais. L'agilité m'a permis ce qu'il m'aurait été impossible quelques mois plus tôt.

Oh, bien sûr, ce n'est pas non plus facile, facile. Une équipe est en bas. Une équipe est en haut. Scrum le matin pour la première. Scrum l'après-midi pour l'autre? C'est ce que j'avais écrit dans mon étude, mais je réfléchis encore à la meilleure manière. L'organisation optimale reste en rodage. Mais nous venons quand même de monter notre premier sprint, après une phase de deux semaines pendant laquelle l'équipe a plongé en apnée dans le projet, dans la méthodologie, dans la connaissance métier, dans le code, sans compter l'installation des postes, la familiarisation avec Team Foundation Server ...

En tout cas, cette expérience est tout a fait passionnante, exitante, nouvelle, et surtout inimaginable il y a peu.

Combien ça vaut, un Scrum Master ? #2

En lisant l'article consacré à Eric Gerets, l'entraîneur de l'Olympique de Marseille, dans le France Football de ce vendredi, j'ai trouvé un certain nombre de correspondances dans l'évaluation d'un entraîneur et celle d'un scrum master.

Eric Gerets est arrivé à Marseille au coeur de l'automne, pour tenter de redresser une équipe bien mal partie, seulement 17ème du classement. Et pourtant, un recrutement d'enfer avait été effectué durant l'été. Quelques mois plus tard, avec pratiquement les mêmes joueurs, l'OM est troisième. Combien vaut Gerets ? 14 places!

Que peut apporter un (bon) scrum master? Déjà, s'il arrive à faire passer l'équipe dont il a la charge, d'une gestion de projet traditionnelle vers une méthodologie agile, rien que là, déjà, c'est pas mal du tout. L'équipe est mise sur de bons rails. Les informations circulent mieux entre les développeurs. Plus personnes ne travaillent en silo. Chacun est amené à donner naturellement le meilleur de lui même. La communication, par principe de capilarité, hydrate à son tour les autres sphères. Le mur de Berlin séparant MOE et MOA disparait sous les coups de bélier de la révolution "Agile". Etc ...etc ...

Ensuite, si ce scrum master (très efficace) parvient à tirer profit du levier de l'extensibilité de la méthode, ce sera de l'économie d'un, de deux, voire de trois chefs de projets qu'il saura faire profiter l'organisation qui l'emploie, et donc le rénumère, en animant de front autant d'équipes Scrum, auto-organisées, auto-gérées et auto-apprenantes.

Pattern "Sprint" ou pattern "Round" ?

Une habituée du pilotage de projets en mode traditionnel évoquait nos projets agiles en terme de "round". Amusés, nous lui précisions qu'il s'agissait de "sprint" et non de "round".

Ce lapsus m'apparut après coup assez révélateur, et non simplement le fruit d'une confusion effectuée par une néophyte en méthodologie Scrum.

Qu'est-ce qu'un round? Une période de temps, prédéfinie, pendant laquelle les deux boxeurs mettent le plein d'énergie pour mettre l'adversaire KO debout. On parle aussi de round d'observation, pour évoquer l'art et la manière de déceler chez l'autre les faiblesses que l'on pourra utiliser.

Qu'est-ce qu'un sprint? Le moment fort d'une course pendant laquelle tous les coureurs accélèrent, pour atteindre la ligne d'arrivée, le but, l'objectif, le Grâl! Portés par un même élan, les adversaires se mobilisent tous ensembles, non pas finalement les uns contre les autres, mais tous ensemble pour dépasser le plus vite possible le fin cordon rouge de l'horizon.

Ces deux métaphores sportives sont tout à fait interressantes de ce point de vue. Qu'une personne rompue au management de projet en waterfall rebaptise l'itération agile en "round" exprime bien l'ambiance de certains gros projets informatiques traditionnels : le mode combat par KO. MOA contre MOE : qui gagnera? Prestataire au forfait contre client au cahier des charges : qui tombera sur le sable amer de l'arène? Métier contre analyste. Chef de projet contre développeur. Architecte contre responsable de production. La liste est longue ... Les méthodologies agiles ont au moins le mérite de faire assoir autour d'une même table toutes les personnes citées, non pas pour apposer leurs initiales au bas de contrats illusoires, mais pour construire ensemble les cathédrales de demain.