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 brun 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. 

Donner la parole aux développeurs

Un aspect intéressant de Scrum réside dans la parole donnée aux développeurs. Lors des démos, par exemple.

Au fur et à mesure des sprints, nous nous sommes améliorés, pour avoir maintenant un schéma de démos assez satisfaisant.

Peu de temps après la constitution du sprint à venir, j'envoie un email d'invitation à la prochaine démo, à destination d'un cercle de plus en plus étendu. C'est le fameux concept du cercle d'influence de Stephen Covey, que l'on agrandit au fur et à mesure, à condition d'avoir su monter à l'intérieur de soi-même une organisation solidement fondé sur des principes. Ces principes, j'en ai quatre, les quatre principes de l'Agile Manifesto. Donc, pour en revenir à mon "carton d'invitation", je l'envoi au Product owner et responsables métier, responsables utilisateur, maîtres d'ouvrage, responsable organisation et gestion du changement, directeur des systèmes d'information, responsable des études informatiques, chefs de projet, développeurs d'autres équipe, graphistes, etc... Cela peut sembler au départ beaucoup de monde, mais avec l'expérience, je sais qu'en moyenne une personne invitée sur deux ne peut pas venir.

Dans ce "carton" électronique, je liste les différentes user stories sur lesquelles l'équipe s'est engagé lors du sprint à venir. ET pour chaque user story, je précise ce qui sera présenté lors de la démo : celà peut être un modèle de données, des flux d'alimentation de tables en présentant l'avant et l'après, tables vides et tables remplies, un site web, des web services avec dans ce cas, différents type d'appel, nominaux, avec erreur gérée, ...

En générale, nos démos ont lieu le vendredi après-midi. Le matin, je fais donc un point préparatif de la démo avec l'ensemble de l'équipe. On définit qui présente quoi, comment, si plusieurs écrans sont nécessaires, on s'entend sur quelques scénarios, de manière à mettre en scène le travail effectué pendant le sprint.

Lors de la démo, je laisse mes invités debout! avec quelques chaises à disposition pour qui veut s'asseoir. Cela donne un peu une ambiance cocktail, les échanges sont plus fluides, les discussions plus actives.

Je prends la parole en entrée de la démo, pour souhaiter la bienvenue aux participants et les remercier de leur présence, puis je rappelle le contexte du sprint àà l'intérieur du projet, ses attendus, ce qui a pu être réalisé, et le cas échéant, ce qui n'a pas pu l'être. Je donne ensuite la parole à l'équipe, selon les scénarios définis le matin. Souvent, on s'en éloigne un peu, parce qu'un participant pose une question complémentaire par exemple, qu'une règle métier est précisée...

Parfois, j'interviens lors des présentations effectuées par l'équipe, si je sens qu'on oublie quelque chose, ou qu'une précision doit être donnée, mais j'évite d'intervenir trop souvent. C'est le travail de l'équipe, pas le mien. Je suis responsable de la méthode, pas de la production des développements. C'est aux membres de l'équipe de s'exprimer sur leurs productions. Et cela fonctionne plutôt bien.

Pour en revenir à l'idée principale de ce billet : la parole donnée aux développeurs, je remets en comparaison ma propre situation lorsque j'étais jeune développeur. En tant que développeur, je n'avais guère la parole. Seuls les chefs de projet communiquaient avec les clients ou les demandeurs. Et lorsque l'on passait de développeurs à chef de projet, on se retrouvait brutalement installé à de grandes tables de réunion, entouré de responsables opérationnels métier et de directeurs, terrorisé à l'idée même de sortir le moindre son.

Aujourd'hui, avec les démos, les développeurs s'habituent dès leur premier projet, à prendre la parole, à exposer leurs travaux, à communiquer... et lorsqu'ils deviendront à ler tour product owner ou scrum master, ils auront déjà derrière eux cette expérience de prise de parole.

Scrum en dehors du monde du software

C’est encore le temps des vacances, pas besoin d’être foncièrement sérieux. D’ailleurs, avec l’agilité, même au sein des moments de labeur les plus intense, il reste toujours un espace pour le fun, le jeu, l’échange, l’inhabituel…

Quand j’écris pas foncièrement sérieux, c’est que je vais vous parler maintenant d’une petite communauté, d’une toute petite communauté sise dans nos belles montagnes, dont les membres n’ont rien à voir avoir le développement logiciel, et n’ont sans doute jamais entendu parler de scrum, de scrum master ou autre product owner.

J’ai eu le bonheur de les visiter il y a bien longtemps de cela, mais les dialogues, les échanges sont restés gravés dans ma mémoire.

Vivant en quasi-autarcie, et sous le vœu de pauvreté, les frères et les sœurs de cette petite communauté ne pouvaient compter que sur eux-mêmes pour bâtir leur maison, élever leurs animaux et cultiver leur jardin. Mais il n’y avait ni fermier, ni maçon, ni électricien, ni plombier parmi eux. Qu’à cela ne tienne, ils faisaient quand même tout par eux-mêmes. Car le terme équipe, quand il s’agit d’une véritable équipe, n’est pas un vain mot. Je les ai vu à l’oeuvre.

