Qu'est-ce que Scrum et pourquoi votre équipe devrait-elle l'évaluer ?

Partager!

Scrum est en vogue et il est impossible de nier l'influence qu'il exerce sur tous les modèles de gestion et de travail en équipe. Ce "modèle" est le protagoniste d'une transformation à l'échelle mondiale. Si la pandémie a accéléré la transformation organisationnelle, Scrum est le carburant qui alimente des centaines de milliers d'équipes distantes et virtuelles dans le monde.

Mais qu'est-ce que Scrum et pourquoi est-il si célèbre ?

Dans le contexte de la gestion, Scrum a été créé au début des années 1990. Cependant, il a fallu près de deux décennies pour que la première version du Guide officiel soit publiée, ce qui est, comme nous autres geeks le dirions, le modèle canonique d'aujourd'hui.

Les parents de Scrum sont Jeff Sutherland et Ken Schwaber. Et sa vision a évolué au fil des ans. Pour beaucoup, il est donc difficile de définir ce qu'est Scrum - une méthode ? un modèle ? un processus ? ou une méthodologie ?

Méthodologie ou processus Scrum ?

Puces de couleur Lego
Avez-vous des jetons préférés, et y en a-t-il que vous utilisez toujours ? C'est votre cadre de travail

Scrum est un cadre - un cadreEt qu'est-ce que cela signifie d'être un cadre ? Prenons un exemple de ce qu'est un cadre. Un des exemples que j'aime bien.

Imaginez que vous êtes un fan de LEGO® et que vous avez acheté une boîte de jetons LEGO®. Mais vous décidez de ne pas suivre les instructions et de créer votre propre modèle. Mode créatif, comme diraient les joueurs de Minecraft.

Lorsque vous êtes en mode créatif avec vos jetons, vous pouvez avoir une préférence pour quelques jetons qui servent toujours de base à vos modèles. Ces jetons fondamentaux, qui sont la base de modèles plus complexes, on pourrait les appeler : cadre de travail o cadre.

Scrum : un ensemble de base

Scrum est un ensemble de "règles de base" qui comprend :

  • Événements - un ensemble d'activités que certains "innovateurs du mot" appellent des cérémonies ou des rituels.
  • Artefacts - des outils et instruments tels que le Backlog Backlog de produit et Backlog d'itération, ou la définition de l'achèvement - la définition de fait
  • Rôles - où sont décrits les fameux Scrum Master et Product Owner.

Cet ensemble de base constitue un terrain fertile pour l'incorporation de nouvelles pratiques ou l'extension du modèle. Et c'est là que réside le succès de Scrum et la raison pour laquelle il est si célèbre. Scrum est simple, direct et léger. C'est son plus grand avantage - et sa plus grande faiblesse.

Si votre équipe structure bien ce qu'elle construit en plus de Scrum, elle réussira. Si votre équipe ne structure pas bien la manière d'étendre le cadre, elle sera sûrement confrontée à de nombreux problèmes qui vous feront penser à abandonner la voie.

Que sont les sprints ?

Avant de parler des événements Scrum, il est bon de parler du concept de sprint. Et, bien que Scrum ne soit pas un processus normatif, il propose un modèle de gestion basé sur les sprints.

Les sprints sont des périodes de temps courtes et de durée déterminée - pas plus de 4 semaines. Ces cycles sont appelés itérations dans d'autres modèles de gestion. Dans de nombreux cas, les gens utilisent ces termes de manière interchangeable.

Les sprints doivent toujours avoir la même durée. Au fil des ans, la recommandation concernant la durée des sprints est devenue de plus en plus courte. Il n'y a pas si longtemps, des cycles de 2 à 8 semaines étaient recommandés. Aujourd'hui, la recommandation est qu'un Sprint doit durer de 1 à 4 semaines.

Si vous utilisez Scrum, vos sprints doivent toujours avoir la même longueur. En d'autres termes, vous ne devriez pas avoir des sprints d'une semaine, des sprints de 4 semaines et des sprints de 2 semaines.

Cycle de Scrum

Diagramme du cycle de Scrum - par Alberto Dominguez

