Thérapie de choc : L'amorce d'une hyperproductivité Scrum

1. Tous les membres de l'équipe participeront à une session de formation Scrum.
   J'effectue un travail extrêmement condensé Scrum sur MySpace La formation se déroule en quatre heures environ, et toute l'équipe se réunit pour une session. Tant que tout le monde n'aura pas été formé, nous ne commencerons pas notre premier Sprint.
2. Les sprints dureront une semaine.
   Je justifie cela en soulignant qu'il y a une raison pour laquelle les généticiens étudient les mutations chez les drosophiles plutôt que chez les éléphants - ils veulent voir les mutations rapidement et adapter leurs études en conséquence. Les équipes détestent généralement cette partie autant ou plus que tout ce que je leur demande, mais j'ai réussi à convaincre toutes les équipes de me donner au moins quatre sprints d'une semaine à titre d'essai. Voici un de mes échanges préférés qui revient presque toujours - n'hésitez pas à l'utiliser :
   Ingénieur : "Mais je ne peux pas faire n'importe quoi dans une semaine !"
   Scott : "Le simple calcul suggère que vous ne pouvez faire que quatre rien dans un mois".

   Il est intéressant de noter qu'au moment où les équipes ont rempli les trois critères de modification de cette règle, une seule d'entre elles a choisi de la modifier.

3. Ils commenceront par utiliser ma définition du terme "Fait".
   C'est souvent l'une des questions les plus épineuses à résoudre avec une équipe, aussi je la retire de la table jusqu'à ce qu'ils aient une réussite commune comme base. Ma définition initiale de "Fait" est la suivante :

1. Prêt pour la production
1. Toutes les estimations seront exclusivement exprimées en Story Points.
   Encore une fois, cette question est parfois accueillie par un roulement cérémonieux des yeux mais - jusqu'à présent, en tout cas - ils ont tous fini par s'y faire. C'est généralement vers la troisième semaine que je peux intentionnellement déclencher un débat sur la question de savoir si une carte est un 3 ou un 5, puis j'ai le plaisir de leur faire remarquer la passion avec laquelle ils débattent de ces valeurs récemment dépourvues de sens. Je me fais également un devoir de crier "BA !" lorsqu'ils votent tous la même valeur pour une carte donnée. Mon intention est de leur montrer à quel point ils sont souvent d'accord dans leur vote. Lorsque l'humeur de l'équipe se détend, certaines équipes commencent à scanner les autres votes et à "baa" comme des moutons lorsque cela se produit. Une seule équipe a répondu à mon "Ba" par un "Humbug". Quoi qu'il en soit, ils commencent tous à s'amuser et c'est important.
2. Nous utiliserons un radiateur d'information physique.
   Non seulement j'insiste pour qu'il y ait un radiateur d'information physique, mais j'ai un modèle de base que j'utilise initialement pour toutes les équipes. Je choisis unilatéralement l'emplacement du tableau Scrum et l'utilise comme point central de la réunion quotidienne. Lorsque l'équipe est formée pour la première fois, je la laisse se concentrer sur l'interaction avec ses coéquipiers (les trois questions sur les réalisations) et je déplace moi-même ses cartes sur la surface du radiateur. Au bout de quelques semaines, ils commencent à déplacer eux-mêmes les cartes sans qu'on le leur demande. C'est généralement la première indication que je peux commencer à prendre du recul et à relâcher mes exigences.
3. Les réunions de planification du sprint dureront quatre heures, une fois par semaine.
   La première plainte de la plupart des ingénieurs est qu'ils ont l'impression que le Scrum leur impose un emploi du temps très perturbant, avec plus de réunions qu'ils ne pensent en avoir jamais eues auparavant. Pour minimiser cette inquiétude, je regroupe toutes les réunions, à l'exception des réunions quotidiennes, en une seule réunion de quatre heures. Au bout de quelques semaines, les équipes n'ont généralement besoin que de quelques heures. Et à la fin d'environ huit sprints, les réunions ne durent plus que quatre-vingt-dix minutes ou moins pour un sprint d'une semaine. Mon ordre du jour initial est le suivant :
   1. Démonstrations où l'équipe montre à la Product Owner le travail qu'elle a accompli et reçoit des points d'histoire en fonction de sa précision.
   2. La rétrospective vient ensuite, aidé par une foule de mesures que je suis. Je ne suis que les indicateurs de l'ensemble de l'équipe, jamais les indicateurs individuels. Au départ, bien que je publie de nombreux indicateurs, je me concentre uniquement sur les éléments suivants Vitesse, combustion, capacité de travail et Engagement Précision.
   3. Présentation du carnet de commandes L'équipe est libre de remettre en question les motifs, de proposer des alternatives et d'ajouter des exigences à ce moment-là. L'équipe est libre de remettre en question les motifs, de suggérer des alternatives et d'ajouter des exigences à ce stade. Je rejette toute User Story mal formée au nom de l'équipe.
   4. Estimation et négociation signale que la réunion est presque terminée. Elles se déroulent en une seule fois dans mes nouvelles équipes, bien que les équipes plus matures choisissent éventuellement de diviser ces activités en réunions uniques. Le Product Owner ne joue qu'un rôle consultatif durant cette phase de la réunion. Je passe le plus clair de mon temps dans cette phase à essayer d'empêcher les équipes de décomposer inutilement les Story Cards en séquences de tâches, ce que certaines d'entre elles ont tendance à faire. Le moyen mnémotechnique INVEST est très utile à cet égard.
   5. Engagement dans le Backlog de Sprint est l'acte final de la réunion de planification. Au cours des premiers sprints, je lis littéralement à haute voix ce que signifie et ne signifie pas "s'engager" afin qu'il n'y ait aucun doute dans l'esprit de quiconque. Une fois que l'équipe s'est engagée à travailler, la réunion est levée.
