Guide Scrum 2020 #2 - Scrum vs Agile

Suite de ma série sur le guide Scrum 2020, je vous propose une plongée dans les arcanes du monde Agile et du monde Scrum. Un monde maintenant largement influencé par des intérêts mercantiles et que la mise à jour 2020 du guide Scrum essaye de contenir à sa façon.

L'agilité hors de contrôle

Au mois de février 2001, une quinzaine de personnes se retrouvent en gros autour du feu dans les montagnes de l'UTAH pour discuter de l'évolution et de l'avenir des méthodes de développement logiciel. Ambassadeurs du eXtreme Programming, Scrum, Feature-Driven Development et autres se concertent et se posent une excellente question: quels principes sous-jacents à nos méthodes font leur succès? Ils résument leur réponses avec 4 principes qui forment le Manifesto Agile:

Nous valorisons

• 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

Et c'est tout. C'est là quelque chose de très important et l'une des grosses incompréhensions de la haute-performance et de la transformation numérique. Le processus importe finalement peu. Ce qui compte c'est la mentalité avec laquelle vous appliquez votre méthodologie. On dit souvent que Scrum est une méthode agile mais une majorité d'équipe font du Scrum de manière non-Agile car ils n'appliquent pas les valeurs énoncées ci-dessus.

Comment quatre petites phrases ont pu se transformer en industrie? La volonté des entreprises de copier les modèles de la Silicon Valley, la peur de rater le virage du numérique ou encore le besoin de se vendre comme entreprise moderne ont permis à tout un nouvel écosystème de voir le jour: consultants, coaches, certifications, processus, techniques de développement tout devient Agile. Au risque d'être vidé de son sens.

Être Agile, c'est travailler selon un certain état-d'esprit et quand je dis ça, je vois déjà mes anciennes équipes lever les yeux au ciel, car c'est bien quelque chose que je répète absolument constamment. C'est une mentalité et rien de plus. Cela ne veut pas dire que ce n'est pas important bien au contraire: Les meilleures équipes se différencient justement par leur mentalité et leurs comportements différents qui leur permettent de mettre en place une culture de haute-performance. Me suis-je d'abord concentré sur les interactions avec mes collègues avant de me réfugier derrière la règle du processus? Est-ce que je me concentre vraiment sur les besoins de mes clients au lieu de juste servir la demande (contrat) du boss? Voilà des questions qui pourront complètement changer la façon dont vous créez vos produits technologiques.

Être Agile donc, ce n'est pas juste appliquer un certain processus ou certaines pratiques. Cela amène plein de conséquences presque cocasses: Il est donc tout à fait possible de fonctionner en Scrum de manière non-agile! Et c'est un des pièges dans lequel on retrouve de trop nombreuses équipes. Soyez méfiants envers les recettes de succès pré-fabriquées, elles oublient souvent le cœur de ce qu'est l'agilité et ne vous délivrera probablement pas les résultats attendus.

Scrum en alternative

En février 2001, deux personnes particulières ont signé le Manifesto Agile: Ken Schwaber et Jeff Sutherland. Ces noms vous disent quelque chose? Ce sont les parents de Scrum et les deux auteurs du Guide Scrum! Voilà pourquoi on associe toujours Scrum à l'Agilité. Mais voilà, 20 ans après et avec l'édition 2020 de ce Guide Scrum, l'Agilité n'est mentionné nul part.

Quand on on parle d'agilité maintenant, on ne parle quasiment plus du tout des valeurs agiles qui sont aussi complétées par 12 principes de développement logiciel. On parle de méthodologies, souvent de recettes toutes faites censées propulser du jour au lendemain une entreprise et ses équipes vers des sommets d'innovation et de performance. Le succès est malheureusement rarement au rendez-vous et Scrum souhaite explicitement se distancier de ce mouvement. Alors que SAFe prétend: "SAFe sustains and drives faster time-to-market, dramatic increases in productivity and quality, and improvement in employee engagement", Scrum annonce de manière très différente "Easy to understand, difficult to master".

Scrum se positionne ainsi clairement en opposition à l'industrie Agile et je pense ce nouveau positionnement bienvenu car quand on compare Scrum et SAFe, les approches sont complètement opposées. SAFe vous dira que vous pouvez faire du Scrum dans SAFe bien sur mais vous comprendrez bien rapidement que lorsqu'un Product Owner voit son backlog être "cascadé" du backlog du Program Owner qui lui même est "cascadé" du portfolio de l'Epic Owner, on n'est pas dans l'Agilité mais bien dans une approche Waterfall très classique. Scrum se veut tout autre et se concentre sur un élément critique de la haute-performance: L'autonomie, la responsabilisation mais surtout une notion que je traduirais en français par l'émancipation des équipes.

Les Affranchis

En anglais, on parle d'empowerement. Il n'y a pas vraiment de traduction française qui permet de communiquer le sens complet du mot. Il y a une notion de pouvoir bien sur, mais aussi d'autonomie et d'habilitation, signifiant qu'avec le pouvoir vient aussi liberté et une attente d'une certaine pro-activité et de sens des responsabilités. À l'image d'un mineur qui gagne les droits d'un adulte, j'aime bien le terme émancipation car il véhicule bien cette idée de s'affranchir d'une tutelle avec un objectif d'indépendance mais aussi de l'attente d'une attitude responsable. Et voilà donc le facteur différentiateur #1 quand on regarde les équipes de haute-performance des Amazon et autres versus le reste du monde: Ces équipes bénéficient d'une émancipation totale. Netflix est l'entreprise ayant poussé cette notion le plus loin si vous souhaitez en savoir plus.

Ici l'industrie  Agile n'a plus vraiment de message et le Scrum Guide 2020 positionne Scrum très fortement sur ce thème. Il est ainsi énoncé clairement que les équipes doivent être auto-gérées. Il ne s'agit pas ici de prendre un positionnement contre les gestionnaires. Les équipes de haute-performance n'ont pas moins de gestionnaires, elles ont de meilleurs gestionnaires (ma prochaine série d'articles sera d'ailleurs dédiée à ce sujet). Cela dit, les équipes sont émancipées et totalement indépendantes lorsqu'il s'agit d'organiser leur travail et elles ne sont pas sous la tutelle d'un gestionnaire ou d'un exécutif avec la mission de livrer des requis venant "d'en haut" ou de "la business".

Avec la mise en place des Objectifs Produits, indiquant que le Propriétaire Produit n'est plus seulement en charge du backlog mais bien aussi de la définition des résultats. le Scrum Master qui voit ses responsabilités étendues avec l'imputabilité de la performance de l'équipe, Scrum version 2020 s'assure que l'équipe puisse fonctionner de manière complètement autonome, seul moyen de garantir son indépendance et donc de pouvoir réaliser son émancipation.

Et vous d'ailleurs, pensez-vous faire partie d'une équipe émancipée? Avez-vous parfois l'impression que les requis "arrivent d'en haut" sans que vous puissiez vraiment y faire quelque chose? Avez-vous aussi cette impression de ne pas pouvoir mettre en place la solution sur vos clients mériteraient pourtant? Partagez vos expériences sur le fil de discussion Linkedin ou Twitter!