Scrum "Shock Therapy" Comment changer d'équipe RAPIDEMENT

Alors qu'il mettait à jour son article pour Scrum "Shock Therapy", Scott Downey de Rapid Scrum J'ai trouvé l'un des courriels originaux qu'il a écrit sur la façon dont il a stimulé des douzaines d'équipes à l'hyper productivité. Il commente ci-dessous et l'article complet a été publié sous le titre :

J. Sutherland, S. Downey, et B. Granvik, "Thérapie de choc : Un tremplin pour une Scrum hyperproductive"dans Agile 2009, Chicago, 2009.

Jeff sera présent à Agile 2012 à Dallas et à sur l'hyperproductivité le jeudi 16 août à 9h30.

1. Augmentation de la vitesse d'au moins 240%
2. Ils ont réalisé trois sprints consécutifs réussis
3. Ils ont identifié une bonne raison commerciale de commencer à modifier les règles.

Mes règles initiales sont à peu près les suivantes :

Tous les membres de l'équipe participeront à une session de formation Scrum.
J'organise un cours d'introduction à Scrum très condensé et toute l'équipe se réunit pour une seule session. Tant que tout le monde n'a pas été formé, nous ne commençons pas notre premier Sprint.

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 :

Ingénieur : "Mais je ne peux rien faire en une semaine !"

Scott : "Le calcul simple suggère que vous ne pouvez faire que quatre choses en 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.

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 :

• Fonctionnalité complète
• Code complet
• Aucun défaut connu
• Approuvé par le Product Owner
• Prêt pour la production

Toutes les estimations seront exclusivement exprimées en Story Points.
Quel que soit le modèle Scrum que vous allez suivre, les Story Points sont un élément clé. Certains auteurs recommandent d'utiliser les Story Points uniquement pour l'estimation du Backlog de produit, mais exigent que vous passiez à des estimations basées sur les heures lors de la construction du Backlog de sprint. Personnellement, ayant appris que les estimations basées sur les heures sont erronées par un facteur de 50% ou plus, je ne veux jamais d'une unité aussi inexacte et facilement abusive dans mes mesures.

Mais mon raisonnement va plus loin.

Puisque vous devez apprendre à utiliser les Story Points un jour ou l'autre - ne serait-ce que pour le Backlog de produit - il est logique que plus vous vous exercez, plus vous apprenez vite. Ainsi, en limitant tous les votes et toutes les estimations à l'échelle des Story Points, les équipes apprennent rapidement à utiliser ce nouveau mécanisme de catégorisation rapide du travail.

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. J'ai alors 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. Comme l'humeur de l'équipe se détend, certaines équipes commencent à scanner les autres votes et à s'applaudir 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.

Nous utiliserons un radiateur d'information physique.
Non seulement j'insiste sur l'existence d'un radiateur d'information physique, mais j'arrête également toute utilisation de logiciels de gestion de projet et d'outils de gestion du carnet de commandes. Je veux que mes équipes fassent l'expérience physique et tactile du processus de démarrage afin que, même si les cartes deviennent électroniques par la suite, elles puissent toujours sentir et imaginer le flux de ce qui se passe.

J'ai un modèle de base que j'utilise initialement pour toutes les équipes. Il comprend quatre colonnes qui sont dessinées pour être de la largeur exacte des cartes d'histoires d'utilisateurs que nous utilisons (pour éviter de créer des rangées de cartes dans un seul couloir de nage). Les colonnes sont "Product Backlog", "Sprint Backlog", "In Progress" et "Done". On se plaint généralement que le tableau ne permet pas à l'équipe de représenter suffisamment d'"états" (conception, codage, code terminé, tests, tests terminés, correction de bogues, etc.)

C'est l'occasion idéale d'expliquer à l'équipe le véritable objectif du tableau, qui est de servir de radiateur d'information pour les non-membres de l'équipe. Il est là pour refléter ce que l'équipe sait d'une carte. Il ne s'agit pas d'un outil de communication entre les membres de l'équipe, de sorte que les déclarations qui n'ont pas de sens pour les observateurs externes n'ont pas leur place sur le tableau.

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, je la laisse se concentrer sur l'interaction avec ses coéquipiers (les trois questions d'accomplissement, plus ma quatrième question décrite dans le document Scrum Metrics for Hyper Productive Teams d'Agile 2010) 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 à assouplir mes exigences.

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.

En l'espace de quelques semaines, la plupart des équipes n'ont besoin que de quelques heures pour tout réaliser. Et à la fin d'environ huit sprints, les réunions ne durent plus que quatre-vingt-dix minutes, voire moins, pour un sprint d'une semaine.

