Chapitre 1

Les bases de Scrum

 

Dans ce chapitre :

• Découvrir les principes essentiels de Scrum
• Cerner les valeurs et la structure de Scrum

 

À la base, Scrum est un modèle empirique, ce qui signifie que la connaissance s’acquiert de l’expérience de la vie réelle, et les décisions sont prises sur la base de ce qui est restitué de cette expérience. C’est une manière d’organiser votre projet – qu’il s’agisse de sortir un nouveau smartphone ou d’organiser la fête d’anniversaire de votre fille de 5 ans – afin de vérifier si la manière dont vous vous y prenez produit les résultats attendus.

 

Scrum, c’est l’empire du bon sens. Vous vous concentrez sur ce que vous êtes en mesure de faire aujourd’hui, décomposant le travail à venir en morceaux que vous pourrez terminer. Vous pouvez immédiatement constater si votre méthode de développement fonctionne, et lorsque vous détectez des inefficacités, Scrum vous permet de réagir en procédant à des ajustements clairs et rapides.

Le modèle empirique renvoie à la nuit des temps dans le domaine de la production artistique. En sculpture, vous taillez, vous observez le résultat, vous procédez à des retouches, puis taillez un peu plus. C’est une manière tout à fait moderne d’approcher la production informatique. Ce modèle empirique signifie que vous raisonnez sur la base de vos expérimentations concrètes, plutôt que sur la base d’une modélisation abstraite initiale. Dans Scrum, vous décomposez votre projet en éléments autonomes, afin de pouvoir observer les résultats de leur production de chacun d’eux. Cela vous permet d’apporter immédiatement les changements nécessaires pour garder le cap autant que possible.

Les bases de la vue d’avion

Scrum n’est pas une méthode. Ce n’est pas une approche mathématique de la production d’un produit ; c’est simplement un cadre pour définir des rôles clairs et organiser votre travail, afin d’être plus efficace lorsque vous priorisez, et plus efficient lorsque vous réalisez ce qui a été priorisé. Un cadre est moins prescriptif qu’une méthode ; il est possible de lui adjoindre des processus, des structures et des outils pour le compléter. Lorsque vous utilisez une telle approche, vous pouvez clairement observer les résultats et ainsi déterminer si vous réalisez des progrès tangibles. Vous pouvez parvenir à des résultats qu’il est possible de tester en quelques semaines, quelques jours ou même parfois en quelques heures.

 

Tout comme on construit une maison brique par brique, Scrum est une approche itérative, incrémentale. Elle vous donne accès aux preuves empiriques de votre performance et de la qualité de ce que vous produisez. Les rôles sont distincts, les individus et les équipes disposent de la liberté et des outils requis pour accomplir leurs tâches. Il n’y a pas de rapports d’avancement interminables, de réunions redondantes, d’empilements de strates de management. Si vous souhaitez simplement parvenir à un résultat, Scrum est l’approche dont vous avez besoin.

Scrum est un terme emprunté au rugby. Une mêlée (Scrum en anglais) est formée par les joueurs, les avants d’une équipe se tenant par les bras, tête baissée, et poussant les avants de l’équipe adverse, qui se tiennent aussi par les bras, tête baissée. Le ballon est alors jeté au milieu de cette masse compacte. Quoique chaque joueur occupe une position unique, tous jouent à la fois un rôle d’attaquant et un rôle de défenseur, et travaillent comme une seule équipe pour déplacer le ballon sur le terrain de jeu. Tout comme le rugby, Scrum repose sur des gens talentueux intervenant à divers niveaux de responsabilité dans différents domaines, travaillant tous ensemble comme une équipe afin d’atteindre un objectif commun.

 

Je veux insister sur un aspect souvent négligé de Scrum, auquel j’ai tout de même consacré les deux tiers de ce livre – sa versatilité absolue. Ceux qui connaissent Scrum pensent souvent que c’est adapté au logiciel, à l’informatique, à la technique. Mais ce n’est que le sommet de l’iceberg. N’importe quel projet – grand, petit, technique, artistique, personnel, social – peut être placé avec profit dans le cadre défini par Scrum. Les Chapitres 7 à 17 vous le démontreront.

Une feuille de route pour la création de valeur

Tout au long de ce livre, je discute des techniques que moi-même et d’autres praticiens de Scrum appliquons à titre d’extensions de Scrum. Elles complémentent, et non remplacent, le cadre défini par Scrum. Je mettrai en évidence les différences quand il y en aura. Chaque pratique que j’ai retenue a été testée par moi et bien d’autres, et je vous la recommande – sans jamais perdre de vue que ces pratiques ne relèvent donc pas directement de Scrum, et qu’il vous appartient de les retenir ou non selon la situation à laquelle vous êtes confronté.

 

