Manager une équipe de développement Web

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.    

Recrutement express

Je suis assez content. Le recrutement de ma seconde équipe est presque clos. Trois collaborateurs, sur les quatre attendus, ont été sélectionnés. Ce qui est sympa, c'est qu'ils viennent tous les trois du même partenaire, avec qui je travaille depuis un an et demi. La fidélité vis à vis de son réseau et de ses partenaires s'avère d'une très grande force. Le recrutement de collaborateurs de qualité dans le monde de l'informatique en général et du développement web en particulier est assez difficile. Il s'agit d'une sorte de jungle, en fait, avec ses codes, ses lois, ses bêtes féroces, et ses charognards, aussi. Savoir où l'on avance pour ne pas tomber dans les pièges cachés sous les fourrés est indispensable. Je suis ultra sollicité, plusieurs appels téléphoniques chaque jour, spammé en permanence, que ce soit dans ma boîte aux lettres professionnelles ou personnelles, mais je sais que sur toutes ces sollicitations, il faut se montrer sélectif à l'extrême. Il fut un temps où j'acceptais tous les rendez-vous qu'on me donnait. Oh! la la! quelle perte de temps. Alors, depuis, je me suis constitué un réseau de partenaires sur lesquels je sais pouvoir compter, en toute confiance, comme ils savent aussi pouvoir compter sur moi, et ma manière d'encadrer les collaborateurs qu'ils me confient. Car la confiance doit marcher dans les deux sens.

Quelques petites anecdotes?

Il y eu l'affaire des 47 secondes.

Allo? Monsieur Doillon? Avez-vous 47 secondes à m'accorder? PAs une de plus pas une de moins. En fait, j'ai un problème avec l'un de nos ingénieur. Il est en inter contrat et il s'ennuie. Il gamberge. Est-il possible qu'il vienne chez vous, comme ça, pendant quinze jours? Vous trouverez bien quelque chose à lui donner?

Il y eu l'affaire de celle que je faisais suer.

Allo? Monsieur Doillon? Bon, le CV de ce webmaster que je vous ai envoyé, vous en pensez quoi? Franchement, prenez-le! Moi, ça me fait vraiment suer de voir ce gars en inter contrat. Je vous le dis, ça me fait vraiment suer.

Sans compter le commercial débutant. Ce n'est pas au téléphone, mais en entretien, avec présentation d'un collaborateur.

On se sert la main. Bonjour, Monsieur Doillon, excusez-moi mais je suis débutant. Le collaborateur présente ses précédentes missions. Puis le commercial : je suis débutant. Excusez-moi. Je vais vous présenter ma société. Et puis, à chaque question que je posais : excusez-moi, je suis débutant. En fin de compte, j'avais choisi un autre ingénieur, d'une autre SSII. Lors de mon appel pour lui apprendre que je ne travaillerai pas avec sa société, je lui ai quand même dit : "juste un conseil qui pourra vous servir pour la suite de votre carrière. Que vous soyez débutant n'est pas un problème. nous l'avons tous été un jour. Mais éviter de l'annoncer à tout bout de champ en vous en excusant."

Et puis, il y a aussi les grosses structures, avec pignon sur rue, mais qui ne répondent jamais, parce qu'on est trop petit, et qu'on leur envoie un appel d'offre pour une mission de trois mois d'un seul ingénieur. Je ne citerai pas de nom...même si l'envie m'en brule les doigts.

Et maintenant, j'attends mardi matin, pour un dernier rendez-vous qui, je l'espère, sera fructueux pour boucler ce recrutement ... express.

L'ambition d'un Bauhaus numérique

Quel est l'un des principe essentiel d'une équipe Scrum? La pluridisciplinarité.

Rassemblez dans un même lieu des personnalités différentes, aux talents complémentaires, aux compétences hétérogènes, et focalisez-les vers un seul objectif, tout en les laissant s'organiser par eux-mêmes, en les aidant jour après jour en levant les obstacles qui pourraient les empêcher d'avancer.

La pluridisciplinarité.