Ils ne connaissaient pas scrum, et moi non plus d’ailleurs à cette époque, c’était bien avant, vous dis je, que je m’imagine un jour manier du software…mais la fondatrice qui élevait tout ce petit monde dans la spiritualité la plus pure, pour les choses matérielles de la terre, avait mis en place une méthode très …scrum. Tout les après-midi, juste après le repas, quand l’arôme du café flotte encore au dessus de la table, un à un, elle demandait à chacun des membre de la communauté ce qu’il avait fait la veille, et ce qu’il ferait l’après-midi. Il s’agissait de clôturer un pré, de nettoyer une étable ou une bergerie, de vacciner un troupeau entier, de récolter le miel, de monter des parpaing, de vider un grenier, etc… des équipes de deux, trois personnes se formaient à ce moment-là, spontanément, quand certains n’avaient rien de spécial à entreprendre, et qu’ils voyaient que d’autres avaient besoin d’aide. Et très régulièrement, les travaux étaient présentés. La nouvelle chambre tapissée. Le plancher d’un couloir. Le veau qui vient de naître… Il s’agissait d’une communauté de l’Esprit, je le rappelle, pour que vous compreniez mieux la signification du « done ». Chaque chose terminée était baptisée et bénie par la fondatrice. Je l’aurais mal imaginé baptiser une pièce au trois quart tapissée, un toit mal fait, ou une récolte non terminée. Il ne pouvait pas y avoir de mauvaise interprétation de ce côté-là.

La fondatrice pouvait trancher, un chantier plutôt qu’un autre, à l’image d’un product owner qu’elle était sans le savoir, tout en étant scrum master, car gardienne du temple, gardienne de la méthode qu’il était bon de suivre pour poursuivre dans cette voie des bâtisseurs. Bien sûr, il pouvait y avoir des obstacles. Un mur récalcitrant, une récolte mauvaise. Parfois, avec l’esprit, une prière peut suffire, mais il faut aussi savoir s’entourer. Alors les obstacles étaient levés par des interventions extérieures, des amis, qui avaient la science du troupeau, de la terre ou des parpaings.

Oui, scrum fonctionne. La preuve, la petite communauté de mon histoire a réussi trois fois, sans partir de rien, à bâtir une grande maison. Il suffit pour cela d’un beau projet, d’une vision claire et précise de ce projet, d’un product owner et d’un scrum master, d’une équipe, de communication quotidienne, de produits finis.

Backlog de ballons de baudruche et de bateaux en papier

Un petit retour sur ma formation Scrum Master avec Jeff Sutherland. A la fin du deuxème jour, Jeff nous a donné quelques XP Games appréhender. A chaque sprint, un ensemble de cartes est distribué à chaque équipe, avec des user stories du styles "Gonfler 10 ballons de diamètre 40 cm" ou "Plier 5 bateaux en papier". A chaque user story est attribuée une valeur business allant de 100 à 400 unités. A l'équipe de définir ensuite le niveau de risque et de faisabilité à attribué à chaque user story. Ensuite, il s'agit pour le Product Owner désingé dans l'équipe de définir et prioriser les user stories à effectuer. Dans ces jeux, le rôle du Scrum Master est plutôt effacé. En revanche, en trois sprint de 10 minutes, on comprend parfaitement le rôle du Product Owner.

Parce que bien sûr, Jeff est malin. Pendant qu'on s'amuse à gonfler des ballons pendant le premier sprint, sans trop savoir si on retombe en enfance, et qu'on va se réveiller, malheureusement, de ce rêve joyeux, Jeff, lui remplit une feulle Excel projetée au mur, qui détaille pour chacune des quatre équipes du stage les résultats obtenus en terme de valeur business.

Dès le deuxième sprint, l'émulation fait son oeuvre, et le Product Owner calcule avec l'équipe les bonnes user stories à prioriser, afin de créer un maximum de valeur, en un minimum de temps.

Voilà, le rôle du Product Owner est bien ici : prioriser, prioriser, prioriser. Par cette priorisation, il est le garant de la maximisation de la valeur. Le Scrum Master est le garant de la méthode. Et l'équipe est la garante du développement!

Avec quelques ballons et quelques origamis, en une demi heure de temps, on comprend tous comment fonctionnent les trois rôles scrum.

Pattern Maître et anti-pattern Chef

A la fin d'un scrum matinal, l'équipe me demande si je pouvais leur faire installer Query Tool. Simple obstacle à franchir. C'est l'une de mes tâches de scrum master. Aussitôt demandé, aussitôt fait. La bonne personne est contactée et je prends rendez-vous avec elle pour que l'installation soit faite dès le lendemain matin sur l'ensemble des postes de l'équipe.

En réponse, l'un des membres du Team m'envoie un email : "Merci, Chef!".

