Manager une équipe de développement Web

Vous allez me manquer

C'était vendredi soir. Le projet s'arrête dans trois semaines, et l'équipe projet laissera ensuite la main à l'équipe interne, après un dernier sprint de quinze jours, qui permettra tuilage et passage de connaissances. Mais Zahira part un peu plus tôt que les autres, pour une quinzaine de vacances, bien méritées!

"Vous allez me manquer", nous a-t-elle dit.

Une petite phrase qui en dit long... En effet, elle n'aurait pu ne rien dire, simplement "au revoir!" ou encore : "ah, je suis bien contente de partir en vacances!" ou pire, "enfin partir de ce projet, de cette équipe : mon rêve se réalise enfin".

Ce que je consigne ici dans le journal public d'un scrum master, ce n'est pas tant le fait d'être satisfait en tant qu'animateur, mais surtout, parce qu'un projet, quand il se passe bien, quand les conditions sont mises en place, et conservées, jour après jour, malgré les hauts et les bas, les moments de galères inhérents à tout projet informatique quel qu'il soit, scrum ou waterfall, oui, parce qu'un projet est d'abord une aventure humaine, un moment partagé à plusieurs, un chemin parcouru, avec nos différences, nos convictions personnelles, nos caractéristiques féminines et masculines, nos cultures, nos habitudes, nos expériences diverses et variées, que nous devons porter ensemble, pour parvenir à cette construction unique, incroyable, qu'on appelle un projet informatique.

A la fin de tout projet, chacun devrait dire à l'ensemble de ses compagnons de voyage : "vous allez me manquer".

Je ne souhaite pas faire de prosélytisme, ni croire que mes convictions ont une quelconque vocation universelle, mais sur ce projet, oui, scrum a permis qu'au moins une personne dise "vous allez me manquer".

Merci Zahira!

Un homme seul est toujours en mauvaise compagnie

De cette citation de Paul Valéry, l’écrivain québécois Gary Klang a tiré un roman en 2005. Déjà, Jules Verne, dans son roman de 1905 « Le phare du bout du monde » explique pourquoi les gardiens de phare étaient toujours trois : si par malheur l’un des gardiens venaient à mourir, ils seraient deux à lui survivre, et il est toujours moins terrible de veiller un mort à deux que tout seul.

Alors, si vous avez à mettre en place un projet d’une charge estimée d’une année-homme, montez une équipe de trois à quatre développeurs, pour une durée de trois à quatre mois. Mais n’imposer pas jamais ce projet à un seul développeur. C’est garanti, à la fin, vous aurez sur la conscience la « mort » du développeur et celle du chef de projet.

Bien entendu, une équipe agile ne sera jamais, par définition du mot « équipe », confrontée à une telle situation tragique. L’agilité, si elle ne garanti pas le succès d’un projet par simple automatisme, garantit au moins la survie des développeurs !

Un développeur seul, aussi doué soit-il, ne pourra jamais assuré un succès à un projet. En effet, le poids du retard ou de l’échec est trop lourd à supporter pour une seule personne. S’il est seul, le développeur cherchera à dissimuler le retard qu’il a pris. Parfois même de la pire des manières, en accumulant les heures supplémentaires, les nuits blanches et les week-ends studieux, au bureau ou chez lui. Lorsque l’on est trois ou quatre dans une équipe, la responsabilité est collective. En cas de retard ou de problème, l’équipe dans son ensemble n’hésitera pas un instant à remonter les problèmes rencontrés, même au sein d’un projet non agile.

De même, de quel soutien externe peut bénéficier un développeur isolé ? Dans une équipe, chacun peut trouver auprès des autres membres une source de motivation, une pression douce pour suivre l’avancée collective. Et en cas de retard de l’un des membres de l’équipe, les autres peuvent se mettre à son niveau pour l’aider à refaire surface. Bon, juste une petite précision ici, c’est effectivement plus aisé à faire dans une équipe agile, où le scrum master est là pour faciliter ce genre de démarche, par l’incitation au travail en binôme ou en trinôme, afin d’optimiser les phases de passages de connaissances et le montant de compétence collective.

A tous les développeurs du monde, si un chef de projet tient à vous mettre sur un projet où vous serez seul, fuyez ! À toutes jambes, sans même vous retourner. N’acceptez jamais ce genre de mission. Sinon, vous signez votre arrêt de mort !

A tous les chefs de projets du monde, si votre boss vous oblige à mettre en place un projet dans lequel vous ne disposerez que d’un seul développeur, fuyez ! À toutes jambes, sans même vous retourner. N’acceptez jamais ce genre de projet. Sinon, vous signez votre arrêt de mort !