J'ai longtemps étudié l'histoire du Bauhaus, sa stratégie et la philosophie qui a donné lieu à la plus grande école d'art et de design de tous les temps : Klee, Kandinsky, Itten, Albert, Moholy-Nagy, Feininger, Schlemmer, Breuer pour ne citer que les plus grands. Des maîtres de la peinture venus de l'Europe entière, des architectes, des sculpteurs, des forgerons, des tisseurs, des photographes...qui ont, entre 1919 et 1933, créés, entre autre, les canons du design, qui perdurent encore de nos jours. Ateliers de métal, de poterie, de menuiserie, de textile, de poterie, de verre ... toutes les matières comme autant de compétences : la richesse naît de la différence et non de l'uniformité.

Web design, C#, Web Services, Fitnesse, CSS, Photoshop, Visual Studio, XML, HTML, SSIS, IIS, SQL, NUnit, Team Foudation Server, PNG, ASP.NET 2.0... 

Et si finalement, la mission d'un Scrum Master, ce n'était pas tout simplement l'ambition folle d'animer un petit Bauhaus numérique?

Fitnesse

Je viens de commander sur Amazon le livre de Gojko Adzic concernant l'utilisation de Fitnesse dans les applications .Net. Pour ceux qui ne le connaissent pas, Fitnesse est un outil d'automatisation de recettes à destination des analystes fonctionnelles. D'une très grande simplicité d'utilisation, il permet une communication très souple entre les équipes de développements et les analystes. Il fonctionne par wiki et se base sur Excel! Pour simplifier en une phrase, dans une colonne on liste les données entrantes, et dans une autres les données attendues. On colle l'ensemble dans une nouvelle page du wiki. Et on execute. Si c'est vert, c'est ok. Si c'est rouge, le test d'intégration ne passe pas. On ne peut pas faire plus simple!

A l'origine, Fitnesse a été conçu pour les applications Java. Le wiki tourne d'ailleurs en Java. Et la documentation pour .Net est quasi inexistante. C'est bien là tout le mérite de Gojko d'avoir rédigé ce livre pour nous faire partager son expérimentation.

Je recrute ...

Si l'on suit les étapes de mise en place d'un projet détaillées par Joseph Little dans son post récent How do I start an Agile project? , j'en suis à l'étape 2, celle de la construction de l'équipe.

L'étape 1, celle qui me dit si j'ai réellement un effort significatif à mener, est franchie. Nous n'avons qu'une vie, et il est préférable de la passer sur des projets qui ont de la valeur. Surtout en tant que responsable d'équipes, inutile d'entraîner une équipe entière dans une aventure que l'on saurait pourrie dès le départ.

L'aventure sera belle!

J'ai donc maintenant quinze jours à trois semaines pour monter une nouvelle équipe Scrum. Pour celà, je cherche deux à trois développeurs et un testeur.

Les technos et les outils? Asp.net 2.0, C#, Micrososft Sql Server, Visual Studio 2005, Team Foundation Server, DotNetNuke. La connaissance de NUnit serait un plus. L'expertise dans le développement de Web Services et la maîtrise des aspects sécurités qui y sont attachés seraient deux atouts considérables.

Les profils? C'est simple, je veux des tueurs! Les meilleurs du monde, passionnés, enthousiastes.

Le contenu du projet? euh, top secret! je ne peux pas dévoiler ces infos sur mon blog perso...

Les challenges? ajouter une dimension à notre pratique de l'agilité. En passant d'une seule équipe aujourd'hui, à deux équipes, ce projet est une première pierre dans la pratique et l'expérimentation de la "scalabilité" de Scrum.

SSII s'abstenir! Non pas que je ne travaille pas avec les SSII, mais j'ai déjà un réseau auquel je reste fidèle.

La preuve par 9

Ce matin, en saisissant dans Team Foundation Server les user stories et les tâches associées sur lesquelles l'équipe s'est engagée, je me suis aperçu qu'il s'agissait de notre neuvième sprint! Déjà neuf sprint! Et dire qu'il y a un an, je n'avais jamais entenu parler de Scrum. C'est à peine si j'entrevoyais un rai de lumière filtré sous la porte de l'agilité.

Neuf sprints de 2 semaines. Nous n'avons pas changé notre rythme depuis lepremier, le sprint que j'avais appelé Sprint Zéro, ne sachant pas, à ce moment là, si le management et l'environnement nous permettrait de continuer. Mais l'exemple a fait preuve.

Neuf sprint et trois équipes différentes, puisque par rapport au sprint zéro, suel un des développeur a participé à tous les épisodes. Comme quoi Scrum s'avère aussi un accélérateur d'intégration.

