Le nouveau livre de Jeff Scrum : L'art de faire deux fois plus de travail en deux fois moins de temps sortira le 30 septembre 2014. J'ai pensé partager avec vous un extrait de ce livre qui explique comment le Daily Scrum a vu le jour. Pré-commandez le livre à l'adresse suivante Amazon, BN, iTunesou Relié à l'unité.
Avec la première équipe Scrum d'Easel Corporation en 1993, je leur ai régulièrement montré un vidéo des All Blacks équipe de rugby se préparant pour un match. Les All Blacks, équipe légendaire du petit pays qu'est la Nouvelle-Zélande, sont une équipe transcendante. Avant chaque match, ils exécutent la cérémonie guerrière maorie du haka. Le haka est une danse guerrière qui donne de l'énergie à ceux qui s'apprêtent à partir au combat. En la regardant, on peut presque voir l'énergie se dégager de chaque joueur et se fondre en un tout plus grand. Avec des battements de pied, des applaudissements et des chants synchronisés - des mouvements ritualisés pour trancher la gorge d'un ennemi -, on peut voir des hommes ordinaires se transformer en quelque chose de plus grand, de plus grand. Ils invoquent un esprit guerrier qui n'accepte ni la défaite ni le désarroi.
Il a fallu plusieurs visionnages de la vidéo, mais mon équipe de programmeurs informatiques un peu déglingués a fini par se demander comment ils pourraient être ainsi.
Ils se sont donc penchés sur la littérature pour savoir comment les meilleures équipes s'y prenaient. L'un des aspects les plus intéressants du développement de logiciels est que la situation était si mauvaise au début, et que tant d'argent était gaspillé - des milliards et des milliards chaque année - que les gens ont passé beaucoup de temps à étudier les raisons de ce gaspillage, et il y avait des données sur tout.
L'un des documents que nous avons trouvés portait sur l'examen d'un projet de Borland Software Corporation appelé Quattro Pro pour Windows. Pour ce projet, un million de lignes de code logiciel ont été créées. Il a fallu trente et un mois pour les produire et huit personnes y ont travaillé. Cela signifie que chaque membre de l'équipe a produit mille lignes de code par semaine. C'est le travail le plus rapide jamais réalisé par une équipe. (voir Article de Jim Coplien pour plus de détails)
L'un des éléments de la "sauce secrète" de l'équipe Borland était que tous les membres de l'équipe se réunissaient chaque jour pour discuter de leurs performances. Réunir tout le monde dans une salle était essentiel, car cela permettait à l'équipe de s'auto-organiser en fonction des défis à relever. Si quelqu'un était bloqué par un problème - si l'accéléromètre ne communiquait pas avec l'altimètre - tout le monde voyait que cet obstacle pouvait bloquer l'ensemble du sprint, et ils s'y attaquaient en masse, s'assurant que le problème était résolu pronto.
Chez Borland, la réunion quotidienne durait au moins une heure. Cela m'a semblé trop long. J'ai donc examiné les éléments essentiels qui doivent être communiqués lors de cette réunion et j'ai formulé les trois questions suivantes.
C'est ainsi que la réunion quotidienne a commencé à fonctionner. Nous avions certaines règles. La réunion avait lieu tous les jours à la même heure et tout le monde devait être présent. Si toute l'équipe n'était pas présente, la communication n'avait tout simplement pas lieu. L'heure de la réunion importait peu, du moment qu'elle avait lieu tous les jours à la même heure. Il s'agissait de donner à l'équipe un rythme régulier.
La deuxième règle était que la réunion ne devait pas durer plus de quinze minutes. Nous voulions qu'elle soit claire, directe et qu'elle aille droit au but. Si un point nécessitait une discussion plus approfondie, nous en prenions note et nous nous réunissions à nouveau après la réunion quotidienne. L'idée était d'obtenir les informations les plus exploitables et les plus précieuses en un minimum de temps.
La troisième règle était que tout le monde devait participer activement. Pour y parvenir, j'ai dit que tout le monde devait se lever. De cette façon, il y aura des discussions et des écoutes actives. Cela permet également de raccourcir la durée des réunions.
C'est la raison pour laquelle une telle réunion est souvent appelée "Daily Standup" ou "Daily Scrum". Peu importe le nom que vous lui donnez. Elle doit avoir lieu tous les jours à la même heure, poser les trois mêmes questions et ne pas durer plus de quinze minutes.
Le problème que je vois souvent surgir est que les gens ont tendance à considérer le Daily Scrum comme un simple rapport individuel. "J'ai fait ceci, je ferai cela. Je vais faire ça", puis on passe à la personne suivante. L'approche la plus optimale est plus proche d'une réunion de football. Un grand receveur peut dire : "J'ai un problème avec ce joueur de ligne défensive", ce à quoi un bloqueur offensif peut répondre : "Je m'en occupe, je vais ouvrir cette ligne". Je vais ouvrir cette ligne". Le quarterback peut aussi dire : "Notre jeu de course se heurte à un mur ; surprenons-les avec une passe sur la gauche". L'idée est que l'équipe se concerte rapidement sur la manière d'avancer vers la victoire, c'est-à-dire de terminer le sprint. La passivité n'est pas seulement de la paresse, elle nuit activement aux performances du reste de l'équipe. Une fois repérée, elle doit être éliminée immédiatement.
Je veux des équipes agressives - des équipes qui sortent de la réunion quotidienne en sachant quelle est la chose la plus importante qu'elles doivent accomplir ce jour-là. Une personne peut entendre une autre dire qu'une tâche lui prendra une journée, mais un autre membre de l'équipe peut savoir comment la réaliser en une heure s'ils travaillent ensemble. Je veux que les équipes sortent de cette réunion en disant des choses telles que : "On va faire ça, on va faire ça". Faisons-le." L'équipe doit avoir envie d'être géniale.
Le discours que je tiens habituellement aux équipes, grandes et petites, est le suivant : "Voulez-vous vraiment être nuls pour toujours ? C'est ce qui vous motive dans la vie ? Parce que c'est un choix, vous savez, vous n'êtes pas obligés d'être comme ça". Une équipe doit exiger d'elle-même qu'elle se surpasse.
Chez Easel, avec la première équipe Scrum, nous avons mis en œuvre le Scrum quotidien au cours du troisième Sprint. Nous avions planifié quatre semaines de travail pour ce Sprint, soit à peu près la même charge de travail que le mois précédent. Nous avons tout terminé en une semaine. Une amélioration de 400 %. Ce premier vendredi, toute l'équipe s'est regardée et a dit "Wow". C'est à ce moment-là que j'ai su que j'étais peut-être sur la bonne voie.
Pré-commande Scrum:L'art de faire deux fois plus de travail en deux fois moins de temps de Amazon, BN, iTunesou Relié à l'unité.
French 
English 
Spanish