Je vais appeler cette combinaison de Scrum et de pratiques dûment certifiées la « feuille de route pour la création de valeur ». Elle se compose de sept étapes que vous parcourez, allant de la vision de votre projet à la description des tâches, puis procédant à rebours dans un processus continu d’évaluation et d’adaptation. Autrement dit, les étapes vous aident à déterminer ce que vous souhaitez produire en vous proposant de décomposer votre projet en éléments de manière itérative, répétant un cycle au cours duquel vous produisez des résultats intermédiaires chaque jour, chaque semaine, chaque mois.

Figure 1-1 : Les 7 étapes de la feuille de route pour la création de valeur.

La Figure 1-1 donne une vue générale de cette feuille de route.

 

Ce graphique permet de voir que vous commencez par la vision, enclenchez sur la planification, puis entrez dans la boucle de répétition des sprints, des revues et des rétrospectives.

Une présentation simplifiée de Scrum

Le processus de Scrum est simple et circulaire, conduisant à évaluer et à adapter en permanence ce que vous faites :

•  Une liste des courses très résumée – appelée backlog du produit – est créée et tenue à jour.
•  Les chantiers les plus prioritaires sont sélectionnés pour être réalisés dans un temps donné – appelé un sprint – pendant lequel l’équipe Scrum fait de son mieux pour atteindre un objectif convenu collectivement.

Figure 1-2 : Une vue simplifiée des différents évènements et des cycles de Scrum.

Le processus de Scrum permet de s’adapter rapidement aux changements des forces du marché, des contraintes technologiques, des régulations, des innovations, et presque à tout ce qui pourrait changer. La clé, c’est de travailler en continu sur les éléments de plus haute priorité jusqu’à les livrer. Chacun de ces éléments est intégralement développé et testé en parcourant les étapes suivantes :

•  Élaboration des exigences
•  Conception
•  Développement
•  Tests exhaustifs
•  Intégration
•  Documentation
•  Approbation

Les sept étapes sont parcourues pour chaque exigence traitée lors d’un sprint. Aussi limitée ou importante qu’elle soit, toute exigence est totalement développée, testée et approuvée ou rejetée.

 

Lorsqu’une exigence est acceptée et qu’elle est donc « livrable », vous saurez que cela fonctionne. L’espoir et le tâtonnement sortent de l’équation et sont remplacés par le principe de réalité. Vous construisez votre produit, étape par étape, et vous donnez à voir ces étapes aux parties prenantes pour qu’elles vous fassent un retour. Ce retour génère de nouvelles exigences qui sont rajoutées dans le backlog du produit, les priorités de toutes les exigences étant alors redéfinies.

Qu’est-ce qui est le plus important : l’efficacité ou l’efficience ? C’est l’efficacité. Ne vous souciez pas d’être efficient tant que vous n’êtes pas efficace. Une équipe de développement efficiente qui ne travaille pas sur le bon sujet perd son temps. Toutefois, une équipe de développement super efficace peut facilement apprendre à devenir efficiente. Il faut toujours travailler sur le bon sujet.

« Rien n’est plus inutile que faire efficacement ce qui ne devrait pas être fait du tout » – Peter F. Drucker.

 

Le cycle de Scrum se répète encore et encore. Grâce au flot ininterrompu des retours et à la priorisation, vous tenez mieux compte de ce qui focalise l’attention de vos clients, et vous les livrez plus rapidement avec une meilleure qualité.

L’équipe Scrum

Quelle que soit l’importance de votre projet Scrum, votre équipe Scrum devra présenter les mêmes caractéristiques. La taille de l’équipe de développement peut varier, mais les rôles restent identiques. Je passerai en revue chacun d’entre eux au fil de cet ouvrage. La Figure 1-3 vous présente une représentation visuelle de l’équipe Scrum.

 

Au cœur de l’équipe Scrum, on trouve l’équipe de développement. Ce sont les gens qui vont travailler ensemble pour créer le produit. Ils travaillent directement avec un propriétaire du produit et un Scrum Master. Je traite dans le détail de ces rôles. Il suffit pour l’instant de dire que leur travail est d’aider à aligner les priorités du business et celles du développement et d’éliminer tout ce qui pourrait distraire l’équipe de développement de sorte qu’elle puisse se focaliser sur son travail : produire !

Figure 1-3 : Au cœur de l’équipe Scrum, on trouve l’équipe de développement.