4. Il est interdit de faire plusieurs choses à la fois. Le travail doit être effectué par ordre de priorité.
   Certains ingénieurs le comprennent immédiatement. D'autres se sentent plus productifs ou épanouis lorsqu'ils ont plusieurs projets en cours et ils n'apprécient pas que je leur fasse remarquer qu'un travail incomplet n'a aucune valeur - mais je le fais. Et souvent. J'insiste sur le fait qu'ils doivent travailler sur des cartes sans faire plusieurs tâches à la fois et en respectant l'ordre des priorités.

1. Je trouve le plus gros problème de l'équipe et je le résous dans le jour ou les deux jours qui suivent la première réunion de planification. Certaines équipes me soumettent rapidement ce problème lors de leur première rétrospective, tandis que d'autres ont besoin d'observation, d'écoute attentive et de reconnaissance en coulisses pour le découvrir. En particulier pour les équipes qui n'ont pas encore travaillé directement avec moi, la résolution de ce très gros problème souligne qu'elles sont importantes pour moi, que je les prends au sérieux et que je m'efforce de rendre leur monde meilleur.
2. Comme je suis le maître évangéliste Scrum Master/Scrum pour l'ensemble de l'entreprise, je ne suis presque jamais le Scrum Master permanent d'une équipe donnée. Cela me donne la liberté de créer un mors (mais très peu) de l'atmosphère "Nous contre Lui" au début. Cela permet à l'équipe de tisser des liens d'une manière totalement différente de ce qu'elle a connu jusqu'à présent, et cela permet également à leur Scrum Master permanent d'être le "bon flic" à l'avenir. Cela me permet également d'être plus ferme sur le fait de rester debout pendant le Stand-Up, de garder vos estimations privées jusqu'à ce que le vote soit appelé pendant l'estimation, etc. Si l'on garde à l'esprit que je dois généralement tirer ma révérence et passer à une autre équipe au bout de 6 à 12 semaines, alors qu'elles fonctionnent très bien et se situent (en moyenne) autour de la barre des 500%, la plupart des équipes tolèrent très bien cette situation et prennent de bonnes habitudes plus rapidement - même si cela me donne l'impression d'être un peu le maître d'école.
3. Je pense que Socrate avait raison. Lorsque je vois que quelque chose ne va pas - par exemple, quelqu'un qui s'assoit pendant le Daily Stand-Up - je ne m'adresse pas toujours directement à l'auteur de la transgression. Au lieu de cela, il m'arrive d'interrompre la réunion et de demander à l'équipe : "Équipe, l'un d'entre vous voit-il quelque chose qui ne va pas dans notre réunion en ce moment ?" Ironiquement, c'est presque toujours la personne la plus sceptique qui est la première à corriger le coéquipier insolemment perché. Bientôt, ils commencent à s'interpeller les uns les autres sur le fait de s'appuyer ou de s'asseoir bien avant que j'arrête la réunion et que je demande ce qui ne va pas. Cela les aide à commencer à se contrôler eux-mêmes, de sorte que je n'ai pas toujours besoin d'être là pour les inciter à bien se comporter.

C'est à peu près de cette manière que j'ai conduit des équipes à l'hyperproductivité en seulement quatre semaines, et c'est pourquoi l'un de mes collègues m'appelle "l'homme qui murmure à l'oreille des Scrum". J'ai une équipe qui a atteint 1 650% de contribution à la valeur ciblée supérieure par semaine après seulement quatre mois (16 sprints) de collaboration. Nous sommes très fiers de ces chiffres. J'ai également remarqué que les équipes qui utilisent cette approche de "format rapide" ont tendance à atteindre leur coude de vélocité beaucoup plus tôt, ce qui donne à Product Owners une vision plus large et plus stable de la feuille de route que les équipes qui utilisent des sprints plus longs ou qui passent leur période inaugurale à réfléchir à l'endroit où elles veulent que leur tableau Scrum soit situé.