Enfin, à tous les bosses du monde, si vous voyez au sein de votre service, de votre compagnie, de votre organisation, un projet ne disposant que d’un seul développeur, arrêtez tout ! Stop ! Sinon, honte à vous ! Car c’est l’arrêt de mort de vos collaborateurs, et sans doute de la votre aussi, que vous signez.

Bonjour Zahira, bonjour Anthony, bonjour Omar

J'avais lu il y peu de temps sur le blog d'un scrum master qu'il avait essayé le "Bonjour, équipe!" au lieu du sempiternel "Bonjour à tous!".

La justification en était la reconnaissance de l'équipe en tant qu'unité.

Un jour, j'ai essayé, bien peu convaincu. Avant d'entrer dans la war room, j'ai respiré un bon coup, puis je me suis lancé sans y parvenir. Cela m'a fait rire. J'ai donc du expliquer la cause de mon hilarité en entrant ce matin-là.

Tout le monde était d'accord avec moi pour trouver l'idée saugrenue.

Alors, depuis ce jour, j'ai remplacé le sempiternel "Bonjour à tous!" par un bonjour personnalisé à chaque membre de l'équipe, bien appuyé. Bon, en même temps, on peut dire aussi que c'est le minimum de la politesse.

Dans l'histoire des trois rôles scrum, l'équipe est effectivement un rôle. Mais un rôle aux multiples visages, et c'est chacun des membres de l'équipe qui apporte sa richesse à la réussite de l'ensemble. On est tous d'accord pour dire que le collectif peut s'avérer supérieur aux sommes des individualités, d'où le 1+1=3, mais le collectif n'est rien sans la valeur des individualités.

C'est bien là l'un des sens profond du principe agile "Les individus et les interactions priment sur les processus et les outils". 

La mort au bout du planning

Il était une fois et une fois il n’était pas un projet informatique. D’une durée prévue de 12 mois, ce projet occupait à temps plein un chef de projet et un développeur. La communication entre le chef de projet et le développeur se faisait sans heurt :

- bonjour, ça va ? demandait chaque matin le chef de projet
- bonjour, ça va, répondait chaque matin le développeur.
- à demain, disait chaque soir le développeur.
- à demain, répondait chaque soir le chef de projet.

La seule entorse à cette routine somme toute assez joyeuse avait lieu tout les vendredis soirs, où le développeur disait :

- bon week end,
- merci, répondait le chef de projet, bon week end.

Le projet était sans risque, car il suivait un plan. Et pour éviter toute espèce de confusion, le plan était affiché au mur :

- du 1er janvier au 30 novembre : développement
- du 1er décembre au 21 décembre : recette
- du 22 décembre au 30 décembre : correction
- 31 décembre : mise en production.

Le développeur développait. Le chef de projet allait en réunion, avec son ordinateur portable. Il rédigeait des comptes-rendus dans Word, qu’il envoyait par email avec Outlook. Le soir, il faisait des suivis de projets, avec des fichiers Excel colorés. De temps en temps, il préparait des présentations, avec PowerPoint. Chacun vivait sa vie de son côté, tranquillement, sans embrouilles. Un projet de rêve.

En janvier, le développeur avait découvert qu’il pouvait jouer avec Pinball sur son ordinateur. Il ne mettait pas le son, pour ne pas déranger le chef de projet. De temps en temps, il regardait le plan affiché au mur. Il était rassuré.

En février, le développeur s’aperçut qu’il existait un logiciel sur son ordinateur qui s’appelait Internet Explorer et qui lui permettait de lire des informations très intéressantes sur l’avenir des abeilles, un sujet qui le préoccupait au plus au point. Le plan sur le mur n’avait pas bougé. Il savait où il allait. Le chef de projet était satisfait, lui aussi, car le développeur remplissait bien ses suivis. Le projet avançait donc comme prévu, sur des roulettes.

En mars, le développeur parti au ski. En avril, le chef de projet parti au ski. Mais le projet avançait bien, car le chef de projet avait bien pris garde d’envoyer par email le tableau de suivi au développeur, afin de bien anticiper toute cette période de congés.