Je lui réponds alors par ce début de litanie, qu'il est aisé de poursuivre à l'infini...

Avis aux amateurs!

• Le Chef commande et contrôle.
• Le Maître connaît et enseigne.
• Le Chef tape et cogne.
• Le Maître partage et dialogue.
• Le Chef est sourd et aveugle.
• Le Maître écoute le chant du monde et regarde la lumière de la vie.
• Le Chef mène ses projets à la catastrophe.
• Le Maître emmène son équipe Scrum vers des succès joyeux.

 

Backlog de galets, de coquillages, de sable et d'eau de mer

Depuis longtemps, je me dis que je devrais relire les ouvrages de Stephen Covey à la lumière de l'agilité en générale et de scrum en particulier. Un joli sujet de thèse en perspective pour un futur Docteur en Management. Avis aux amateurs...

L'histoire suivante est adaptée de Covey, adaptée au temps des vacances et des plages surchargées d'enfants chahuteurs.

Jean-François, appelons le Jeff, est animateur au club Mickey. Ce matin-là, il rassemble devant lui le groupe d'enfants dont il a la charge, avec la mission délicate de capter leur attention pendant au moins une demi-heure. Les enfants sont assis sur le sable. Jeff prend un seau, un grand seau. A côté de lui, une pyramide de galets roulés par la mer. Il prend les cailloux un à un, en les déposant avec soin dans le seau, jusqu'à ras bord. Alors, il demande à sa jeune assistance : "Le seau est-il plein?", "Oui, il est plein", répondent les enfants en choeur.

Jeff hoche la tête. Il se lève et prend un petit seau, rempli de petits morceaux de coquillage brisé : coques, huitres, moules, chapeaux chinois... de toutes les couleurs, nacrés, emiettés. Il verse le contenu de ce seau dans le grand seau plein de galets. Et là, ô miracle! devant les yeux des enfants médusés, les brisures de coquillages se frayent un chemin entre les galets et se déposent au fond du seau. Jeff vide les coquilles jusqu'à ras bord. Alors, pour la seconde fois, il demande aux enfants : "Le seau est-il plein?", "Oui, il est plein, plein, plein!", répondent-ils tous d'une seule voix.

Jeff hoche de nouveau la tête. Il pose ses mains sur le sable, sur le sable chauffé à blanc par l'été, bien sec, fin comme de la poussière, puis en prend une poignée, et la verse sur le seau. Les grains de sable coulent doucement, entre les galets, entre les coquillages brisés...Jeff recommence plusieurs fois, jusqu'à ras bord. Alors, pour la troisième fois, il demande aux enfants : "Le seau est-il plein?". Cette fois, ils hésitent. Ils ne ssavent plus trop quoi penser. Pourtant, une nouvelle fois, ils répondent, mais plus timidement "Oui, le seau est plein".

Jeff hoche la tête. Il prend le petit seau qui avait conteu les coquillages et demande à un grand dadais d'aller le remplir d'eau de mer. A son retour, Jeff prend le seau d'eau puis, goutte après goutte, le verse sur le grand seau déjà rempli de galets, de coquillages et de sable. Chaque goutte s'enfonce dans le mélange, bu par le sable, qui change petit à petit de couleur. Les enfants applaudissent, fascinés par cette démonstration.

Jeff demande alors : "Quelle est la morale de cette histoire?". Certains réfléchissent, d'autres répondent : "Quand on croit que c'est plei, en fait, c'est pas encore plein!".

Jeff hoche la tête. "Non, les anfants, cette histoire n'a pas de morale. C'est en mettant cette histoire à l'envers, qu'il y a une morale.". Alors, Jeff se lève, prend un nouveau seau, aussi grand que le premier, et le remplit d'eau de mer. Puis, se rasseyant devant les enfants, il prend du sable fin dans ses mains et le verse dans le seau plein d'eau. A chaque nouvelle poignée de sable, l'eau déborde. Puis il prend un petit seau rempli de coquillages cassés, et le verse par dessus. Cela fait un petit tas, une petite pyramide pointue. Puis il tente de poser par dessus des galets. Ceux-ci roulent les uns après les autres, sur les côtés de la pyramide de coquillages, et tombent à côté du seau.

"La morale de cette histoire, reprend Jeff, c'est que si vous commencer à faire les petites choses avant les grandes choses, vous n'y arriverez jamais!". Puis il lance un sprint, le dernier dans la mer fera dix pompes. Et tous s'en vont en courrant, dans un brouhaha indescriptible.

Ce que ne savent pas les enfants, c'est que Jeff est Product Owner, dans la vraie vie. Et qu'il gère bien son backlog. Avec des priorités bien spécifiées. Une priorité de 100 pour le projet le plus important en terme de business. 200 pour le suivant, 300 pour le troisième,etc... Jusqu'à 1000, ce sont ses galets. De 1000 à 2000, ce sont ses petits coquillages. De 3000 à 4000, ce sont ses grains de sable...