Le modèle définit une séquence répétitive d'événements. sprint a sprint. Ce cycle comprend :

  1. Planificationqui cherche à répondre aux questions :
    1. Quel est l'objectif de ce Sprint ?
    2. Comment espérons-nous atteindre cet objectif ?
  2. Suivi quotidienL'objectif est de garder l'équipe synchronisée et de répondre aux questions :
    1. Qu'avons-nous réalisé ?
    2. Sur quoi nous concentrons-nous maintenant ?
    3. Quels problèmes avons-nous ou quels risques anticipons-nous en tant qu'équipe ?
  3. Fermeture au niveau du produit. Cherche à répondre :
    1. Qu'avons-nous réalisé pendant le Sprint ?
    2. Ce que nous avons réalisé répond-il au besoin ou à l'objectif fixé ?
  4. Fermeture au niveau du processus. Répondez aux questions :
    1. Qu'avons-nous fait de bien en tant qu'équipe ?
    2. Que devons-nous ou pouvons-nous améliorer ?
    3. Quelles actions allons-nous entreprendre pour améliorer ou corriger les mauvaises habitudes en tant qu'équipe ?

Affinement du Backlog de produit

L'affinement de la arriéré de travail est une activité qui gagne du terrain au fil des ans. L'affinement du backlog était autrefois connu sous le nom de grooming.

Cependant, et je pense que cette activité - qui est souvent mentionnée avec le terme scrum - n'apparaît pas comme un événement officiel dans le cadre, par entêtement.

Je suis ouvertement contre le fait de ne pas l'expliciter comme un événement.

Exemple de Scrum : les événements du cycle comme un agenda

Comme je l'ai déjà dit, le cycle Scrum se répète à chaque sprint. Ainsi, si la durée de vos itérations est d'une semaine, ce cycle d'événements se répète chaque semaine. Si vos itérations durent deux semaines, vous pourriez avoir un calendrier similaire à celui-ci - il s'agit d'un exemple, à ne pas copier et coller avec toutes vos équipes et tous vos projets. Je suis sûr que cela vous aidera à avoir une idée de ce qui se passe.

Exemple d'un agenda avec des événements scrum pour un sprint de 2 semaines - par Alberto Dominguez

Types de Scrum

Bien qu'il n'existe qu'un seul Scrum canonique, il y a certainement plusieurs versions ou visions de ce cadre. Bien sûr, le plus accepté et le plus respecté est le Guide Scrum.

Mais je vous présente ici une grande partie de la littérature disponible - chacune avec sa propre version adaptée à Scrum - ce qui est un peu ce que je fais avec cet article. Ajoutez un peu de contexte et d'expérience, en essayant de ne pas enfreindre les règles de base - les piliers et les valeurs.

Guide officiel : modèle canonique

J'ai déjà parlé du Guide Scrum. Voici ses caractéristiques :

  1. Il est maintenu et mis à jour par les "parents" de Scrum.
  2. Il a été conçu à l'origine pour le développement de logiciels.
  3. Il s'agit de la version la plus populaire et la plus largement acceptée.
  4. C'est aussi la version la plus ambiguë et la moins restrictive. Cela peut conduire des équipes inexpérimentées, sans accompagnement adéquat, à s'égarer.

Corps de connaissances de Scrum : le plus détesté

Si le Guide officiel a la vision la plus large et la plus souple, le SBOK est tout le contraire. La société à l'origine de ce document (monstrueux) voulait imiter le PMBOK du PMI. Il a connu un grand succès il y a quelques années et ses certifications étaient très courantes. Aujourd'hui, avec l'arrivée d'autres acteurs encore plus douteux et moins stricts, elle a perdu beaucoup de terrain. Bien que je n'aime pas leur approche, j'admets que dans l'effort de structurer tout le travail il y a de la valeur et quelques solutions intéressantes aux défis de l'adoption de la méthodologie.

Scrum dans Scaled Agile Framework (SAFe)

SAFe est un cadre d'agilité à l'échelle. Sa proposition tente de remédier au fait que le cadre ne fait pas de choix concernant les efforts ou les structures organisationnelles d'autres tailles - 50, 70 ou 150 personnes.

Bien que SAFe ne décrive pas le cadre, il est évident qu'il apporte des modifications claires au modèle canonique.