Les parties prenantes ne renvoient pas à des rôles, mais je les ai fait figurer, car elles impactent votre projet, même si elles ne sont directement impliquées dans sa réalisation. Elles peuvent être internes ou externes. Les équipes du marketing, du juridique ou de l’infrastructure sont quelques exemples de parties prenantes. L’équipe Scrum est celle qui devra finalement rendre des comptes. Elle doit trouver le moyen d’atteindre ses objectifs dans l’environnement où elle évolue.

La gouvernance

Scrum comprend trois rôles, d’égale importance, mais renvoyant à des fonctions bien distinctes. Chacun de ces rôles poursuit un objectif bien défini spécifiquement assigné pour améliorer la productivité de l’équipe dans son ensemble :

•  Le propriétaire du produit : le quoi et le quand (et non le combien).
•  L’équipe de développement : le comment et le combien.
•  Le Scrum Master : le gardien du processus.

Les créateurs de Scrum ne sont pas tombés sur ces rôles par hasard ; ils les ont identifiés après des années d’expérience à travailler avec toutes sortes d’équipes de projet. Ils ont vu le bien, le mal, et des combinaisons horribles de l’un et de l’autre, et finalement déterminé que les meilleurs résultats étaient produits en recourant à ces trois rôles.

Je préfère que chaque rôle soit assuré à temps plein et consacré exclusivement à l’équipe Scrum du projet. Ne répartissez pas les membres de votre équipe sur différents projets, et ne mobilisez pas de membres à temps partiel. Connaissez-vous des équipes de rugby professionnel dont les joueurs sont à temps partiel ou qui jouent dans plusieurs équipes simultanément ? Disperser l’équipe n’est pas un facteur de succès.

Dans Scrum, aucune personne, quel que soit son rôle, n’est au-dessus des autres. Tout le monde est à égalité ; pas de patron ou de subordonné. Il faut dire « nous » plutôt que « je ».

Le cadre de Scrum

Scrum est un cadre, une approche, plutôt qu’une méthode. Il clarifie les responsabilités grâce aux rôles, donne de la visibilité grâce aux artefacts et ménage des opportunités d’évaluer et d’adapter au fil des évènements. Scrum contient des processus et des outils qui sont adaptés aux besoins spécifiques de l’équipe, de l’organisation ou du projet.

 

Le cadre d’un projet Scrum de base contient les choses suivantes :

•  Trois rôles
•  Trois documents (artefacts)
•  Cinq évènements

Chacun de ces éléments du cadre Scrum intervient dans le processus Scrum, qui est itératif et incrémental. Vous allez créer puis améliorer votre produit par touches successives, et améliorer de manière incrémentale votre processus dans ce cadre. Comme vous pouvez le voir, ce cadre est donc incroyablement simple :

•  Rôles :
  • • Propriétaire du produit
  • • Équipe de développement
  • • Scrum Master
•  Documents/Artefacts :
  • • Backlog du produit
  • • Backlog du sprint
  • • Incrément du produit
•  Évènements :
  • • Sprint
  • • Planning de sprint
  • • Scrum quotidien
  • • Revue de sprint
  • • Rétrospective de Scrum

Dans le monde de Scrum, les artefacts font référence à des listes de travaux à accomplir ou à un travail déjà réalisé et considéré comme « livrable ». Contrairement aux artefacts archéologiques, les artefacts de Scrum ne sont pas gravés dans la pierre. Au contraire, le processus Scrum exige qu’ils soient perpétuellement évalués pour s’assurer que vous fouillez dans la bonne direction.

Chaque rôle, artefact et évènement Scrum a un objet précis. La seule chose que Scrum vous impose, c’est le cadre dans lequel vous inscrivez votre projet pour parcourir les sept étapes de la feuille de route de création de valeur. Les outils et les techniques à utiliser pour atteindre vos objectifs sont à votre discrétion. Scrum ne vous dit pas comment atteindre ces objectifs ; il ne fournit que le cadre vous permettant de savoir clairement ce que vous êtes en train d’accomplir.

 

En théorie, Scrum est simple. Dans la pratique, Scrum peut être compliqué à mettre en œuvre. C’est un peu comme chercher à maigrir. En théorie, vous devez faire plus d’exercice et ingurgiter moins de calories. Toutefois, c’est loin d’être aussi facile en pratique.

 

Pour vous aider dans la mise en œuvre, je vous recommande quelques pratiques qui complémentent Scrum. Au fil des années, il m’a été donné de voir des réussites étonnantes basées sur ce modèle (les éléments que je rajoute sont en italique) :

