Manager une équipe de développement Web

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

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 !