Mon programme initial est le suivant :

DémonstrationsL'équipe montre à la Product Owner le travail qu'elle a accompli et reçoit des points d'histoire en fonction de sa précision.

Les 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 nombreuses mesures, je me concentre uniquement sur la vélocité, le burndown, la capacité de travail et la précision de l'engagement.

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 toutes les User Stories mal formées au nom de l'équipe, mais je m'efforce toujours de rencontrer le Product Owner avant cette réunion, d'examiner son travail et de lui donner une chance de corriger ses erreurs avant que la réunion ne soit ouverte.

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 pendant cette phase de la réunion, mais ne vote jamais et n'essaie pas d'influencer les estimations.

Au cours de cette phase, je passe le plus clair de mon temps à 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. Dès qu'une carte passe les six contrôles INVEST, nous arrêtons de la décomposer, nous l'estimons et nous nous mettons au travail.

Engagement dans le Backlog de Sprint est l'acte final de cette Ubermeeting. Au cours des premiers sprints, je lis littéralement à haute voix ce que "Commit" signifie et ne signifie pas, afin qu'il n'y ait aucun doute dans l'esprit de quiconque. Une fois que l'équipe s'engage sur le travail, la réunion est levée.

Pendant le sprint, il est interdit de faire plusieurs choses à la fois. Le travail doit être traité et achevé 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. Ils n'apprécient pas que je leur fasse remarquer qu'un travail incomplet n'a aucune valeur - mais je le fais. Souvent.

J'insiste pour qu'ils travaillent sur les cartes sans faire plusieurs tâches à la fois et en respectant l'ordre des priorités. Cela donne parfois lieu à des protestations pétaradantes, les gens restant inactifs, mais ils font moins de dégâts dans ce mode que lorsqu'ils ont les mains dans neuf projets, dont aucun ne sera mené à bien.

J'ai également des modèles standard que j'utilise pour les tableaux de planification de sprint initiaux, les histoires d'utilisateurs, les cartes d'histoires, les tableaux d'épuisement et le suivi de la vélocité.

Comme je l'ai dit au début, j'essaie d'obtenir tout cela avec un sourire amical et un "s'il vous plaît", mais je dois généralement insister - parfois avec beaucoup de force - pour les faire bouger. Bien que les débuts soient difficiles, nous commençons généralement à rire et à nous amuser lors des réunions au bout d'une semaine. Et au fur et à mesure qu'ils se concentrent sur Scrum et deviennent plus compétents, je relâche rapidement mon emprise sur certaines règles et je les laisse réorganiser leur environnement à leur guise - tant qu'ils continuent à respecter les principes de Scrum. Mon objectif est toujours de me retirer des projecteurs, de redonner le contrôle à l'équipe et de devenir un conseiller dont la participation n'est pas nécessaire à la réussite de l'équipe.

Les trois principales raisons pour lesquelles je pense que cette approche est couronnée de succès sont les suivantes :

• Je trouve le plus gros problème de l'équipe et je le résous dans un délai d'un jour ou deux après la première réunion de planification, si cela est possible. 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 disparition 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.

• Comme je suis le chef de la pratique agile pour l'ensemble de l'entreprise, je ne suis jamais le Scrum Master permanent d'une nouvelle équipe. Cela me donne la liberté de créer un peu (mais très peu) d'atmosphère "Nous contre Lui" au début. Cela permet à l'équipe de tisser des liens d'une manière souvent totalement différente de celle qu'elle a connue jusqu'à présent, et de préparer son Scrum Master permanent à jouer le rôle de "bon flic" par la suite. Cela me permet 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 quelques semaines, alors qu'elle fonctionne très bien et se situe (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.

• 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 ou la plus résistante 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 je n'interrompe la réunion et que je ne 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 formation immersive 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é.

C'est un choc culturel assez important pour la plupart des équipes et il n'y a pas beaucoup d'invitations amicales à déjeuner au début. Mais, d'après les commentaires de mon vice-président de l'ingénierie, ils ne "...détestent [moi] que pendant 2 ou 3 semaines. Ensuite, ils sont indifférents à [moi] pendant encore quelques semaines. Ensuite, ils crient au meurtre s'il essaie de les éloigner de moi".

Je reste en contact avec les équipes que j'ai lancées de cette manière et, à une exception notable près, elles ont toutes continué à s'améliorer en mon absence, ce qui a toujours été mon objectif.

J'espère que certains de ces éléments vous seront utiles lorsque vous tenterez d'amener vos équipes à des performances optimales dans le cadre du programme Scrum.

Scott Downey
Propriétaire, RapidScrum.com
Scott@RapidScrum.com