•  Rôles :
  • • Propriétaire du produit
  • • Équipe de développement
  • • Scrum Master
  • • Parties prenantes
  • • Scrum Mentor
•  Artefacts :
  • • Vision
  • • Feuille de route du produit
  • • Backlog du produit
  • • Backlog du sprint
  • • Plan de livraison
  • • Incrément du produit
•  Évènements :
  • • Planification du projet
  • • Planification de la livraison
  • • Sprint
  • • Planning de sprint
  • • Scrum quotidien
  • • Revue de sprint
  • • Rétrospective de Scrum

Ici, j’ai changé la formule en 5-6-7. Cela reste toujours simple, mais avec des rôles, des artefacts et des évènements supplémentaires, conçus pour rendre le processus plus fluide. Je vais passer en revue dans le détail chacun au fil de ce livre.

Le retour gagnant

L’un des grands avantages de Scrum sur les autres approches de gestion de projet, c’est la valorisation des retours. Cela vous permet de savoir très tôt ce qui fonctionne, ce qui ne fonctionne pas, ce qui manque, et ce qui est extraordinaire.

 

Le retour est généré régulièrement par les membres de l’équipe Scrum, les parties prenantes et les clients finaux. Il prend approximativement les formes suivantes :

•  Le retour quotidien entre membres de l’équipe de développement tandis qu’ils se lancent dans le développement de chaque exigence du projet.
•  Les interactions directes et quotidiennes entre le propriétaire du produit et l’équipe de développement pour répondre aux questions du moment et fournir un retour.
•  Le retour direct des propriétaires du produit quand ils acceptent ou rejettent chaque exigence une fois réalisée.
•  À la fin de chaque sprint, le retour des parties prenantes internes.
•  À la fin de chaque livraison, le retour du client ou du marché.

Scrum vous sera plus utile que les anciens modèles de gestion de projet, car il se focalise sur le développement du produit plutôt que sur le développement d’artefacts – livrer des produits tangibles, testés, plutôt que des rapports sur ce qu’il serait possible de livrer. Vous bénéficierez d’un retour régulier tout au long du développement, ce qui vous permettra de pouvoir mettre progressivement votre produit sur le marché aussi vite que possible.

 

À la fin de tout projet, qui n’est finalement qu’une série de sprints dans une série de livraisons, vous ne vous retrouvez pas à vous demander si ce que vous avez livré répond aux besoins des clients. Vous aurez communiqué et reçu un retour du début à la fin. Le processus d’évaluation et d’adaptation aura joué pour vous, et vous serez ainsi en mesure de livrer à vos clients ce qu’ils ont demandé.

Les racines de l’agile

Pour comprendre Scrum, il convient de consacrer quelques pages à l’univers des techniques agiles. Scrum relève de l’approche agile (pour un exposé détaillé de techniques agiles, voir mon livre à ce sujet dans la même collection).

 

Agile renvoie à des approches qui respectent les valeurs du Manifeste Agile et les 12 principes de l’agilité, que je vais présenter ici. Scrum est une des approches agiles, car il en existe bien d’autres. Pour vous faire une bonne idée de Scrum, il convient donc de remonter au Manifeste.

Attention ! Scrum est un cadre tellement passionnant que vous l’utiliserez bientôt pour entraîner l’équipe de rugby de votre enfant, planifier des promenades dans le quartier, et même améliorer vos exercices physiques quotidiens.

Les trois piliers de l’amélioration

Le modèle de processus empirique repose sur trois piliers. Ils s’appliquent à l’agile et à Scrum :

•  Transparence
•  Évaluation
•  Adaptation

Transparence

L’un des aspects spécifiques de Scrum, et des techniques agiles en général, c’est leur transparence absolue. L’information est diffusée partout, de manière claire pour la rendre accessible. L’organisation tout entière est mise en capacité de savoir ce qui a été réalisé, ce qui est en cours, et ce qu’il reste à faire. Dès le départ, vous produisez des résultats concrets qui sont testés et puis soit approuvés, soit immédiatement repris pour être ajustés. Le temps de latence entre la date de démarrage et les résultats visibles se compte en jours, et non plus en mois.

 

 

Évaluation

Comme vous le découvrirez au fil des chapitres suivants, les projets agiles sont souvent décomposés pour aboutir aux plus petites actions possibles (normalement appelées histoires utilisateur ou user stories ; voir le Chapitre 3). Des objectifs sont fixés pour être atteints dans un temps limité – le sprint, la version, et le projet. Chaque réalisation est évaluée pour s’assurer qu’elle fonctionne et qu’elle répond aux attentes du client.

 