Oh, je suis loin d'écrire que nous faisons tout de bien. Encore beaucoup de choses restent à améliorer, en particulier sur notre environnement technique : pas encore de test unitaire, ni de test d'intégration, ni de gestion de branche... Mais cela ne saurait tarder. J'ai dealé avec notre Product Owner pour que l'on puisse réserver un sprint entier à nos preojets techniques : gestion des branches, NUnit et Fitnesse.

Pattern "Chien de berger" et "Chien dans un jeu de quilles"

Un commentaire récent me faisait me remémorer cette question de mon boss, à l'issue de notre premier sprint : "mais si l'équipe s'auto-organise, comment les développeurs choisissent-ils les bonnes tâches? ne vont-ils pas prendre les tâches dans le désordre et commencer par celles qu'il serait préférable de traiter en dernier?".

Judicieuse question? En fait, c'est bien dès le premier scrum du premier sprint que j'ai compris l'évidence de la réponse. L'équipe s'auto-organise effectivement. Elle ne fait pas semblant, et chacun ne choisit pas les tâches selon ce qu'il lui plait mais selon l'objectif collectif à attendre à la fin du sprint. Le dépilement des tâches se fait de manière cohérente, logique. Essayez pour voir! Il n'y a aucun risque.

En revanche, le risque inverse existe : celui du Scrum Master qui confond "protection" et "injonction". J'ai du faire l'erreur une fois ou deux. Demander à un développeur s'il pouvait effectuer telle tâche plutôt qu'une autre. Et là, instantanément, c'est le chaos total. De "chien de berger", je suis devenu "chien dans un jeu de quille". Après de telles interventions, il faut bien un jour ou deux pour que l'équipe se remette en marche de manière normale. C'est la première règle d'or : ne jamais intervenir directement. Aider, faciliter l'équipe à discuter, à décider des choix. Mais ne jamais s'en mêler. Un Scrum Master interventionniste est le pire fléau pour l'équipe. Je suis encore très loin de tout comprendre de Scrum, mais c'est bien la première chose que j'ai appris, dès la pratique de nos premiers sprints.

(Photo: MHN/Alain Germond)

Combien ça vaut, un Scrum Master ?

Après le succès incroyable de mon post de l'an passé sur les jobs en or en général, et celui de Directeur Technique Web en particulier, voici que je repose une question identique, mais cette fois à propos du poste de Scrum Master.

Ma réflexion date d'il y a quelques jours, à la lecture de quelques échanges sur le ScrumDeveloppement Groupe de Yahoo, à propos du salaire de Scrum Master aux Etats-Unis. L'idée, bien sûr, étant qu'un Scrum Master n'a pas vraiment de prix, tout dépend de ses capacités à accélérer les développements de son employeur, et donc du business qu'il lui permet d'atteindre.

Et en France ? Les propositions "officielles" sont encore peu nombreuses. Il y a bien sûr l'offre de Valtech, qui cherche depuis plusieurs mois maintenant des coaches agiles et scrum masters. J'étais heureux de trouver aussi une annonce de Scrum Master sur Monster, intitulée "SCRUM MASTER POUR UN EDITEUR DE LOGICIEL" et proposée par un grand éditeur français de solution de Web Self Service, entre autres. La fourchette de salaire affichée va de 55 k€ à 65 k€. Le truc marrant, c'est que l'offre apprait aussi sous l'intitulé "DIRECTEUR DE PROJET METHODES AGILES POUR UN EDITEUR DE LOGICIEL". Comme quoi Scrum ne parle pas forcément à tout le monde. Mais qu'en même temps, on arrive au début d'une nouvelle ère. Valtech, et ses consoeurs, ne sont plus les seules à recrtuer des Scrum Masters. Les éditeurs commencent donc à s'y mettre. Et demain viendra le tour des sociétés utilisatrices...

Pattern du Cerf et de la Licorne

Au cours des deux derniers sprints, j'ai constaté que l'équipe n'était pas à l'abri d'une petite dérive de trop vouloir bien faire. Au cours du sprint précédent, l'une des user story, sur laquelle l'équipe s'était engagée, pouvait facilement être réaliser en ajoutant une verrue dans l'accès aux données du code existant. Pas très propre. Soit. Au cours d'un scrum, l'un des développeur a proposé de factoriser le code afin d'obtenir un contrôle générique, facilement maintenable par la suite. Un débat assez animé s'était poursuivi dans l'équipe, entre les tenants de cette option, et les tenants de l'option contraire. Finalement, c'est le code générique qui a été choisi. Mais du coup, le sprint a dérapé sur le sprint suivant.