En mai, le développeur pris connaissance du cahier des charges du projet. Un pavé de 682 pages. Ce fut une belle affaire, ce cahier des charges en .pdf, car le développeur n’avait pas le lecteur Acrobat. Il lui fallu un certain temps, à lui et au chef de projet, pour comprendre pourquoi, malgré tous les clics, le fichier ne s’ouvrait pas. Heureusement, on trouva la solution et une demande d’installation d’Acrobat fut transmise par voie hiérarchique au Service Informatique. Il y eu quelques dissension entre le Service Informatique et le chef de projet, car le responsable informatique reprochait au chef de projet de n’avoir pas anticipé cette demande qui allait occuper une partie de son équipe. Quand le développeur put enfin ouvrir le fichier du cahier des charges, le problème fut de pouvoir l’imprimer. Cela ne fonctionnait pas, une histoire de driver a priori. Le développeur n’osa pas, cette fois, déranger le chef de projet, après tous les problèmes causés par l’histoire du lecteur Acrobat. De toute façon, il pouvait le lire sur l’écran, cela fonctionnait aussi bien. Le développeur regarda le pla affiché au mur, et calcula assez facilement, grâce à la calculatrice intégrée à Windows qu’il devait développer l’équivalent de 682 pages divisé par 6 mois restant à faire soit l’équivalent de 113,6 pages par mois, c’est-à-dire environ 5,68 pages par jours. Après avoir lu les 10 pages de table des matières, il fut assez rassuré par ce calcul. Il remercia le chef de projet de ce plan affiché au mur.

En juin, le développeur commença à développer. Il avait lu sur Internet que Visual Studio Team System était un outil intéressant.  Mais comme le coût de la licence n’avait pas été prévu dans le projet, ce n’était pas bien grave, il utiliserait Notepad, qui est aussi un outil très intéressant, et surtout qui ne demande pas d’installation, donc évite les embrouilles avec le Service Informatique. La lecture de ses 5,68 pages par jour procurait une grande satisfaction au développeur, car il comprenait tout. D’ailleurs, il n’y avait rien à développer. Les 113 premières pages rappelaient l’importance du projet, les acteurs principaux, les attendus, l’existant, et bla bla bla...

En juillet, le chef de projet partit en vacances à la mer. En août, le développeur partit en vacances à son tour. Mais comme pour les vacances d’hiver, le suivi fut assuré. Avant de partir, le développeur s’aperçut qu’il prendrait du retard sur sa lecture quotidienne du cahier des charges, alors il mit les bouchées doubles. Heureusement, le plan affiché sur le mur lui rappelait l’objectif à tenir.

En septembre, le développeur s’inquiétait quand même un peu, car la lecture du cahier des charges devenait plus compliquée. Afin d’anticiper, et pour suivre le plan accroché au mur, il décida de manière unilatéral à venir tous les samedis.

En octobre, le développeur s’aperçut que plus il avançait dans sa lecture du cahier des charges, plus leur mise en œuvre en terme de développement s’avérait complexe. Il décida, toujours de manière unilatérale, de venir aussi tous les dimanches. Le chef de projet finit par s’en apercevoir car, le vendredi soir, le développeur oubliait de lui souhaiter un bon week-end et faisait comme les autres soirs. Le chef de projet décida alors de venir aussi travailler tous les week-ends.

En novembre, le développeur commença à se sentir un peu fatigué. Le chef de projet se mit aussi à coder dans Notepad. Le 11 novembre, le développeur dut s’absenter, car il était malade. Mais ce n’était pas grave, ils allaient rattraper leur retard. L’objectif clair affiché au mur les tenait motivé. Ils se mirent à développer aussi la nuit. Enfin, une nuit sur deux, car le développeur était de plus en plus malade. Le chef de projet, à force de développer, attrapa une tendinite, car il n’avait pas l’habitude de ce genre de tâches. Il se mit à le plus faire ses suivis. Ni à participer aux réunions. Le 21 novembre, le développeur envoya à la DRH un arrêt maladie d’une semaine. Il vient pourtant le 23 novembre, pour rattraper le retard. Le 24 novembre, il envoya à la DRH un arrêt maladie de 6 mois. Le 25 novembre, le chef de projet s’aperçut qu’il n’y arriverait pas tout seul. Le 26 novembre, son Directeur lui accorda une rallonge budgétaire, et une équipe de 10 développeurs arrivèrent. Le 27 novembre, le chef de projet s’aperçut qu’ils n’y arriveraient toujours pas, son Directeur lui accorda une nouvelle rallonge budgétaire et 20 nouveaux développeurs arrivèrent. Du 28 novembre au 30 novembre, pendant deux jours et deux nuits, tous les bureaux, les salles de réunion, les caves, les greniers, furent réquisitionné pour le projet. Malgré tout, ce n’était pas fini.

Le projet fut jeté à la poubelle. Le chef de projet fut mis dans un placard. Le directeur fut mis à la porte. 

On appela un scrum master, qui battit une équipe transverse, obtint un product owner digne de ce nom, arracha le vieux planning du mur et le remplaça par des grandes affiches de Will Smith et de Charlize Theron.

La puissance du 3

Le chiffre 3 est une des portes de notre univers.

En géométrie, le triangle est sans doute, avec le cercle, la figure la plus étudiée, car elle permet, entre autre, de passer de la première à la seconde dimension. L’association de trois points fonde aussi toute la trigonométrie et donc une grande partie de la physique newtonienne, de l’analyse des forces et de la mécanique.