Ces évaluations sont réalisées par des personnes les plus proches de la réalisation – tant ceux qui font le travail que ceux qui représentent les clients. Cela permet de réduire le délai que prendrait une tierce personne pour réaliser la tâche, et cela signifie aussi que tout ajustement peut être réalisé rapidement, la connaissance requise étant à portée de main.

 

 

Adaptation

Si l’évaluation précédente relève des défauts et/ou des inefficacités – c’est-à-dire, si une fonctionnalité ne répond pas aux besoins – il faut procéder à une adaptation. L’adaptation doit être réalisée aussi vite que possible et avant de passer au travail suivant sur la liste des choses à faire. Autrement dit, avant de continuer, vous devez être certain que ce que vous laissez derrière vous fonctionne parfaitement.

 

Un Sprint permet de procéder à des évaluations et à des adaptations immédiatement au niveau de l’équipe et du projet, grâce à des revues, des rétrospectives et le Scrum quotidien. Je reviens là-dessus en détail au Chapitre 6.

Le Manifeste Agile

Si Scrum est une approche alignée sur le Manifeste Agile, il vaut mieux que vous saisissiez le caractère remarquable de ce bref paragraphe de quatre phrases.

Scrum est un cadre, et pas une méthodologie de pilotage par le chiffre. Vous devrez réfléchir et faire des choix. L’un des avantages du cadre de Scrum est qu’il vous permet de prendre les décisions qui vous conviennent le mieux, en fonction des réalités auxquelles vous vous confrontez.

 

En 2001, 17 experts en logiciel et en projet, chacun ayant appliqué avec succès sa propre manière de travailler, se sont entendus sur quatre valeurs principales au centre de toutes ces manières.

 

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser :

•  Les individus et leurs interactions plus que les processus et les outils.
•  Des logiciels opérationnels plus qu’une documentation exhaustive.
•  La collaboration avec les clients plus que la négociation contractuelle.
•  L’adaptation au changement plus que le suivi d’un plan.

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

 

Manifeste Agile Copyright © 2001 : Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.

 

© 2001, les auteurs ci-dessus.

 

Cette déclaration peut être reproduite librement sous toute forme, mais uniquement si elle l’est intégralement en comprenant cette note.

Quoique le Manifeste Agile et les principes qui en découlent aient été écrits par et pour des experts du logiciel, ils demeurent valides pour tout projet Scrum dans lequel vous vous embarquez. Tout comme le GPS a été conçu par et pour les militaires, cela ne signifie pas pour autant que nous ne pouvons pas en bénéficier lorsque nous sommes en voiture ou en randonnée.

 

La première partie des quatre phrases de l’énumération figure en gras à dessein. Toutefois, la seconde partie des phrases n’en est pas moins importante. Elle vient évoquer l’existence de pratiques qui conservent de la valeur, mais une valeur qu’il convient de relativiser désormais.

Pour plus d’informations sur l’histoire du Manifeste Agile et ses auteurs, reportez-vous à http://agilemanifesto.org.

Les douze principes de l’Agile

Les auteurs n’en sont pas restés à l’affirmation de ces valeurs. Ils se sont aussi entendus sur 12 principes qui en découlent. Dans un projet Scrum, vous pouvez vous appuyer sur ces derniers pour vérifier que votre cadre est bien agile :

1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
2. Accueillez positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compétitif au client.
3. Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
4. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
5. Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
6. La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
7. Un logiciel opérationnel est la principale mesure d’avancement.
8. Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les donneurs d’ordre, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
9. Une attention continue à l’excellence technique et à une bonne conception renforce l’agilité.
10. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
11. Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.
12. À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

Ces principes ne changent pas, mais les outils et les techniques qui en découlent évoluent.

 

Quelques-uns de ces principes sont plus faciles à mettre en œuvre que d’autres. Par exemple, considérons le principe 2. Peut-être que votre entreprise (ou votre groupe, votre famille) est ouverte au changement et aux nouvelles idées. Pour eux, Scrum est naturel et ils sont prêts à s’y lancer. D’un autre côté, certains pourraient opposer plus de résistance au changement.

 

Et que penser du principe 6 ? Est-il seulement possible de travailler face à face dans votre projet ? Avec Internet et la globalisation de la force de travail, vous travaillez peut-être avec des membres de l’équipe qui se trouvent à Mumbai ou à Moscou. Plutôt que d’y voir un obstacle, comment trouver une solution ? Skype ? Google Hangouts ? La téléconférence régulière ? Aucune de ces solutions ne répond au principe 6, car aucune n’est aussi bonne que la communication en face à face. Toutefois, il faut bien faire avec.

 

