Les poulets et les cochons
Auteur : Steve Porter
Source : Chickens and Pigs (Scrum.org)
Date : 12/08/2011
Traducteur : Fabrice Aimetti
Date : 12/08/2011
Traduction :
La tradition du poulet et du cochon dans Scrum ne fait plus partie du Guide Scrum. Steve Porter, Professional Scrum Trainer, discute de la signification de ce que certains peuvent supposer être un changement relativement anodin :
Comme vous le savez probablement, Jeff Sutherland et Ken Schwaber ont récemment publié une mise à jour du Guide Scrum, le guide de référence pour Scrum. Beaucoup des changements qu'ils ont apportés visaient à mieux définir les règles du jeu, et supprimer les tactiques liées au contexte. Certains changements ont un impact fort et d'autres moins apparent.
Un changement particulier a justement sans aucun doute semblé petit et cosmétique, mais il est vraiment porteur de sens à mon avis.Tellement, que j'ai proposé d'écrire ce bref article et d'expliquer pourquoi ce changement a été fait et comment vous pouvez interpréter ce changement lorsque vous le mettez en œuvre dans vos projets.
Chaque pratiquant Scrum a entendu la fable du poulet et du cochon. Je ne vais pas la raconter ici, mais cela fait partie intrinsèque de la tradition Scrum. Ken Schwaber a créé la métaphore du cochon et du poulet dans les grands débuts de Scrum et elle a été utilisée à plusieurs reprises pour séparer les gens qui sont engagés dans le projet des gens qui sont simplement impliqués.
Au fil des années, ces étiquettes ont généré leur part de controverse. Certains soutiennent que ces termes sont nuisibles au processus parce que dénigrants. D'autres disent que cette connotation négative conjure une dynamique de pouvoir qui génère un comportement négatif. De toute façon, vous ne trouverez aucune référence à des animaux, de basse-cour ou autres, dans le nouveau Guide Scrum.
Pourquoi cela a-t-il été enlevé ? Ken et Jeff ont estimé qu'il était préférable de parler directement de responsabilité dans le Guide Scrum, au lieu de passer par une métaphore. Cependant, je pense que je peux formuler une idée supplémentaire. J'ai assisté à certaines des discussions qui ont conduit à la mise à jour 2011 et beaucoup de gens, moi y compris, ont constaté que ces étiquettes ont été utilisées d'une manière qui ne contribue pas de façon positive à la capacité qu'une équipe a de remplir son rôle de base.
Ces étiquettes ont été utilisées pour créer des barrières entre l'équipe Scrum et des individus de l'organisation qui peuvent éventuellement aider l'équipe à atteindre ses objectifs. Jeff Sutherland a été cité : "...d'autres arrivent avec un euphémisme pour trouver un bon équilibre entre être "gentil" et communiquer clairement que les oreilles indiscrètes doivent minimiser leur impact sur la productivité de l'équipe".
En tant que consultant, j'ai été témoin d'une scène où de nombreux membres importants d'une organisation se sont mis eux-mêmes à l'écart d'une équipe Scrum avec des commentaires tels que "Je sais que je suis juste un poulet, donc je ne peux rien dire". Dans certains cas, ces personnes étaient des promoteurs importants du projet ou de véritables experts du système. Ce sont des individus qui, tout en pouvant avoir besoin d'une certaine formation et de conseils d'un Scrum Master, peuvent être essentiels à la réussite d'un projet. Meilleur est le niveau d'engagement que vous obtenez de l'ensemble de vos intervenants, meilleur votre projet sera. En appelant quelqu'un un poulet, cela ne ressemble pas exactement à dérouler le tapis rouge.
Un autre point à considérer est que Scrum, en tant que framework pour livrer des produits, a parcouru un long chemin. Il est maintenant utilisé dans toutes sortes d'organisations, y compris les grandes entreprises. Je me réjouis de ce développement parce que je pense qu'il y a un grand potentiel pour améliorer les environnements de travail des professionnels du développement dans ces organisations par l'utilisation de Scrum. Si nous voulons être pris au sérieux dans ces types d'organisations, nous devons nous assurer que nous pouvons communiquer efficacement avec les différentes parties prenantes avec lesquels nous nous engageons. Je me réjouis de relever le défi de travailler avec un dirigeant d'entreprise classé dans les 100 premières fortune pour l'aider à créer des produits de la plus haute valeur métier possible.Je ne veux pas commencer cette relation en le considérant comme une volaille avec un petit cerveau et moi comme un animal qui s'est emparé de la ferme des animaux de George Orwell.
Alors, à quoi vous amène ce changement ? Heureusement, la mise à jour du Guide Scrum fait toujours une distinction entre les membres de l'équipe Scrum et ces individus qui font partie du processus, mais qui ne sont pas responsables de la fabrication des produits. Mais la terminologie a été modifiée. Nous avons encore l’Équipe Scrum, mais maintenant le guide fait référence à "l'organisation", aux "employés" et aux "parties prenantes" plutôt qu'à des cochons et des poulets.
La mise à jour du guide clarifie également que "Personne (pas même le Scrum Master) n'explique à l’Équipe de Développement comment transformer le Backlog Produit en Incréments de fonctionnalités potentiellement déployables". Pour tous ces Scrum Masters qui ont à traiter des parties prenantes qui font de l'ingérence, imprimez le nouveau guide, mettez en évidence les passages appropriés et mettez-leur à disposition le plus tôt possible et souvent.