Scrum @Scale

Une autre tentative - un peu simpliste à mon goût - de promouvoir Scrum au niveau organisationnel. L'une de ses principales critiques est qu'il s'appuie sur ce que le modèle sans échelle a tenté de discréditer. Inévitablement, l'échelle requiert une structure et une certaine bureaucratie.

Autres versions : certifications sans apport conceptuel

Je pourrais prétendre qu'il existe 1000 versions du framework. Ils sont presque tous associés à une "certification" dans l'un des rôles. Mais je peux vous assurer que derrière cet effort, il y a plus l'intention de faire de l'argent avec des cours et des certifications, que de contribuer réellement à la profession ou à l'exercice même des équipes qui adoptent Scrum.

Artefacts Scrum

Le cadre Scrum comporte très peu d'artefacts. Il est donc difficile d'"atterrir". Et, sans les connaissances et l'expérience nécessaires, cela peut conduire à la frustration de l'équipe qui ne sait pas comment en tirer le meilleur parti.

Vous trouverez ici une liste d'artefacts "officiels" et d'autres artefacts qui sont utilisés en plus du "jeu de base" et qui sont très populaires.

Backlog

Le backlog est une liste d'exigences classées par ordre de priorité. Contrairement aux autres structures de décomposition, le backlog est conçu pour supporter le mouvement et le dynamisme des exigences. Il est facile de gérer les changements, les nouvelles exigences et même les différents niveaux de détail.

Il existe deux types d'arriérés :

  1. Backlog de produit. Une version axée sur la valeur commerciale.
  2. Backlog du sprint. Une sorte d'enfant du backlog de produit qui, bien qu'orienté business, contient presque toujours beaucoup plus de détails et même des éléments orientés vers le développement ou la maintenance du produit - connus sous le nom de facilitateurs ou de tâches et sous-tâches.

Augmenter

L'incrémentalisme est un concept simple qui est très difficile à mettre en pratique. L'incrémentalisme est un "pas décisif" ou une "victoire concrète" dans le sens de la réalisation de l'objectif du produit.

Ainsi, si nous parlons de logiciel, il s'agit d'une version du produit qui est développée ou "évoluée" au cours du sprint et qui ajoute une portion de valeur claire et testable - n'oublions pas les piliers de scrum.

Mais qu'est-ce qu'un incrément si mon équipe ne développe pas de logiciels ? Eh bien, c'est là que le bât blesse. Comment structurer une feuille de route de haut niveau, orientée vers les gains rapides. Pas facile.

Définition du terme "achevé" - Définition de Done

Il s'agit d'une sorte de liste de contrôle que l'équipe de développement convient avec le Product Owner. L'objectif de cette liste de contrôle est similaire à celui de la visite de votre voiture chez le concessionnaire - ou dans un atelier officiel. Avant que vous puissiez récupérer votre voiture, ils vous donneront certainement une liste de contrôle sur laquelle toutes les étapes doivent être marquées comme terminées. Ainsi, ils savent qu'il est prêt à être "approuvé" par vous.

Définition de "prêt à travailler" - Définition de Ready

Il s'agit d'un artefact populaire, mais non officiel.

S'il existe une liste permettant de valider si un travail a été effectué. Il est également possible de définir une liste pour valider qu'un élément du backlog de produit est prêt à être évalué par l'équipe lors de la planification d'un sprint.

Histoires d'utilisateurs - Histoires d'utilisateurs

Histoires d'utilisateurs Ils ne sont PAS un artefact de la mêlée.. De plus, il n'y a AUCUNE obligation d'utiliser ce type d'outil comme élément du backlog - bien que beaucoup insistent sur le fait que si vous n'utilisez pas les user stories, vous n'êtes pas agile.

Malgré la croyance populaire, les user stories et scrum n'ont pas la même origine. Les US, comme on les appelle communément, ne sont pas une condition préalable à l'élaboration d'une user story. sine qua non d'avoir un backlog ou d'adopter le scrum. Autrement dit, vous pouvez adopter Scrum et ne JAMAIS utiliser les user stories.