Vous devrez relever des défis pour appliquer ces principes. Ne vous laissez pas arrêter parce que les conditions ne sont pas parfaites. Une partie du jeu avec Scrum, c’est de se confronter aux problèmes et de trouver des solutions. Ainsi en va-t-il avec les 12 principes. Tâchez de vous y tenir au mieux et vos projets déboucheront plus rapidement sur des résultats de meilleure qualité.

Trois principes supplémentaires en or

Voilà une bonne dizaine d’années que je travaille sur des projets agiles et Scrum, et j’ai personnellement assisté des dizaines d’entreprises, d’associations et de commerces. Je sais combien ces principes fonctionnent ; j’ai pu constater leur valeur alors que j’assistais à leur mise en œuvre.

 

De cette expérience, j’ai retiré trois principes supplémentaires qui ont systématiquement permis d’améliorer la performance des équipes que nous avons aidées :

•  Résister au formalisme
•  Penser et agir en équipe
•  Visualiser plutôt qu’écrire

Ces principes peuvent être appliqués à n’importe quel projet, et non seulement aux projets de développement de logiciels. C’est ce qui fait en partie la beauté des techniques agiles – vous pouvez les utiliser pour n’importe quoi.

 

 

Résister au formalisme

N’avez-vous jamais vu une présentation PowerPoint stupéfiante, et ne vous êtes-vous alors pas demandé combien de temps son auteur avait passé à la réaliser ?

 

Ne pensez même pas à en réaliser dans le cadre d’un projet Scrum. En 1/1 000 de ce temps, griffonnez sur un graphique, collez-le sur un mur où tout le monde pourra le contempler, puis retournez créer de la valeur. Ou alors, s’il faut discuter, allez voir directement les parties concernées et parlez-leur sur l’instant des choses telles qu’elles se présentent ici et maintenant.

 

Consacrez votre temps si précieux au produit plutôt qu’à des présentations sophistiquées.

La société Atos Origin a conduit une recherche indépendante qui montre que l’employé moyen d’une entreprise passe 40 % de ses journées de travail sur des courriels internes qui ne contribuent en rien à la valeur ajoutée. Cela signifie que la semaine de travail ne débute véritablement pas avant le mercredi (Guardian Professional, 17 décembre 2012, 40 % du temps des équipes est consacré inutilement aux courriels internes, par Nick Atkin).

Le problème du marshmallow

En 2010, Tom Wujec a fait une remarquable intervention sur TED (TED est une organisation caritative qui se donne pour objectif de diffuser des idées, généralement sous la forme de courtes interventions efficaces), nommée Le problème du marshmallow. Il traitait d’un exercice de conception intéressant conçu par Peter Skillman. Dans cet exercice, des petits groupes de participants ont 18 minutes pour construire une structure à l’aide d’outils étranges et minimaux : 20 spaghettis, une longueur de bande, une longueur de ficelle, et un… marshmallow.

 

Wujec a commencé à administrer ce test et à observer les résultats. La plupart des groupes rencontrent des difficultés pour construire quelque chose qui s’élève ou qui résiste. Ils discutent d’options, planifient un schéma minimal, puis dans la dernière minute ou presque, assemblent tout pour réaliser qu’ils ont oublié de tenir compte d’une donnée cruciale et que ça ne tiendra pas debout.

 

Les groupes qui ont le plus mal réussi ? De jeunes diplômés d’écoles de commerce (aïe, j’ai deux MBA). Les groupes qui réussissent le mieux ? Les enfants de maternelle. Ils produisent des structures plus élevées et plus créatives.

 

La raison ? Wujec croit que lorsque les étudiants d’écoles de commerce travaillent sur une idée, ils pensent qu’il n’existe qu’une seule « bonne » solution et ils passent beaucoup de temps à la rechercher, alors que les enfants commencent directement à jouer avec les outils. Ils découvrent ce qui ne marche pas et le changent, puis ils trouvent ce qui marche et le gardent. Tout au long du processus, ils construisent des prototypes.

 

Ce qu’il faut en retenir, c’est que notre instinct nous pousse à explorer et à nous adapter. Nous y sommes poussés par nature, mais au cours de notre vie, on nous apprend que rechercher une seule solution et tout planifier d’avance pour la mettre en œuvre est la bonne manière de procéder. Mais les enfants de maternelle nous rappellent que ce n’est pas ainsi qu’il faut procéder.

Le grand spectacle est souvent confondu à tort avec le professionnalisme. Dans les projets Scrum, vous êtes incité à communiquer immédiatement, directement, et de manière informelle chaque fois que vous avez une question, et à travailler dans la proximité des membres de votre équipe pour améliorer l’efficience et gagner du temps.

 

