Guide Scrum 2020 #1 - Les 3 changements majeurs à connaître
Le nouveau guide scrum est sorti! Que faut-il en retenir? On vous dit tout ici!
Dans cette série d'articles qui se conclura par un podcast qui pourra également répondre à vos questions, j'aimerais vous parler du nouveau Guide Scrum qui a été mis à jour le mois dernier pour la première fois depuis 2017. Il y a en effet quelques changements importants qu'il est important de bien comprendre afin de pouvoir organiser au mieux nos équipes au quotidien et les aider à performer aussi bien que possible.
Un survol suivi de trois articles détaillés
Dans cet article, nous allons parcourir la mise à jour dans son ensemble. J'y vois en effet trois changements majeurs qui sont également la bienvenue pour bien comprendre l'évolution de Scrum et de l'Agilité. Je prendrai aussi le temps de revenir en profondeur sur ces différents sujets avec des exemples concrets de bonnes pratiques à mettre en place dans des articles dédiés. Vous ne voulez pas les rater? N'hésitez pas à vous inscrire à l'infolettre si ce n'est déjà fait!
1 - Ciao Agilité!
Un des sujets qui a rapidement fait jaser la toile, c'est la disparition du terme agilité du guide Scrum. Alors Scrum est-il toujours une approche agile? Ou même l'a-t-il jamais été?
Scrum n'a jamais vraiment demandé à être catégorisé comme Agile.
Saviez-vous que Scrum a été inventé et pratiqué avant l'écriture du Manifesto Agile et avant que l'agilité existe vraiment comme une approche moderne du développement logiciel? C'est important à savoir car en réalité, Scrum ne s'est jamais vraiment préoccupé de l'agilité. Dans le guide Scrum, bien que les mots "agile" et "agilité" ont complètement disparu, ils n'étaient présents qu'une fois dans la précédente édition et dans une contexte bien particulier: il s'agissait de sensibiliser le PO aux pratiques techniques qui sont considérées comme agile avec par exemple le Pair Programming ou le Refactoring.
Scrum et Agile sont concurrents
En revanche, le nouveau guide Scrum s'annonce une nouvelle parenté dans cette édition en s'associant explicitant au mouvement Lean. C'est très factuel et bienvenue comme le Lean se concentre sur l'amélioration continue et la suppression des inefficacités et autres gaspillages et Scrum est justement un cadre de travail qui se concentre sur l'amélioration continue grâce à ces principes d'inspection et d'adaptation.
Mais ça va plus loin et je vais ici mettre mon chapeau de direction. La guerre fait rage sur le marché de la transformation numérique. Et soyons directs, Scrum Masters et Coachs Agiles courent régulièrement après les même mandats. D'ailleurs les mêmes personnes vont souvent passer d'un titre à un autre en fonction du style de l'entreprise.
Alors quel est le problème? L'argent évidemment! ;-) Les mouvements Scrum et Agile sont devenus des industries profitables et actives économiquement. Les grandes firmes de conseil murmurent à l'oreille des CEOs sur l'importance de leur transformation agile pendant que sur le terrain les employés se spécialisent via les certifications. Agile Alliance, Scrum Alliance, Scrum.org, Project Management Institute, ils ont tous une certification pour vous et il ne faut pas être naïf, il est évident que le guide Scrum, édité par Scrum.org, va se positionner pour se faciliter la vie et essayer de prendre un maximum de distance vis à vis des autres joueurs.
L'Agile est sur une pente (trop?) glissante
Cette distanciation avec le mouvement agile est bienvenu. Avec l'arrivée ces dernières années des transformation numériques dans les grandes entreprises, c'est un nouvel eldorado qui s'est ouvert pour les firmes de conseil et les experts agile. À un point tel qu'on voit aujourd'hui émerger des processus et autres méthodologies agile qui sont simplement non-agile. Voire anti-agile. Le Frankenstein de l'agilité a d'ailleurs un nom: SAFe. Une aberration qui n'a jamais engendré une seule équipe de haute-performance. C'est un point important, car l'autre grand changement du guide Scrum 2020, avec la mise en place des Product Goals peut-être vu comme une attaque directe contre SAFe. Si vous utilisez SAFe, il vous est impossible d'appliquer Scrum version 2020. Juicy ;-)
2 - Le pari risqué des Objectifs Produit
Sujet cher à mon cœur bien sur pour moi qui viens du côté produit. C'est je pense la plus grosse mise à jour du guide. Le propriétaire produit (PO) qui jusqu'à présent avait seulement l'imputabilité sur la gestion du backlog doit maintenant avoir l'imputabilité et la liberté totale d'établir les Objectifs Produits qui vont permettre ensuite la construction et la priorisation du carnet de produit (backlog).
Le rôle de PO toujours aussi peu clair
C'est un défi pour la majorité des équipes et entreprises. Jusqu'à présent, le rôle le plus incompris et le moins bien exécuté est celui du PO. J'ai d'ailleurs très hâte de m'atteler à mon article Gestionnaire de Produit (PM) vs Propriétaire Produit (PO) car comme c'est très mal compris, chaque entreprise le fait un peu à sa sauce, pour le meilleur (parfois) comme pour le pire (souvent).
Le piège dans lequel d'innombrables équipes tombent est de confondre acteur et personnage. Personne et rôle. PO est un rôle, PM est une personne. Et il se trouve que dans les meilleures équipes, souvent le PM va jouer le rôle de PO. Dans la majorité des équipes, le rôle s'est transformée en personne. Et cette personne, juste avec son chapeau de PO, s'est retrouvée à gérer un backlog. C'est le problème des "administrateurs de backlog" qui se retrouvent alors en position d'exécutants. Oui ils gèrent le backlog comme ils veulent, mais tous les choix en amont sont faits par d'autres personnes. Et le PO finit alors en funambule qui essaye de jongler avec toutes les patates chaudes qu'on lui envoie de partout. Rarement efficace.
Scrum a toujours évité (avec raison) de dire comment faire la gestion de produit
Scrum se veut par nature aussi peu prescriptif que possible et tout comme Scrum n'a jamais indiqué comment le développement devait être fait et quelles pratiques devaient être appliquées, le guide Scrum veut aussi éviter de définir comment la gestion de produit doit être faite. Alors il faut voir l'ajout de ce nouvel artefact comme une très grosse décision de leur part. Cependant, c'est un pas logique et bienvenu pour travailler de la bonne façon et de se rapprocher de la haute-performance.
En effet, beaucoup trop d'équipes et d'organisations n'ont simplement pas de stratégie produit. Le backlog est une succession d'éléments souvent ordonné de manière à répondre à la demande la plus urgente d'une partie prenante, avant de répondre à la demande suivante d'une autre partie prenante etc. Le travail de l'équipe Scrum devient alors un patchwork de demandes variées et il n'est pas surprenant que les résultats d'affaires se font ensuite souvent attendre.
Les artisans du guide Scrum ont alors pu réaliser que juste gérer l'ordre du backlog n'est pas suffisant pour travailler efficacement. Il faut aussi pouvoir choisir le focus du backlog à une échelle supérieure à celle des épiques. Il fallait aussi une réponse à une des faiblesses du principe du backlog: il définit quoi faire et pourquoi mais il ne force pas à dire comment le succès de l'initiative sera mesuré. Le backlog se retrouvait donc seulement concentré sur le travail réalisé, l'output, en ignorant la valeur produite, l'outcome.
C'est le problème #1 sur lequel j'interviens et il n'est donc pas à sous-estimer. La mise en place des Objectifs Produits permet de répondre à cette problématique en forçant la définition des critères de succès en amont et de forcer l'équipe à s'inspecter et s'adapter vis à vis de l'impact du travail fourni et pas seulement la quantité de travail fourni. Saviez-vous que dans le monde de l'IT, 70% des fonctionnalités développées sont peu ou jamais utilisées? Notre industrie est un énorme gaspillage et la majorité du travail fourni ne sert en gros à rien.
Mais n'est-ce-pas un changement trop radical justement?
Se pose maintenant la question de la faisabilité de la mise en place des objectifs produits. Les niveaux d'évangélisation et de patience requis me semblent très élevés et c'est donc probablement une évolution qui va prendre du temps et qui va nécessité de la part des leaders sur le sujet de mener le combat sur deux fronts.
Le premier se situe au niveau tactique et des équipes. Si vous êtes dans une organisation qui a à la fois un PM et un PO, on va directement au clash puisqu'il y a justement de bonnes chances pour que le PM explique que c'est justement le cœur de sa mission que de définir les objectifs et la roadmap. On va se le dire, vous êtes probablement déjà dans une situation parfois conflictuelle depuis longtemps si vous utilisez ce schéma. Ou alors il y a clairement un décideur et un exécutant. Le Guide 2020 va mettre plus de pression sur ces systèmes en poussant les PO à prendre la responsabilité de la définition des objectifs. Il faut alors se rappeler que comparer PM et PO, c'est comme comparer un pompier et un arroseur. Le problème c'est avoir un pompier formé et mandaté à éteindre les incendies (PM) qui tombe face à une personne qui tient le tuyau pour éteindre le feu (PO). La solution efficace est bien sur de laisser le pompier faire son travail et de repositionner l'arroseur dans un rôle qui aura plus d'impact.
Le second défi se passe plus au niveau des leaders et gestionnaires. Il reste encore beaucoup trop d'organisations où les équipes Scrum sont au service "de la business" - ie les départements des ventes, des opérations ou du marketing qui font leurs demandes de fonctionnalités et attendent ensuite de voir les équipes techniques livrer le travail attendu. Bien qu'il soit massivement documenté que faire évoluer un produit selon les demandes des clients ou des ventes/opérations/marketing est la méthode la moins efficace d'augmenter la valeur du produit et d'une entreprise, comment se fait-il que ce phénomène soit encore si présent? Il y a deux raisons:
C'est contre-intuitif. "Je parle avec les clients tous les jours, c'est logique que je sois mieux placé à savoir quelle fonctionnalité développer!" Cet énoncé est erroné et il faut l'expliquer encore et encore. Non le vendeur ou le CEO ou un exécutif n'est pas le mieux placé pour savoir quoi faire car il n'est normalement pas expert de la technologie qui permet de construire une solution. Il ne peut donc pas définir la réponse au problème.
Ils sont en situation de domination. Les exécutifs et les ventes/opérations sont très souvent propriétaires des budgets. Trop souvent encore les équipes techniques sont vues comme un centre de coût. Alors pour les propriétaires des budgets, en particulier quand ce sont les départements qui génèrent le chiffre d'affaires de l'entreprise, il est tout naturel de payer les équipes techniques en échange de la livraison de quelque chose qui leur convient. Cela se fait souvent via la fameux business case qui définit ce qui sera livré en échange de la mise en place du budget. Personne n'est encore assigné à l'initiative que tout est déjà tout décidé. Impossible d'avoir du succès dans le Hi-Tech dans ces conditions.
Bref la mise en place des objectifs produits va permettre aux leaders de la transformation de mettre une certaine pression pour enfin pouvoir donner de l'autonomie aux équipes sur la meilleure façon de livrer de la valeur aux clients. Beaucoup, et en particulier dans les grandes organisations, pourront par contre voir cela comme un mur infranchissable et un changement utopique. Il faut évangéliser au plus haut niveau pour que cela marche, il n'y a malheureusement pas de secret. En attendant, chez Amazon, Google, Apple, Netflix et les autres, on se marre. Leurs équipes autonomes continuent à créer de la valeur plus vite que n'importe quelle autre entreprise et à accroître leur avance sur le reste du monde. Pour le meilleur comme pour le pire.
3 - Le Scrum Master 2020 dans la situation du PO!
Dernier changement majeur que je souhaite aborder aujourd'hui avec ce nouveau Guide Scrum 2020: l'évolution du rôle de Scrum Master. Je considère ce changement comme moins radical que celui des objectifs produits mais c'est en fait mon changement préféré car c'est un pas dans la direction d'une prédiction que je fais depuis longtemps: le Scrum Master en tant que personne va disparaître. #popcorn ;-)
Self-Managed & Accountable, le coup de pied dans la fourmilière
C'est écrit noir sur blanc: L'équipe Scrum passe de auto-organisée à auto-gérée. De plus, le Scrum Master devient imputable de la performance de l'équipe Scrum.
J'imagine déjà les cauchemars de certains gestionnaires qui, après avoir patiemment expliqué à leurs équipes qui voulaient les mettre dehors qu'elles étaient seulement auto-organisées et non pas auto-gérées, vont devoir gérer les nouvelles attentes de "liberté" de leurs équipes parce que oui, en 2020, c'est officiel, on est enfin auto-gérés!
De l'autre côté du spectre, le Scrum Master a aussi de quoi stresser. Comment ça il est responsable maintenant de la performance de l'équipe? Ou est passé le principe de guide qui accompagne les équipes en prenant toujours bien soin de leur laisser faire leurs propres choix?
Derrière cette apparente promesse de chaos, il y a en fait une décision brillante qui aidera énormément les équipes. Mais retournons d'abord deux secondes à la théorie de Scrum.
Après PM vs PO, bienvenue dans l'ère du TL vs SM
Pour bien comprendre ma conclusion, il faut d'abord bien comprendre le guide Scrum. Tout comme il n'a jamais été écrit dans le guide Scrum que le PO était une personne, mais bien un rôle qui devait être pris par quelqu'un, c'est la même chose pour le Scrum Master.
Il est écrit nul part que le Scrum Master doit être une personne dédiée et il est bien écrit que c'est un rôle qui doit être assigné à quelqu'un dans l'équipe Scrum. Ça peut être un développeur. Ça peut être la réceptionniste. Ça peut être le gestionnaire de produit. Il s'agit bien de choisir la personne qui pourra accomplir la mission de la meilleure façon possible, en ayant les compétences et le temps nécessaire à la bonne exécution des activités attendues.
Dans les entreprises qui n'ont pas assimilé ces concepts, tout comme elles se retrouvent avec des PM et PO qui se marchent sur les pieds, elles vont se retrouver avec des Scrum Master qui vont se marcher sur les pieds avec leurs Tech Lead (le gestionnaire de premier niveau qui gère les développeurs, il est peut-être nommé différemment dans votre organisation). En effet les deux vont se retrouver responsables/imputables de la bonne gestion de l'équipe et de la performance de l'équipe.
Une solution brillante quand le TL devient SM
Je pense que ce recouvrement entre responsabilités du gestionnaire de développement (TL) et Scrum Master (SM) est fait en toute connaissance de cause même s'ils ne l'ont pas dit clairement. L'exemple des leaders de l'industrie et la recherche en gestion disent en effet la même chose: Dans une équipe performante, la première des responsabilités du manager est de coacher les membres de son équipe et de développer leur potentiel. Suivi ensuite du recrutement et de la gestion de la stratégie.
Seul problème, aujourd'hui trop peu de managers sont déjà passés dans cette modernité et beaucoup trop pensent encore que leur rôle est de jouer au policier ou d'assigner mécaniquement des tâches. Deuxième scénario commun, le manager offre seulement un coaching technique et n'est pas intéressé/formé à maximiser la dynamique d'équipe. C'est cependant bien ce critère qui est évalué en premier quand on devient manager dans une entreprise comme Amazon ou Netflix. Si vous êtes le meilleur techniquement mais que vous n'êtes pas capables de mettre en place l'environnement qui permettra à toute votre équipe de performer, vous ne serez pas gestionnaire.
Être gestionnaire d'une équipe logicielle de haute-performance passe forcément par jouer le rôle défini dans ce guide 2020: Vous devez prendre la responsabilité de la performance de votre équipe, vous devez la coacher et développer les talents et la dynamique au maximum et vous devez vous assurer que l'équipe possède toutes les compétences nécessaires pour mener à bien sa mission. Et quand le manager devient le Scrum Master et fait partie de l'équipe Scrum, et bien, l'équipe devient techniquement auto-gérée! Brillant. D'ailleurs, pour revenir à mon cycle d'entrevue des dernières semaines, 80% des CTOs/Tech Lead que j'ai interrogé m'ont confirmé ne pas avoir de Scrum Master dédié dans leur équipe la plus performante. La formation et la proactivité des développeurs et des leaders (TL & PM) faisant avant-tout la différence.
Un impact économique non-négligeable
Pour conclure, on voit que ce Guide Scrum va probablement pousser les équipes vers de nouvelles topologies. Et ces nouvelles formes d'équipes ont un impact économique important. Prenons une équipe qui aujourd'hui a 1 PM + 1 PO + 1 Designer + 6 Devs + 1 TL + 1 SM = 11 personnes. Si les organisation sont incitées à fusionner PM + PO et TL + SM nous allons arriver vers des squads livrant plus de valeur avec 2 personnes en moins. C'est potentiellement 20% de réduction de coût ou alors une opportunité d'augmenter la productivité de l'ingénierie de 33% en remplaçant ces personnes par des développeurs supplémentaires. Majeur.
À ceux qui trouveraient ces calculs irréalistes, ou qui pensaient que ces rôles fusionnés de PO/PM et TL/SM sont utopiques, je me permettrai de vous renvoyer vers les sections carrières d'Amazon, Google, Apple ou Netflix. Vous n'y trouverez aucun poste de PO ou de Scrum Master alors que les transformations numériques/agiles sont faites pour essayer de leur ressembler un peu plus. Il est peut-être temps de vraiment comprendre ce qui font leur succès pour l'appliquer à nos équipes.
Des questions ou des commentaires? Rejoignez la discussion sur Linkedin!