Dans les relations humaines, le chiffre 3 est la quintessence même du passage de génération en génération en figurant la relation vécue par chaque homme, avec son père, et avec son fils.

Chez les chrétiens, le 3 est élevé au rang le plus haut avec la Sainte-Trinité, formé du père, du Fils et du Saint-Esprit.

En géopolitique, le monde fut longtemps équilibré entre 3 forces, les communistes d’un côté, les capitalistes de l’autres, et le tiers-monde entre les deux.

Et puis, 1 + 1 = 3, la valeur d’une équipe est toujours supérieur à la somme des individualités qui la composent…

Dans la méthode scrum, le chiffre 3 est lui-même élevé à la puissance 3 puisque nous pourrions résumer scrum à trois familles d’éléments : rôle, meeting, artefact, chacune de ses familles comportant trois éléments.

Il n’y a que trois rôles dans scrum, chaque rôle portant une responsabilité bien défini, sans chevauchement néfaste à la clarté des missions de chacun : l’équipe, le scrum master, le product owner. La responsabilité de l’équipe est de produire. La responsabilité du scrum master est d’assurer le suivi de la méthode. La responsabilité du product owner est de créer de la valeur. Chacun des rôles est complémentaire aux deux autres. Sans équipe, le scrum master ne sert strictement à rien, et le meilleur product owner du monde ne créera aucune valeur. Mais sans product owner, le scrum master aura beau être un super héros, animant une équipe de tueurs, le risque est grand de produire au mauvais moment un software qui ne servira à rien. Enfin, un product owner visionnaire ne sera pas d’une grande aide à l’équipe si le scrum master fait défaut : retard, désillusion, mal-être… En résumé, un « bon » projet scrum, c’est une équipe de tueurs, animés par un super héros, travaillant pour un visionnaire !

Dans scrum, on est amené à participé à trois meetings : le sprint planning, le sprint review et les daily scrum. Elucidons un peu tout ce joli franglais !

Le sprint planning, d’abord, c’est l’acte fondamental. Le product owner crée sa valeur en présentant à l’équipe et à son scrum master une liste d’éléments à produire, qu’il aura au préalable priorisé en fonction de leur valeur (en terme de business value et non en terme de valeur sentimentale…) attendue. L’équipe estime en charge relative ces éléments et s’engage sur un nombre d’éléments à produire lors du sprint. Le scrum master vérifie que les estimations de charge ont bien été faîte dans les règles de l’art, en particulier que le product owner n’intervient pas dans ces estimations, en faisant les gros yeux à chaque fois que l’équipe évalue une charge. De même, le scrum master aura bien vérifié que le product owner a priorisé de manière univoque les éléments à produire. Autrement dit, pas de product backlog constitué de 95% de priorité 1 et 5 % de priorité 2.
Le sprint review, c’est la démo, puis la rétrospective. La démo, c’est l’ouverture vers le monde. La rétrospective, c’est se regarder le nombril. Lors de la démo, l’équipe présente au product owner, mais bien au-delà, tout ce qui a été produit lors du sprint. L’intérêt est d’ouvrir le cercle des participants au plus grand nombre de collaborateurs et managers de l’entreprise. Lors de la rétrospective, chaque membre de l’équipe évoque devant les autres ce qu’il a pensé du sprint, les points positifs, les points négatifs, ce que l’on peut améliorer, individuellement ou collectivement.

Enfin, le daily scrum, c’est le rendez-vous quotidien de tous les membres de l’équipe, où chacun expose devant les autres l’avancée de son travail, et les obstacles éventuels rencontrés. Et c’est là que le scrum master endosse sa tenue de super héros, puisque c’est à lui de lever tous les obstacles qui empêchent l’équipe d’avancer. 

Quant aux artefacts de scrum, ils sont trois aussi : le product backlog, le sprint backlog et le burn down chart.

Le product backlog est sous la responsabilité du product owner. Il s’agit de la liste priorisée des user stories, maintenue jour après jour par le product owner, en fonction de l’évolution de la valeur qu’il attribue à chaque user stories.

Le sprint backlog est sous la responsabilité de l’équipe. C’est elle qui s’engage sur les user stories à produire lors du sprint. C’est elle qui décompose chaque story en tâches de développement, et s’organise pour en assurer la production de manière optimale.

Le burn down chart, enfin, est maintenu par le scrum master. Il retrace en temps réel, scrum après scrum, les tâches ou les user stories qui restent à faire. A la vue du profil du burn down chart, le scrum master doit prendre les bonnes décisions afin d’assurer à l’équipe un rythme de travail optimal.