Évitez ces pièges contre-productifs :

•  des présentations élégantes qui prennent du temps ;
•  des réunions longues ou sans objet précis ;
•  des tonnes de documentation.

À l’inverse, investissez sur ces leviers de productivité :

•  Être à peine suffisant. En toute chose, le travail devrait être à peine suffisant pour atteindre l’objectif (ne confondez pas avec médiocre : suffisant, c’est suffisant ; trop, c’est du gâchis, et les problèmes surviennent d’ailleurs quand on en fait trop ; voir le principe agile 10 plus haut).
•  Communiquer fréquemment avec toutes les parties pour réduire leur besoin d’informations à jour.
•  Communiquer simplement et directement. Si vous pouvez vous déplacer pour aller parler à quelqu’un, faites-le.

Trouvez le moyen le plus simple d’obtenir ce que vous voulez, en vous focalisant sur l’objectif de délivrer un produit de meilleure qualité.

La manière de conduire vos projets va évoluer et emprunter à la culture de Scrum. Tandis que les gens assimileront le processus et qu’ils constateront l’amélioration des résultats, ils prendront l’habitude de fournir un travail à peine suffisant. Misez donc sur la formation, la patience et les résultats concrets.

 

 

Penser et agir en équipe

Travailler en équipe est au cœur de Scrum. Cela peut paraître a priori déroutant, car dans une culture occidentale, on encourage souvent l’inverse – on valorise l’individu. « Comment puis-je me débrouiller dans cet environnement afin de pouvoir me distinguer et décrocher une promotion ? ».

 

Dans Scrum, la survie ou la mort du projet se joue au niveau de l’équipe. En vous appuyant sur les talents individuels pour développer des talents d’équipe, vous pouvez devenir hyper-productif. Selon Aristote, « le tout est plus que la somme de ses parties ».

 

Comment créer cette culture d’équipe ? Le cadre de Scrum insiste sur l’équipe. L’espace de travail physique, les objectifs communs et la propriété collective : tout cela renvoie à l’équipe. Ajoutez les pratiques suivantes pour renforcer votre équipe :

•  Éliminez les titres. Personne ne « possède » une partie du développement. Les statuts sont déterminés par les compétences et les contributions.
•  Faites travailler des membres de l’équipe deux par deux pour développer le brassage de compétences (cross-fonctionnel) et la qualité. Permutez souvent les partenaires.
•  Utilisez toujours des métriques propres à l’équipe pour évaluer la situation, et jamais de métriques qui ne conviennent qu’à certains.

Visualiser plutôt qu’écrire

Dans l’ensemble, les gens sont visuels. Ils pensent à l’aide d’images, et se souviennent d’images. À ceux d’entre vous qui sont assez vieux pour se souvenir des encyclopédies : que préfériez-vous ? La plupart des enfants apprécient les images – les illustrations du texte. Il en va de même pour les adultes. Nous avons toujours tendance à lire un magazine en regardant les images, avant de revenir parfois sur des articles dont les images ont attiré notre attention.

 

Les dessins, les diagrammes et les graphiques relaient l’information instantanément. À l’inverse, si vous écrivez un rapport, l’attention chute tandis que le rapport s’allonge.

Twitter a cherché à évaluer l’efficacité des tweets comportant des photos en comparaison de ceux ne contenant que du texte. Pour cela, Twitter a conduit une étude avec SHIFT Media Manager, laquelle étude a produit quelques résultats intéressants. Les utilisateurs s’impliquent cinq fois plus fréquemment lorsque les tweets contiennent des photos que lorsqu’ils ne contiennent que du texte. Et le taux de retweets et de réponses à des photos est double. Toutefois, le coût par implication des tweets contenant une photo est la moitié de celui des tweets à base de texte uniquement (Shift Newsroom, 17 janvier 2014).

 

Lorsque c’est possible, incitez votre équipe à présenter l’information visuellement, même si cela implique de dessiner un diagramme sur un tableau blanc. Ceux qui ne comprendront rien auront toujours la possibilité de le faire savoir, et l’information pourra être présentée autrement sur l’instant. N’oubliez pas qu’avec la technologie d’aujourd’hui, il est très simple de produire des graphiques et des modèles.

Les origines de Scrum

Si l’élaboration du cadre agile que nous connaissons aujourd’hui a débuté il y a presque 100 ans, la première équipe Scrum a été constituée par Jeff Sutherland en 1993 en appliquant les concepts soulignés dans un article de 1986 de la Harvard Business Review intitulé « Le nouveau jeu du développement de produit ». Avec le cocréateur de Scrum, Ken Schwaber, Jeff a formalisé le cadre de Scrum lors de l’édition de 95 du l’OOPSLA (conférence internationale sur la programmation, les systèmes, les langages et les applications orientés objet).