Les récits d'utilisateurs sont des outils précieux en tant qu'artefact lorsque l'équipe tente de développer de nouveaux produits. Les histoires d'utilisateurs se concentrent sur la valeur de ce que je veux réaliser et non sur la portée de ce que je veux réaliser.

Commençons par un exemple. Commençons par un peu de contexte.

Alberto est un travailleur dévoué et engagé. Cela fait un certain temps qu'Alberto n'a pas pris de vacances. Par conséquent, il a décidé de prendre quelques jours pour se reposer avec sa famille.

Exigence orientée vers la portée - Exigence orientée vers la portée - Exigence orientée vers la portée - Exigence orientée vers la portée - Exigence orientée vers la portée - Exigence orientée vers la portée portée

Nous avons un contexte qui pose un besoin. C'est fondamental, et je vais rédiger une exigence qui cherche à résoudre ce besoin avec une portée spécifique - c'est-à-dire déterminer au passage la solution au besoin.

Réservez les billets, l'hébergement tout compris et les transferts pour un week-end complet - du vendredi au dimanche - dans la station balnéaire de Punta Cana en République dominicaine pour Alberto et sa famille.

À première vue, voyager le temps d'un week-end est une exigence qui résoudra certainement mon désir de prendre des vacances. Si vous ne connaissez pas Punta Cana, disons simplement que c'est un endroit pour se détendre et profiter du temps, des plages et d'un bon rhum.

Cependant, l'exécution de cette exigence limite les options pour résoudre le besoin à une (1), c'est-à-dire que je ne peux aller qu'à Punta Cana. Que se passe-t-il si les vols pour Punta Cana sont annulés, ou s'il n'y a pas de disponibilité dans les hôtels ? Nous ne pouvons pas résoudre cette exigence.

Exigences axées sur la valeur commerciale

Une histoire d'utilisateur - plus ou moins bien écrite et avec la ferme intention d'expliquer la différence académique, se présenterait comme suit :

En tant que travailleur dévoué et engagé, je veux passer quelques jours loin du travail et de la famille pour me reposer et recharger l'énergie dont j'ai besoin pour bien faire mon travail.

Cette exigence ne dit pas précisément ce qu'il faut faire pour offrir à Alberto quelques jours de répit. Cela peut être une mauvaise chose si, en tant qu'équipe, nous n'avons pas la moindre expérience en matière de répit familial. Cela peut être une bonne chose si, en tant qu'équipes, nous sommes capables d'offrir des alternatives de répit aux familles.

Rôles de Scrum

Le cadre est un "ensemble de base". Et selon cette philosophie, les rôles au sein de Scrum le sont aussi. C'est-à-dire qu'il y a certains rôles dans le cadre, mais cela ne veut pas dire qu'il ne peut pas avoir d'autres rôles, n'est-ce pas ?

Certains radicaux, ScrumaniacsS'il n'y a pas d'autres rôles dans une équipe Scrum, on dira qu'il n'y a pas d'autres rôles, mais disons qu'il peut y avoir des spécialisations. Disons, spécialiste UI/UX ou spécialiste des tests, ou spécialiste des bases de données - je viens de donner plusieurs exemples pour torturer les scrumaniacs.

Ces rôles fondamentaux sont :

Propriétaire de produit - Propriétaire de produit

Un pot dont les pièces qui en sortent représentent le flux de valeur de l'entreprise

D'après mon expérience, le Product Owner (PO) est le rôle le plus important dans le succès de scrum dans les organisations. Je suis sûr que vous vous posez la question, mais le Scrum Master - quel est l'intérêt de dire "master" dans votre rôle si vous n'êtes pas le plus important ? Eh bien, ces choses-là arrivent parfois.

Selon moi, le PO est responsable de l'élément clé de l'agilité, à savoir la structure de ventilation qui permet la livraison incrémentielle - ou les fameux incréments de produit.

Imaginez être à la tête de la meilleure équipe de chefs du monde et ne pas savoir quoi demander de plus que "du riz avec des œufs".[1]Et je veux dire que c'est un plat que nous avons tous mangé à un moment ou à un autre et c'est une partie de la... Classement de Taste Atlas.. Ou demander des recettes qui ne correspondent pas aux goûts de vos convives potentiels. Quel gâchis !