Script suivant. L'histoire se répète. On opte pour la création d'une nouvelle couche de Business Object Library. Je suis assez pour. Puis, en milieu de sprint, un développeur propose d'aller plus loin dans la factorisation et de mettre en place un projet complet, de la couche de données jusqu'à la couche de présenttaion, générique, qui pourrait être appelé de l'ensemble de nos sites Web.

Je repense alors à quelques échanges que j'avais lu sur le Scrumdevelopment group de Yahoo, en particulier, à l'un des intervenant qui racontait que son équipe, lorsque l'un des développeurs s'éloignait un peu trop de l'objectif du sprint en cours, beuglait comme des cinglés "Attention aux bois du caribou !".

Je me suis alors dirigé vers le tableau blanc, et j'ai longuement disserté sur le modèle du Cerf et sur celui de la Licorne. D'un côté, le Cerf et ses ramures immenses, qui n'en finissent plus. De l'autre, la Licorne et sa corne unique. D'un côté, attention de ne pas perdre le fil du développement, des engagements pris au lancement du sprint, de l'autre, une vision claire de ce l'on veut faire, un objectif unique, bien défini. Attention aux méandres. On m'a fait remarquer, bien sûr, qu'il peut être important, aussi, de passer plus de temps sur une factorisation de code, pour en bénéficier ensuite. C'est là toute la difficulté, d'ailleurs. Choisir entre le Cerf et la Licorne, sans se tromper.

Scrum (et XP) des tranchées

Il vient d'arriver dans ma boîte aux lettres : un petit livre de 120 pages dans lequel Henrik Kniberg raconte ses histoires de mise en place de Scrum, ses essais, ce qui a marché, ce qui n'a pas marché. Ce n'est pas un livre de recette, juste ce que lui a fait, et qui a fonctionné. Des histoires de pratiques. Mais beaucoup de "trucs" à expérimenter, en l'occurrence. A esssayer chez soi, à adapter. Et des questions que l'on se pose, avec des réponses associées.

Il se lit vite, mais combien de réflexions géniales il permet d'initier!

Pattern "Roi/Serviteurs" ou "A Chacun sa Mangeoire" ?

Dans une longue discussion avec le directeur produit et son équipe de chefs de projet, j'étais un peu pris à partie sur le fait que mon équipe se focalisait sur une user story. L'impression générale était une certaine lenteur. Pourquoi, me demandait-on, chacun des développeurs ne travaille-t-il pas sur une user story différente, permettant ainsi une sorte de "multi-threading" de développement ? 

Ma réponse, un peu toute faîte, arguait que l'équipe s'auto-organisait d'elle-meêm, et que je n'avais pas à intervenir sur leur choix de développement. La cseule chose qui comptait, pour moi, c'est que l'ensemble des travaux à mener lors du sprint sont bien affichés, compris de tous, avec un engagement collectif sur leur réalisation à la fin de l'itération. L'ordre, la manière d'implémenter les user stories, n'a que peu d'importance.

Je suis tombé deux jours plus tard sur un article d'Henrik Kniberg qui entre autre, défend une priorisation entre les user stories d'un sprint. La user story prioritaire permet au développeur qui l'implémente d'être le roi. Les autres sont les serviteurs, et ils doivent tout faire pour aider le roi à achever sa mission : libération du code, etc ... Et comme tout le monde veut être roi, finalement, la plupart des membres de l'équipe, de manière naturelle, va se répartir les tâches pour développer la user story prioritaire. C'est pas mal, car si elle est prioritaire, autant qu'elle soit terminé le plus vite possible.

J'étais satisfait de trouver cet argument chez l'un des leaders de l'agilité.

Le plus drôle cependant, c'est que lors du sprint suivant, chacun des trois développeurs s'est naturellement mis sur une user story différente, en fonction de leur affinité. L'idée, cette fois, s'était que chacun puisse donner un maximum d'efficacité là où il est le plus fort. Comme quoi! Il n'y a pas de règle. C'est aussi l'une des forces de l'agilité : coller au plus près du terrain, sans a priori. Et faire différemment la prochaine fois, si les conditions du sprint demandent une autre organisation.