Les cinq valeurs de Scrum

Scrum a été fondé sur cinq valeurs auxquelles tout membre de l’équipe se réfère pour prendre des décisions. Elles n’ont rien de très sophistiqué. En fait, elles relèvent toutes du bon sens. Toutefois, elles n’en sont pas moins essentielles pour réussir à mettre en œuvre Scrum, si bien qu’il convient d’en parler plus en détail :

•  Engagement
•  Focalisation
•  Ouverture
•  Respect
•  Courage

Engagement

Les membres de l’équipe Scrum doivent s’engager à réussir, en cherchant à se fixer des objectifs réalistes et en s’y tenant. Vous devez participer. C’est une situation d’engagement total où vous faites partie de l’équipe, et votre boulot consiste à travailler ensemble pour respecter vos engagements. Fort heureusement, le modèle de Scrum garantit que vous disposez de l’autorité et de la liberté requises pour cela.

 

Au cœur de Scrum, on trouve un évènement nommé sprint. J’en traiterai en détail au Chapitre 5. Pour l’heure, je veux seulement dire qu’un sprint requiert des objectifs clairs qu’il faut atteindre dans des délais impartis. La bonne nouvelle, c’est que dans ce modèle, vous pouvez diviser ces objectifs et leur délai, jusqu’à être en mesure de vous assigner des sous-objectifs que vous êtes certain de pouvoir atteindre en une portion de délai, respectant ainsi vos engagements.

Focalisation

Une partie de la magie de Scrum, c’est qu’elle se fonde sur le concept de focalisation. Focalisez-vous sur un petit nombre de choses à la fois. Votre rôle doit être clair, de même que les objectifs qui lui sont assignés. Votre boulot est de vous contenter de jouer ce rôle pour atteindre les objectifs.

 

Vous avez déterminé vos objectifs et vous vous êtes engagés à les atteindre plus tôt. Focalisez-vous sur ces objectifs, et oubliez le reste. Au Chapitre 2, je vous fournirai même des outils et des techniques pour écarter tout ce qui pourrait vous distraire, sans pour autant vous empêcher de vivre.

 

Ne vous inquiétez pas. Contribuez de votre mieux. Soyez heureux.

Ouverture

Tout dans votre projet doit être transparent et accessible pour être évalué et amélioré. Adieu l’époque où l’on découvrait des surprises après six mois.

 

Les bases de Scrum sont les piliers de l’empirisme agile – la transparence, l’évaluation et l’adaptation. L’utilisation d’indicateurs (sous forme de grands graphiques, bien lisibles) et la pratique de la remontée d’informations en temps réel qui en découle contribuent à ouvrir votre projet aux autres. Sans doute, nous ne sommes pas habitués à exposer pareillement ce que nous faisons, mais une fois que votre organisation aura pris cette habitude, elle ne reviendra pas en arrière.

Respect

Chaque membre de l’équipe est sélectionné pour sa force ou ses forces ; en conséquence de quoi, il a aussi ses faiblesses, et donc autant d’opportunités d’apprendre et de grandir. Chacun doit respecter l’autre. C’est une règle d’or dans Scrum.

 

L’harmonie n’est possible dans l’équipe qu’à condition que chacun joue, à propos, la partition de son rôle. Si un membre de l’équipe n’est pas dans le rythme, c’est dans votre intérêt de l’aider, car chaque membre de l’équipe est tenu responsable des résultats de l’équipe dans son ensemble.

 

Les gens veulent bien faire ; ils sont câblés pour cela. Si vous cherchez à valoriser ce qui est positif, vous susciterez le positif. À l’inverse, si vous cherchez à pointer le négatif, vous susciterez le négatif. Le respect est à la base de la positivité.

Courage

Scrum, c’est le changement. Dites adieu aux procédures routinières, et embrassez les procédures élaborées sur la base de ce que l’équipe trouve le plus efficace.

« Il est important que les étudiants fassent preuve d’un peu d’irrévérence envers leurs études ; ils ne sont pas là pour se livrer au culte du savoir, mais pour le remettre en question » – Jacob Bronowski.

 

Les idées sont mises à l’épreuve. Les fiefs seront remis en question. Les règles sont testées. Les routines sont brisées. Le changement peut être dur. Pour changer, il faut du courage.

 

Il faut du courage pour se lancer dans Scrum.