Le Product Owner est chargé de maximiser le bénéfice des résultats du travail de l'équipe (de développement). En d'autres termes, le Product Owner est celui qui définit, hiérarchise et valide les exigences - ou du moins régit ces processus. Et dans cet exercice de définition, de hiérarchisation et de validation, il/elle cherche à maximiser le "flux de valeur". C'est-à-dire les avantages que l'on retire en testant, en utilisant ou en expérimentant le résultat de chaque itération.

Scrum Master

Silhouette avec des rayons laser derrière

L'autre rôle est celui du Scrum Master, qui est une sorte d'animateur et de pom-pom girl - parfois plus le second que le premier XD - qui cherche à responsabiliser l'équipe (en tant qu'équipe) et à soutenir ses membres dans leur croissance.

Loin de prendre des responsabilités directes au sein de l'équipe, le Scrum Master est celui qui "s'occupe" de l'exercice de la méthodologie - même si, en théorie, Scrum n'est pas une méthode. Et c'est lui qui protège l'équipe contre les abus potentiels du PO, et qui aide à résoudre les obstacles qui peuvent survenir tout au long de l'exercice de travail - une sorte de skateboarder, comme on dirait ici en Colombie.

Beaucoup voient le SM comme un sauveur, ou un être éclairé. J'admets qu'il n'est pas facile d'être celui qui conduit le changement - et qui aide à la transformation. Mais il ou elle est certainement plus un agent de changement qu'un acteur actif du processus de production.

Le Scrum Master est-il le nouveau chef de projet ?

À mon avis, pas du tout. Les deux rôles sont différents et complémentaires. Vous pouvez avoir des PM, des SM ou des SM qui sont également PM, ou des PM qui sont également SM. Cela dépend beaucoup de l'organisation et des responsabilités associées au rôle.

Ce qui ne devrait jamais arriver, c'est que le SM et le PO soient la même personne. Il peut donc s'agir d'un PM/PO ou d'un PM/SM, mais jamais d'un seul PM - je pense que c'est la plus grande erreur de ce que nous appelons aujourd'hui le management traditionnel : essayer de faire en sorte que le PM fasse les deux. Un point pour les agilistes !

Il y a peu de temps, j'ai écrit un article qui pourrait vous intéresser sur les rôles du PM et du SM : Si vous êtes agile, vous n'avez pas besoin de chefs de projet.

Développeurs - Développeurs

Les ouvriers d'un chantier de construction représentent les développeurs Scrum.

Eh bien, bien que Scrum ne parle pas spécifiquement de développement, il n'a pas réussi à trouver un autre terme pour l'équipe de personnes qui font réellement le travail. Autrement dit, si le PO est celui qui demande, et le SM celui qui facilite, les développeurs sont ceux qui font.

Cette équipe est multidisciplinaire et, espérons-le, autonome. Il ne doit pas y avoir trop de personnes, mais pas trop peu non plus - disons qu'on disait quelque chose comme 3 à 9, ou 5 à 7, ou... vous voyez le tableau. S'ils sont trop nombreux, ils ne peuvent pas se coordonner en équipe, s'ils sont trop peu nombreux, ils ne peuvent pas obtenir de résultats en peu de temps.

Considérations finales

Comme vous pouvez le constater, Scrum n'est pas un cadre complexe ou difficile à comprendre. Il est relativement simple et repose sur un modèle très simple de gestion d'équipe et de séparation des rôles. Ça me rappelle beaucoup le livre La mort par réunion. Cependant, comme ils le disent dans le Scrum Guide - le guide canonique de Scrum :

Scrum est gratuit... Le cadre de Scrum est immuable. Bien qu'il soit possible de ne mettre en œuvre que certaines parties de Scrum, le résultat n'est pas Scrum. Scrum n'existe que dans sa globalité et fonctionne bien comme un conteneur pour d'autres techniques, méthodologies et pratiques.

Guide Scrum 2020

Partager!

Commentaires et notes de l'auteur[+]

Image par défaut
Alberto Dominguez
Diriger des équipes de la théorie à la réalisation réelle et durable de produits et services informatiques innovants.
Publications: 33

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

fr_FR