It occurred to me one day that Scrum Teams are the customers of the Scrum Master. If we don’t already know it, Scrum teaches us that customers of our enterprise don't really know what they want until they have seen it, or at least something to define what they don’t want. So why would we expect Scrum Teams to know how to set up, for example, their Sprint Planning Meetings if they haven't seen a working prototype?
Cette approche a été documentée dans la présentation Agile 2009 intitulée "Shock Therapy" (disponible à l'adresse http://www.rapidscrum.com/resources.php), coécrite par Jeff Sutherland et Bjorn Granvik.
Lorsque je rejoins une équipe en tant que Scrum Master, j'établis quelques règles non négociables (avec douceur si possible, avec fermeté si nécessaire). Ces règles restent en vigueur jusqu'à ce que l'équipe ait rempli trois critères :
- Augmentation de la vitesse d'au moins 240%
- Ils ont réalisé trois sprints consécutifs réussis
- 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.
Again, this one is sometimes met with a ceremonial rolling of the eyes but – so far, anyway – they have all eventually come around to this. It's usually at about week three when I can intentionally spark a debate over whether a card is a 3 or a 5, then have the pleasure of pointing out to them the passion with which they are debating these recently-meaningless values. I also make a point of shouting "BA!" whenever they all vote the same value for a given card. My intent is to show them how often they actually agree in their vote. As the mood on the team lightens up, some teams begin scanning the other votes and cheering themselves when that happens. Only one has returned my "Ba!" with a "Humbug!" In any event, they all start having fun with it and that's 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.
I have a basic template that I use initially for all teams. It includes four columns that are drawn to be the exact width of the User Story cards we use (to prevent creating rows of cards in a single swim lane). The columns are “Product Backlog”, “Sprint Backlog”, “In Progress” and “Done.” This is usually met with complaints that the board doesn’t allow the Team to represent enough “states” (Design, Coding, Code Complete, Testing, Test Complete, Bug Fix, etc.). This is the perfect chance to educate the Team about the true purpose of the Board as an Information Radiator to non-Team members. It is there to reflect what the Team knows about a card. It is not a communication tool between Team members, so any states that are meaningless to external observers are not appropriate on the board.
I choose the location of the Scrum Board unilaterally and use it as the focus of the Daily Stand-Up Meeting. When the team is first formed, I let them focus on the interaction with their teammates (the three Achievement questions, plus my Fourth Question described in Scrum Metrics for Hyper Productive Teams paper from Agile 2010) and I move their cards across the Radiator's surface myself. Within a couple of weeks, they start moving cards themselves without having been asked. This is usually my first indication that I can begin slowly stepping back and relaxing my demands.
Les réunions de planification du sprint dureront quatre heures, une fois par semaine.
The first complaint of most Engineers is that they perceive Scrum imposing a highly disruptive schedule on them, with more meetings than they somehow think they have ever had before. To minimize this common concern, I consolidate everything but the Daily Stand-Up meetings into a single, four-hour meeting. Within a few weeks, most Teams only need a couple of hours to achieve it all. And by the end of about eight Sprints together, the meetings are becoming ninety minutes or less in duration for a one week Sprint.
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 signals that the meeting is nearly complete. They happen in a single motion with my new teams, though more mature teams eventually choose to split these activities into unique meetings. The Product Owner participates in an advisory role only during this phase of the meeting but never votes or tries to influence the estimates. I spend most of my time in this phase trying to keep the teams from unnecessarily breaking Story Cards down into task sequences, which some tend to do. The INVEST mnemonic is really handy here. As soon as a card passes all six INVEST checks, we stop breaking it down, estimate it and get to work.
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é.
Some Engineers understand this right away. Others feel most productive or fulfilled when they have multiple projects in progress. They don't appreciate my pointing out that there is no value in incomplete work – but point it out, I do. Often. I insist and enforce that they work on cards without multi-tasking and in priority order. Sometimes this leads to petulant protests with people sitting idle but they’re doing less damage in that mode than with their hands in nine projects, none of which will be done.
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.
This is roughly how I have driven teams into hyper-productivity in as few as four weeks, and why one of my co-workers calls me "The Scrum Whisperer." I have one team that has achieved 1,650% higher targeted value contribution per week after just four months (16 Sprints) together. We are pretty proud of those numbers. I've also noticed that teams using this immersive training approach tend to hit their Velocity elbow much sooner, giving Product Owners a greater and more stable view of the roadmap than teams who use longer Sprints or spend their inaugural period hashing out where they want their Scrum Board to be located.
It's a fairly large culture shock for most teams and doesn't yield a lot of friendly lunch invitations at first. But, per feedback from my VP of Engineering, they only “…hate [me] for about 2-3weeks. Then they're indifferent to [me] for another few weeks. Then they scream bloody murder if [he tries] to take [me] away from them." I do stay in touch with teams that I've kick-started like this and, with one notable exception, they have all continued their trend of improvements in my absence, which was always my goal.
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
French 
English 
Spanish