Les améliorations du guide Scrum en 2020

Bonjour ! Je suis ravi de vous accueillir dans ce podcast dans lequel on va analyser ensemble les changements apportés au guide officiel Scrum. C'est une très belle occasion de renforcer notre maîtrise de Scrum en allant bien au delà du simple inventaire de ces améliorations et en allant justement un peu en profondeur dans l'analyse de ces changements apportés. 

Alors je me présente bien sûr, je suis Florent LOTHON, je suis l'auteur du site L’Agiliste et je fais partie des pionniers dans l'utilisation de Scrum sur des projets à forts enjeux sur la France.

Quelques précisions juste avant de commencer. D'une part le discours que je vais adopter se veut accessible quel que soit son secteur d'activité. C'est un point important, c'est un point sur lequel j'essaye d'être très vigilant déjà depuis pas mal d'années. Mais là ça prend encore plus de sens avec les évolutions comme on va le voir dans un instant, les évolutions apportées au guide Scrum.

En termes de prérequis, évidemment c'est mieux si vous avez déjà une connaissance minimum de Scrum même si on va aborder des concepts qui sont assez universels et qui peuvent être finalement appréhendés aussi indépendamment de Scrum. J'ai repris aussi, pour rendre à César ce qui est à César, des propos tenus par les créateurs de Scrum et leurs collaborateurs, des propos qu'ils ont tenu lors de la conférence officielle qui a été organisée pour présenter ces améliorations et fêter par la même occasion les 25 ans de Scrum.

En termes de déroulement va passer en revue les différentes améliorations et rentrer dans l'analyse de chacune, comme je vous le disais. On va prendre aussi un peu de hauteur pour comprendre en quoi cette évolution du guide s’inscrit et je terminerai en vous donnant mon point de vue personnel et une anecdote à propos du guide.

Alors juste pour commencer, en quoi le guide s'est amélioré ? déjà là dans les grandes lignes. En fait, la première amélioration notable, c'est qu'on ouvre officiellement le guide aux autres secteurs d'activité même si c'était déjà une réalité depuis longtemps dans l'usage. Là - vous allez voir, je vais vous expliquer en quoi ça fait la différence - on va avoir une ouverture plus grande à tous les secteurs d'activité. Au delà de celui du développement logiciel qui est le secteur d'origine de Scrum et des méthodes agiles plus largement. On est aussi sur un guide qui est plus concis. Sur sa version en anglais par exemple on passe de 18 pages à 13 pages, ça rend évidemment la lecture plus facile. Et on est aussi sur un guide à la fois plus explicite pour éviter les erreurs d'interprétation qui se traduisent malheureusement très souvent en erreurs d'implémentation et donc les résultats parfois peuvent ne pas être au rendez vous. Et on est aussi sur quelque chose de moins prescritif. Et l'avantage c'est que ça va nous donner davantage de flexibilité sur les modalités de mise en oeuvre. 

Et une bonne nouvelle au passage, c'est que ces changements ne font qu'expliciter davantage ce que font déjà les bonnes équipes Scrum. Pour celles-ci il n'y a pas besoin de tout changer, on n'est pas en train de révolutionner Scrum et de s'y prendre totalement autrement qu'avant. Non, on continue sur les fondamentaux de Scrum. Il n'y a pas besoin de suivre une nouvelle formation, d'acheter un nouveau bouquin. Ce podcast à la limite peut largement suffire.

Si on rentre maintenant dans la liste des améliorations. Première amélioration notable comme je le disais c'est l'ouverture à tous les secteurs. Encore une fois ça officialise une réalité, on s'ouvre à tous types d'organisations, d'entreprises, d'associations à but non lucratif, etc. Quelle que soit la taille de l'entité, au sein d'une entreprise ça peut être un département, une équipe, ou toute l'entreprise.

En termes de définition du mot produit. C'est vrai que c’est un mot qu'on utilise très souvent dans l'agilité et sur Scrum en particulier. Ce que le guide explicite notamment, c'est ce qu'on entend par produit, ça peut aussi bien être un produit physique, qu'un service, ou même quelque chose de plus abstrait. Il y a même des gens, pour l'anecdote, qui utilisent Scrum pour organiser leur mariage et ils ne sont pas complètement fous. C'est assez intéressant de voir tous les cas d'utilisation possibles quasi illimités de Scrum.

Le terme "développeur", lui a été conservé. L’idée c'est de percevoir ce terme non pas comme un développeur au sens "programmeur", "codeur" et "développement logiciel" mais comme un terme générique pour englober tous les secteurs. Pas uniquement du coup les programmeurs de logiciels. Cela inclut par exemple les personnes qui développent une stratégie marketing dans une entreprise ou qui développent des processus RH par exemple pour prendre des exemples très éloignés du développement logiciel. Mais je reviendrai sur l'utilisation de ce terme à la conclusion. On a aussi du coup des termes qui ont été abandonnés justement dans cet esprit de sortir un peu d'un vocabulaire trop "informatique", trop "développement logiciel". Les termes release et système par exemple ont été retirés et il y en a peut être d'autres mais c'est juste pour vous donner un exemple sur cet objectif là de s'ouvrir.

Sur le côté moins prescriptif  ce qui est intéressant c’est que le guide Scrum nous rappelle que Scrum n'est pas une méthode, c'est un cadre, un cadre par définition c'est ce qui le rend plus simple, plus léger, plus adaptable et c'est aussi ce qui contribue à le rendre plus difficile à maîtriser puisque Scrum ne vous donnera pas les réponses à toutes vos questions. Au contraire il va plutôt vous donner les moyens de trouver les réponses. C'est d'ailleurs JJ Sutherland, le fils de Jeff Sutherland (Jeff Sutherland étant l'un des deux créateurs de Scrum) qui a cette formule : « l'agilité n'est pas la solution à vos problèmes, c'est le moyen de les résoudre ». C'est bien comme ça qu'il faut interpréter Scrum et donc dans le guide on va trouver par exemple la phrase « le framework scrum est délibérément incomplet. Divers processus, techniques et méthodes peuvent être employées au sein de ce framework » (donc ce « cadre » pour ceux qui n'aiment pas trop les termes anglais ou qui ne sont pas à l'aise avec, on pourrait aussi traduire ça par cadre de travail) « Scrum englobe les pratiques existantes ou les rend inutiles ». Donc à l'intérieur de ce cadre on peut y mettre des pratiques, des techniques, des outils.

Et on est aussi moins prescriptif sur la façon de mener chacun des évènements Scrum. Par exemple un changement marquant qui fait beaucoup parler, c'est la suppression des trois questions au moment de la mêlée quotidienne. On avait trois questions qui étaient du genre "Qu'est ce que j'ai fait hier qui a aidé l'équipe à atteindre l'objectif du sprint ? Qu'est ce que je vais faire aujourd'hui qui va aider l'équipe à atteindre l'objectif du sprint ? et Quels obstacles je pressens ou je rencontre ou je constate qui peuvent nous éloigner de l'objectif du sprint?". Ces questions ont été supprimées parce que le constat est qu'une fois qu'une équipe s'est complètement approprié Scrum et en particulier la mêlée, très souvent ces questions on les oublie totalement.  Pour autant la mêlée prend une forme très fluide, très efficace quand l'équipe a vraiment réussi cette bonne appropriation avec sa propre façon de mener la discussion.

Et à titre d'exemple il y a un coach agile qui s'appelle Scott DOWNEY qui a eu une initiative assez intéressante. A un moment donné pour une équipe, il a simplifié et il a dit « Bon bah voilà la question à la mêlée finalement c'est celle ci : pourquoi est ce que cette story (donc la story c'est un élément du Product Backlog qu'il faut réaliser) n'est pas terminée et comment pouvons nous mettre un maximum de membres de l'équipe dessus pour la terminer maintenant ? ». C’est la seule question et quand l'équipe a fini de répondre à cette question là, c'est que la mêlée est terminée. C'est hyper intéressant parce que du coup, elle a choisi une autre question que les trois proposées et à sa façon, et dans son contexte à elle, a réussi à décupler l'efficacité et la productivité de l'équipe notamment à travers la mêlée qui est quand même un élément névralgique dans scrum.

Donc voilà du coup une anecdote au passage associée à cette question et donc pour les non initiés, juste pour revenir cette histoire de Story, c'est un élément qui est constitutif du produit à réaliser. C'est un peu l'équivalent d'une fonctionnalité. Pour un produit physique par exemple, si on réalise un appareil photo à un moment donné, peut être qu'on devra réaliser une fonctionnalité anti yeux rouges, donc on va avoir une story qui correspond à cette fonctionnalité anti yeux rouges sur notre appareil photo. Voilà juste pour les non-initiés.

Alors ça c'est pour le côté moins prescriptif. Je vous ai donné l'exemple de la façon dont la mêlée quotidienne a été décrite dans le guide de Scrum et allégée du coup de ces trois questions en laissant du coup toute liberté aux équipes pour trouver la façon dont - avec l'aide du Scrum Master - la mêlée peut être animée et rendre le service qu'on attendait en terme d'organisation du travail de la journée. Et surtout d'atteindre l'objectif du sprint.

Ensuite sur le côté plus explicite, un des changements consiste à remplacer le terme "vision produit "par "l'objectif du produit". C'est assez subtil comme changement. On considère simplement que l'objectif du produit va être un peu plus parlant que le terme "vision" qui est un peu vague.

Et c'est vrai qu'un des écueils qu'on rencontre souvent c'est qu'on va avoir tendance, quand on se lance dans l'agilité, à faire un peu comme on fait sur la façon classique de gérer les projets, c'est qu'on se focalise souvent très vite sur le budget et le délai. Donc les aspects purement « projet » plutôt que sur le produit en soi. C'est évidemment un écueil. Alors cela ne veut pas dire évidemment que le budget et le délai n'ont pas d'importance. C'est même tout le contraire. Mais Scrum ne consiste pas simplement à mettre tous les besoins dans une liste et les réaliser. Le but c'est d'utiliser Scrum pour aller quelque part, pour délivrer quelque chose, pas juste "faire quelque chose". Donc en mettant plutôt l'emphase sur l'objectif produit plutôt que la vision, même si la vision avait déjà ce même rôle d'expliciter ce travail à faire sur la vision produit en amont, l'objectif produit a ce mérite d'être un peu plus explicite sur ce qu'il y a à faire. Ça permet d'ailleurs d'être plus explicite sur ce qu'il y a à faire.

Ça permet à chacun de savoir dans quoi il s'inscrit et de s'aligner sur un objectif commun, lui même aligné avec la stratégie de l'entreprise ou de l'association si on est une association à but non lucratif par exemple. Et cela permet à chacun de pouvoir prendre des initiatives qui servent cet objectif mais aussi de s'en nourrir comme un challenge, un défi à relever, comme une source de motivation et d'engagement, en ayant une réponse claire à la question « finalement pourquoi contribuer à la réalisation de ce produit ? ». Un bon produit, finalement ça doit résoudre un problème et on augmente ainsi du coup le niveau de transparence sur l'objectif global visé avec un objectif clair.

On parvient également plus facilement à distinguer les éléments utiles à réaliser directement liés à l'objectif des éléments qui seraient moins utiles, ça aussi c'est intéressant pour se focaliser. L'équipe est du coup mieux focalisée sur les tâches qui apportent réellement de la valeur. Le terme objectif ou « objectif produit », il a le mérite d'être plus explicite encore une fois, plus concret, plus inspirant que celui de "vision produit". Et j'expliquerai tout à l'heure comment son importance a été renforcée par ailleurs dans les guides. Et autre citation au passage, cette fois de Jeff Sutherland, un des deux créateurs de Scrum, il racontait, je ne vais pas rentrer dans le détail de l'anecdote mais il racontait qu'à un moment donné, il était intervenu pour un client avec des problèmes d'équipe de développement qui n'étaient pas engagées et qui partaient tôt dans l'après midi. Qui faisait le job mais sans plus. En fait le diagnostic qui a été posé, c'est que c'était des équipes qui n'avaient pas un bon objectif et ce que Jeff Sutherland racontait c'est qu'un bon développeur, c'est un développeur qui ne bosse pas sans objectif. J'ai trouvé cette anecdote assez intéressante à partager. Donc finalement l'objectif produit, ça devient l'étoile du nord de l'équipe Scrum. Ou la cathédrale à construire, si je prends cette métaphore qu'on utilise souvent : quand un tailleur de pierre sait qu'il contribue à construire une cathédrale il met beaucoup plus d'énergie qu'un tailleur de pierre à qui on a juste dit : « Ben, taille des pierres, c'est ton boulot, c'est ce qu'il y a à faire » et qui ne sait pas à quoi il est en train de contribuer en taillant des pierres. Il sait juste qu'il taille des pierres. Donc ça peut faire toute la différence sur le tailleur de pierre en question, sur son énergie, son envie d'y aller, sa capacité à être force de proposition, sa proactivité, etc.

Alors c'est quoi un bon objectif de produit du coup ?

Il y a des exemples qui ont été communiqués pendant la conférence que je trouve pas mal. Par exemple une entreprise qui réalise un produit qui s'adresse à des gens, c'est quand même l'idéal, peut avoir pour objectif de « viser 10 000 utilisateurs de plus ». On pense tout de suite à des applications sur  smartphone mais ça peut être n'importe quoi d'autre. C'est un exemple d'objectif.

L'avantage c'est que c'est concis, c'est spécifique au contexte, c'est mesurable, c'est réaliste, c'est tangible, ça c'est un bon objectif.

Je vous donne d'autres exemples : "améliorer la satisfaction des clients mesurée par le Net Promoteur Score, le NPS". Voilà encore un exemple, un exemple cette fois métaphorique : "perdre 10 kilos avant l'été" et là la question qui est intéressante à poser à ce moment là, c'est pourquoi on veut perdre 10 kilos avant l'été ? C'est là où le pourquoi va donner du sens. Peut être que c'est pour avoir une belle silhouette sur la plage cet été.

Du coup en ayant cet objectif produit on peut plus facilement décliner l'objectif du premier sprint qui pourrait être par exemple : "réduire de moitié sa consommation d'alcool". Là encore on est sur une chose de mesurable qui s'inscrit dans l'objectif produit et qui est tangible, spécifique, mesurable, concis et qui laisse de la souplesse sur le contenu associé dans le sprint puisque peut être qu'on ne va pas traiter que l'alcool, on va faire d'autres choses, mais en tout cas on va se focaliser sur l'atteinte de l'objectif lié à l'alcool si c'est l'objectif du sprint.

« Payer nos fournisseurs en moins de trois jours » ça c'est un exemple que je trouve intéressant aussi en cette période de COVID. Aujourd'hui il y a beaucoup d'entreprises qui sont en risque, voire même qui sont déjà mortes avec cette crise COVID. Je souligne d'ailleurs au passage que je pense pouvoir dire que les entreprises qui sont agiles ont déjà beaucoup plus de chances de survivre que les autres en termes de capacité d'adaptation, de capacité à pivoter et donc là je trouve que l'objectif produit qui consiste à se donner les moyens de payer nos fournisseurs en moins de trois jours, c'est extrêmement intéressant. Pareil, c'est mesurable et ça permet effectivement de limiter la casse de payer les fournisseurs les plus fragiles en priorité. Et peut être justement que le premier sprint consistera à payer les fournisseurs les plus fragiles en priorité. Là encore avec cet objectif on voit bien que cela va nous permettre - au delà de nous donner du sens à notre boulot, c'est vrai que ça a beaucoup de sens de sauver des entreprises et la nôtre au passage - de déterminer plus facilement l'objectif du sprint. Et ensuite à l'intérieur du sprint, si on a du retard, de distinguer plus facilement ce qui est important et qui s'inscrit directement dans l'objectif de ce sprint, du reste.

Alors un mauvais objectif à l'inverse, ça va être un objectif qui peut par exemple fusionner des tas de sous objectifs. "Voilà ! l'objectif du sprint c'est de faire ça + ça + ça + ça". En fait on est en train de faire la liste des éléments du Product Backlog qu'on a retenu dans le sprint, plus ou moins maquillés. Mais évidemment on est sur quelque chose qui n'est pas concis même sil est peut être mesurable et spécifique. Mais c'est certainement beaucoup moins impactant, motivant et ça ne va pas du tout nous aider à nous focaliser sur ce qui est important véritablement.

Une autre anecdote aussi qui a été partagée, c'est un autre exemple de sprint ou de produit : c'était une équipe qui réalise des smartphones entièrement hardware, aucun software à leur main. Le software c'est souvent d'autres équipes qui le réalisent. Google, Apple pour ce qui est iOS, etc. Et donc là pour l'objectif du sprint, ce qui a été déterminé, c'est un exemple, c'était d'augmenter la performance de 10%. Donc là, pareil : concis, spécifique, réaliste, tangible.

Ensuite sur l'objectif de sprint et la planification de sprint là. Ce qui est intéressant c'est que grâce à l'objectif produit on va chercher cet alignement avec l'objectif de sprint. Comme je le disais, c'est ce qui va nous permettre de rester focus et c'est là où on va pouvoir se dire "Non on doit aller là ! Ça c'est l'objectif produit ! Maintenant où est-ce qu'on va demain pour s'en approcher ?". C'est là où je prenais l'exemple du l'objectif consistant à perdre 10 kilos : je vais commencer par réduire la consommation d'alcool. Donc les objectifs produits, je relis mes notes... les objectif du produit et de sprints permettent aussi de mieux mesurer les résultats du travail effectué. Effectivement, encore une fois, c'est un moyen d'augmenter la transparence et d'expliciter ce qu'il y a à faire d'aligner tout le monde. Effectivement, plus on a un objectif clair, plus on peut plus facilement mesurer les résultats qu'on a atteint aussi bien à l'échelle du sprint que du produit. Le produit étant sûrement le fruit de plusieurs sprints.

Autre changement cette fois sur la planification de sprint en soi, c'est qu'on a rajouté un élément ou deux éléments qui étaient déjà là. C'était le quoi et le comment, c'est à dire "quels éléments je sélectionne ?", "Comment je donne vie à ces éléments pour en faire un incrément utilisable et potentiellement livrable ?". Ou "des incréments", je vais revenir d'ailleurs sur cette notion là plus tard. On a rajouté le "pourquoi", pourquoi on va faire ce sprint ? quel sens il a ? pourquoi ce sprint est important ?.  

Si on se contente de déterminer ce qui peut être fait pendant le sprint et comment, on peut oublier de se demander pourquoi ce sprint est important. Et définir du coup un mauvais objectif de sprint, donc c'est pour ça que c'est intéressant d'avoir rajouté ça. Là encore on est sur quelque chose de plus explicite. Grâce à cette troisième question ajoutée qui est souvent la première à se poser quand même, mais c'est du coup une troisième question ajoutée aux deux qui existaient déjà. Et du coup, par la même occasion, quand on répond à cette question là, on facilite aussi le travail de planification de sprint puisque c'est beaucoup plus facile une fois qu'on a répondu à la question "pourquoi ?" de choisir le "quoi" et ensuite évidemment de travailler sur le "comment". 

Ensuite autre changement notable c'est la notion d'engagement. Ce guide renforce la notion d'engagement sur Scrum. C'est assez intéressant, d'abord ça se traduit sur chaque rôle. Par exemple les développeurs ont pour redevabilité le fait d'instiller la qualité en adhérant à une définition de terminer. C'est un engagement qui est quand même fort. Le Product Owner a pour redevabilité de définir et communiquer explicitement l'objectif du sprint et le Scrum Master - je prends des exemples je ne donne pas toutes les redevabilité de chaque rôle mais je donne des exemples - pour ce qui est du Scrum Master, sa redevabilité, c'est de mettre en œuvre Scrum dans le respect du guide Scrum et il est également redevable ou le garant de l'efficacité de l'équipe Scrum. Voilà un changement intéressant. Ils sont tous intéressants mais celui là a quand même un poids qui n'est pas négligeable.

La redevabilité -  attention aux subtilités des termes employés - n'empêche pas de déléguer la responsabilité. Mais par contre si le boulot n'est pas fait ou mal fait, celui qui reste redevable c'est celui qui a délégué. Par exemple le Product Owner, il a aussi parmi ses autres redevabilité, il est aussi redevable de la création et de la clarté de la communication des éléments du Product Backlog. Il peut déléguer cette responsabilité au besoin mais il sera toujours redevable.

Ensuite il y a un truc aussi intéressant, c'est que ça soulève à nouveau une question qui revient assez souvent donc j'en profite pour enfoncer une porte ouverte : qu'est ce que ça veut dire... alors j'allais employer le terme "équipe de développement" mais vous allez voir que cette notion vient de disparaître aussi, donc je reformule : pour les développeurs, ça consiste en quoi de s'engager par exemple sur un objectif du sprint ? Et la réponse qui est faite - par Jeff Sutherland de mémoire qui a rappelé ça - c'est qu'en fait : on s'engage à rester concentré sur l'objectif de sprint. Quoi qu'il en coûte. Autrement dit on ne va pas se laisser distraire par "Ah ouais ! Il y a aussi ça à faire" ou "Ça serait génial de faire ça !", etc. Toutes les distractions aussi bien externes et internes qui pourraient nous éloigner de l'objectif du sprint. Donc l'engagement que prennent les développeurs, ne poste pas sur "On va faire tant de points, tant de jours/hommes ou d'unité d'œuvre", ce serait assez stupide de s'engager là dessus puisqu'il y a des tas d'imprévus qui peuvent arriver. Les estimations ça reste des estimations. Elle sont fausses par définition. Personne ne peut garantir ça. Même si la durée des sprints est très courte. Évidemment on va tout faire pour réussir à faire tout ce qu'on avait prévu de faire, mais la quantité importe moins que la valeur qu'on va créer et du coup l'atteinte aussi en particulier de l'objectif du sprint. Si l'objectif est atteint mais qu'on n'a pas tout fait, c'est toujours mieux que tout faire et avoir "foiré" l'objectif du sprint (pour parler franchement, parler avec des termes un peu directs).

Ensuite ce qui se passe c'est que l'on a rajouté aussi des engagements associés à chaque artefact pour mieux garantir la transparence et cette capacité à se focaliser sur ce qui est important au niveau de l'équipe. Donc au Product Backlog est associé désormais - officiellement on va dire et en termes d'engagement du coup - l'objectif produit. Il faut absolument un objectif produit associé au Product Backlog. Un objectif de Sprint est associé/rattaché au Sprint Backlog. Et une définition déterminée est associée/rattachée à un incrément. Donc ça c'est une bonne chose évidemment d'avoir encore plus explicité tout ça. Là encore, tout ça était déjà présent  dans le guide, c'est juste que là on met davantage d'engagement dessus.

Ensuite il y a des changements sur le leadership du Scrum Master en particulier.

Avec notamment un écueil qu'on rencontre parfois, c'est que le Scrum Master peut vite devenir le "secrétaire" de l'équipe Scrum. Et ça, ça peut être lié à un terme qui était dans le guide Scrum, en tout cas plutôt à une interprétation, à une mauvaise interprétation de ce terme. Dans l'ancienne version du guide on parlait de posture de "servant leader", "le Scrum Master est un servant leader". Autrement dit, ce que l'on pourrait traduire par - mais franchement les traductions ne sont jamais idéales - "leader serviteur". A ne pas confondre avec le leader "carpette" ou leader "secrétaire" puisque ça, ça ne ferait qu'amener à déresponsabiliser les autres membres de l'équipe Scrum et même le Scrum Master avec eux. Et évidemment ce n'est pas du tout la philosophie et les valeurs de Scrum ou de l'agilité au sens large. Avec un Scrum Master qui se retrouverait à prendre des notes en mêlée sans intervenir et qui lève un maximum d'obstacles y compris des obstacles très opérationnels que l'équipe pourrait apprendre à lever elle même. Ou pire, ils se retrouvent à rédiger la documentation et les tests à la place du reste de l'équipe. Voilà, ça c'est pas du tout le but, alors que l'objectif est plutôt d'optimiser l'efficacité de l'équipe et d'assurer une bonne compréhension de Scrum par l'organisation. Et tout ça, ça prends déjà pas mal de temps, donc c'est là dessus qu'il doit se concentrer. Il n'est pas là pour faire la secrétaire de l'équipe.

Autre subtilité dans le guide, au delà de l'abandon de ce terme "servant leader", c'est le fait qu'on a reformulé, alors là ça se joue sur un mot : "Le Scrum Master cause la levée des obstacles freinant la progression de l'équipe Scrum" alors qu'avant on disait "Le Scrum Master retire les obstacles" comme s'il devait le faire lui même. Mais non. Alors effectivement certains obstacles vont peut être relever du Scrum master, des obstacles sur lesquels ce serait vraiment stupide que soit l'équipe qui s'y colle. Peut être parce qu'il faut bénéficier d'un niveau hiérarchique vis à vis de l'organisation pour avoir suffisamment d'influence et c'est d'ailleurs pour cette raison que Scrum Master est souvent un ancien chef de projet (avec un peu de galon). Ou parce que parfois pour certains obstacles, il n'y a franchement aucun intérêt qu'ils soient levés par les développeurs. A l'inverse, il y a des obstacles purement opérationnels et techniques sur lesquels c'est beaucoup mieux que ce soit l'équipe elle même qui se mettent en tête et se donne les moyens de les résoudre. D'ailleurs il y a des outils fait pour ça comme la rétrospective notamment.

Sur ce sujet là du Scrum Master, je fais quand même un petit aparté là dessus parce que c'est vraiment un sujet important dans la conférence. Jeff Sutherland a pris deux exemples pour illustrer ce que lui il entendait par Scrum Master. Il a pris le premier exemple en évoquant le film Invictus. Je ne sais pas si vous l'avez vu mais dans ce film là, on voit la victoire de l'équipe sud africaine face aux All Blacks. Avec un entretien qui a eu lieu entre Nelson Mandela qui était alors président et le capitaine de l'équipe Springboks, l'équipe sud africaine. Et il (Jeff Sutherland) compare le Scrum Master à ce capitaine d'équipe. La comparaison se situant dans le fait qu'un capitaine d'équipe de rugby en particulier est sur le terrain, il se place au même niveau que les autres membres de son équipe. Il prend les coups, quand il y a des coups à prendre et il montre l'exemple. Il va au front quand il faut aller au front et du coup c'est ça qui fait qu'on a envie de le suivre. C'est comme ça que cette équipe a battu la meilleure équipe au monde. Les All Blacks.

J'ai trouvé que ce parallèle était intéressant. Et ce que Jeff Sutherland a ajouté, c'est qu'on compte déjà beaucoup d'équipes Scrum qui ont déjà réalisé des choses qui semblaient impossibles. Grâce à cette posture managériale notamment. Et il ne faut pas oublier non plus que le leadership vient aussi en grande partie du Product Owner puisque c'est lui qui porte la vision du produit. C'est lui qui donne le plus de sens au travail qu'il y a à faire avec les objectifs du produit. Les objectifs de sprint. Mais il y a aussi ce leadership exercé par le Scrum Master bien évidemment. Chez Toyota, le parallèle le plus intéressant, le plus proche du rôle de Scrum Master - et évidemment Scrum et les méthodes agiles s'inspirent largement du Lean management issu de Toyota - c'est lié à un des changements apporté pour changer d'approche chez Toyota consistant à remplacer le manager au sens classique par ce que l'on va appeler le facilitateur qui connaît tous les métiers et peut former chacun pour aider l'équipe à réussir. C'est bien ça l'idée, c'est que je suis plus hiérarchiquement au dessus des autres, je me place au même niveau des autres avec quand même un savoir faire que je peux transmettre et je mets mon pouvoir au service de la réussite de l'équipe. Mon pouvoir et mes compétences bien évidemment. Et l'objectif du Scrum Master, c'est de gérer d'un côté la hiérarchie, l'organisation, aussi bien que de faciliter le travail de l'équipe. Sur la mêlée par exemple, l'objectif ce n'est pas de prendre des notes et ne rien dire, mais c'est de trouver le moyen de faire en sorte que la mêlée permette à l'équipe d'atteindre l'objectif du sprint.

Voilà je referme cet aparté sur le rôle de Scrum Master et la posture managériale associée. Pour aller vers un autre changement qui est important : c'est la décorrélation du rythme des sprints et du rythme des livraisons. Je pense notamment à cette notion de livraison continue ou Continuous Delivery permettant de faire des livraisons plusieurs fois pendant le sprint. Ou à l'inverse sur certains projets - peut être sur des produits physiques par exemple - on ne peut livrer que le fruit de plusieurs sprints, donc il faut vraiment décorréler. C'était déjà une réalité pour ceux qui pratiquent déjà Scrum correctement. Mais là, ça a le mérite d'être davantage explicite.

Donc plusieurs incréments peuvent être créés pendant un sprint et c'est la somme des incréments qui est présentée lors de la revue de sprint et par ailleurs un incrément peut être fourni aux parties prenantes avant la fin du sprint. Si ça a du sens et qu'on est en mesure de le faire. La revue de sprint ne doit pas être - c'est ce que dit le guide - ne doit pas être considéré comme le seul élément déclencheur pour livrer de la valeur. Le guide dit plus précisément : "... ne doit pas être considérée comme la porte pour livrer de la valeur". Et si je reprends un extrait à ce sujet du guide : "Au moment auquel un élément du Product Backlog répond à la définition de terminé, un incrément est né". Voilà ! tout simplement ! Je trouve que c'est une belle formule.

Ensuite sur la collaboration et le "self management" pour reprendre le terme anglais. L'auto management. Il y a un premier changement assez important là encore qui a été fait. Il n'y a plus, comme je le disais un peu avant, de notion d'équipe de développement. Il n'y a plus qu'une équipe, c'est l'équipe Scrum, qui compte des développeurs, encore une fois au sens générique du terme "développeurs" et non pas au sens "programmeur", le Product Owner et le Scrum Master. Tout ça forme une seule et même équipe Scrum.

Ce qui évite l'écueil qui consisterait malheureusement dans certaines équipes à basculer dans une relation client fournisseur, avec le Product Owner qui est le client et l'équipe de développement qui délivre ce que a demandé par le client. En faisant ce changement, le but c'est de renforcer la cohésion entre le Product Owner et le reste de l'équipe Scrum, tout en renforçant la responsabilité collective avec une seule équipe alignée sur l'objectif du produit. Tout en conservant des rôles et des redevabilité qui sont franches et claires, de façon à savoir ce que chacun a à faire, tout simplement.

Et du coup, un autre changement apporté, c'est qu'on ne parle plus d'équipe auto organisée mais on parle d'équipe auto managée. Là je trouve que la subtilité du changement est assez ténue. Là l'écueil visé, c'est le fait que parfois (souvent même), dans une équipe, il y a au moins un développeur qui se dit que l'agilité, ça consiste à faire ce qu'on veut en tant que développeur. Et c'est vrai qu'il y a quand même beaucoup de liberté, beaucoup d'autonomie, beaucoup de possibilités. Sur le fait de pouvoir s'organiser un peu comme on veut. Mais attention à ne pas aller trop loin quand même, puisque parfois un développeur peut être tenté de se faire plaisir à travailler à sa façon et mettre de côté certaines choses qui sont importantes et que ça se fasse au détriment du produit (et ses utilisateurs du coup). Donc si on en arrive là, avec des intérêts personnels qui sont favorisés au détriment du succès du produit, là il y a un problème clairement. Donc le choix du terme "auto-managée" consiste à expliciter davantage le fait que l'équipe s'auto organise certes, mais de façon à atteindre l'objectif du produit et les objectifs de sprint. Elle s'auto-manage donc. Le mot "manage" vise à expliciter cet alignement de chacun sur l'objectif du produit et donc le succès du produit. Voilà un changement important mais un peu subtil.

Voilà pour l'inventaire des principaux changements qu'il me semble important de relever. Après on pourrait passer la journée là dessus.

Maintenant, si on attaque la prise de hauteur, ce qu'on constate c'est qu'on est sur un retour aux sources, aux racines, aux valeurs et à l'essence de Scrum. Ce qui peut paraître être un propos de puriste éventuellement, mais ce qui est intéressant c'est que tout ça : ces racines, ces valeurs, ces fondamentaux et l'essence de Scrum, c'est avant tout un concentré de pragmatisme. Et donc je trouve ça évidemment intéressant de voir cette évolution du guide Scrum avec cette idée qu'on peut prendre et appliquer le guide Scrum, là maintenant, immédiatement, il y a treize pages à lire dans sa version en anglais. L'utiliser. Utiliser Scrum pour créer de la valeur pour challenger le statu quo, pour améliorer le monde dans lequel on vit et créer un environnement qui est à la fois productif tout en replaçant l'humain au cœur du réacteur. Du coup je trouve ça assez intéressant cette évolution là. C'était évidemment déjà le cas mais ça rend Scrum encore plus accessible.

L'autre prise de hauteur qu'on peut faire, c'est finalement le constat que la portée de Scrum a considérablement augmenté. D'une part parce que désormais on officialise le fait que Scrum s'applique à tous les secteurs même c'était encore une fois déjà le cas. Et surtout ce qu'on constate c'est que le monde a changé, il est devenu plus complexe, clairement plus sophistiqué, beaucoup plus basé sur la science qu'auparavant et comme je le disais, le secret des entreprises performantes se situe essentiellement sur cette capacité d'alignement associé à une forte capacité d'adaptation. Évidemment la crise COVID n'a d'ailleurs fait qu'accentuer cette réalité.

Enfin, troisième axe de prise de hauteur, on peut dire qu'on est sur des changements (du guide Scrum) qui sont je trouve d'une grande ampleur mais sans remettre en question les fondamentaux. Et je pense que l'on va davantage parler de ces changements que ceux qui ont été apportés au guide en 2017, à mon avis. Finalement on ne fait que renforcer ces fondamentaux mais avec des changements qui sont à mon sens assez profonds malgré tout. 

Alors maintenant j'arrive à la conclusion, donc mon point de vue personnel que j'ai gardé pour la fin en toute humilité. Personnellement, je suis vraiment ravi de cette officialisation de l'ouverture aux autres secteurs puisque ça fait déjà des années que j'essaye de vulgariser, de rendre accessible l'agilité à tous les secteurs. Depuis 2007 quand j'ai commencé à rédiger des articles de blog sur le sujet. Ça commence à faire déjà de longues années de partage même si au tout début je n'ai pas forcément pensé à vulgariser pour les autres secteurs. Mais ces derniers temps on sent bien que ça a du sens et qu'il y a un véritable besoin. Donc ça c'est plutôt très bien. 

J'ai juste une réserve, mais qui est mineure, c'est le fait qu'on ai conservé le terme "développeur" et ça, en étant moi même un ancien développeur, ça me fait immédiatement penser au développement logiciel, à l'informatique, au métier de programmeur, de codeur, tout ce qu'on veut. Et pour avoir participé à l'animation de Startup Weekends ou d'Hackatons, j'aime bien le terme qui est assez couramment utilisé dans ces évènements. Le terme c'est un anglicisme. Je suis navré mais pour ceux qui n'aiment pas ça, mais c'est "Makers". "Faiseurs", si je devais traduire en français. Je trouve que ce terme est plus générique et peut être un peu plus inclusif que "développeur" qui peut au premier abord, si on ne fait pas ce travail d'ouverture en se disant "Oui ok 'développeur' d'accord, ça peut me concerner même si je ne fais pas du développement logiciel". Mais on pourrait malheureusement s'arrêter au terme sans vouloir creuser davantage. Et du coup je me dis que le terme "Faiseurs", "Makers" ou "Bâtisseurs" serait peut être plus approprié. Malheureusement il n'y a pas de terme évident, s'il y avait un terme évident ça fait longtemps que les gens brillants qui ont travaillé sur ce guide l'auraient trouvé. Bien sûr encore une fois, c'est en toute humilité qu'il dit ça.

Ensuite le côté moins prescriptif, c'est évidemment génial pour se donner de la flexibilité mais ça va aussi soulever pas mal de questions. Pour ceux qui débutent, ce nouveau guide va soulever encore plus de questions à mon avis. Par exemple, justement, comment animer la mêlée qui est quand même - encore une fois - au coeur du dispositif Scrum.

Ceux qui ont d'ailleurs déjà de l'expérience auront un rôle important à jouer pour rassurer ou donner des exemples de façons de faire à ceux qui débutent, mais en veillant toujours à considérer ça comme des exemples et non pas LA façon de faire. C'est là où se situe le "piège" dans lequel on pourrait tomber face à ces questions, qui à mon avis vont augmenter de façon légitime. D'ailleurs au passage, si vous n'êtes pas trop fâché avec l'anglais je vous conseille de lire le guide dans sa version en anglais car la traduction en français, même en étant très très bon en traduction peut livrer certaines choses à l'interprétation. Je prends l'exemple du terme responsabilité qui n'est pas toujours traduit par le terme redevabilité. Là je viens d'avoir un échange avec ceux qui ont traduit le guide. Dont je salue le travail parce que, pour avoir déjà traduit un livre sur l'agilité, contribué à traduire un livre sur l'agilité, je sais que c'est un boulot énorme qui soulève plein de questions qui sont parfois soumises à débat au sein de l'équipe de traduction. Là a un moment donné il y a vraiment une distinction à mon sens à faire entre responsabilité et redevabilité, puisque encore une fois, je peux déléguer la responsabilité mais rester redevable. Donc c'est super important de distinguer ces deux termes. Peut être qu'au moment où vous allez lire le guide en français ça aura déjà été corrigé ou amélioré. Mais voilà c'est un point de vigilance à avoir sur la version du guide que vous allez vouloir lire ensuite.

Là ça relève un peu plus de l'émotionnel on va dire, mais j'ai été beaucoup touché par la simplicité et l'humilité des deux créateurs de Scrum Jeff Sutherland et Ken Schwaber. Je crois qu'il faut prononcer "Chouéber". C'est des gens qui ont quand même 75 ans et plus de 75 ans de mémoire. Et ils citent encore leurs mentors avec qui ils continuent encore à beaucoup interagir apparemment (chez Toyota, je crois de mémoire). Alors qu'ils sont quand même à l'origine d'un mouvement qui est d'une ampleur dingue est ultra positif en terme d'efficacité, de performance, mais aussi de respect de l'humain. Et à la fin ils font des remerciements qu'on sent plein de sincérité qu'ils adressent à tous ceux qui contribuent à rendre finalement le monde meilleur en pratiquant Scrum. Sans prétendre que Scrum est LA solution à tous les problèmes dans le monde, mais Scrum fait partie des choses qui contribuent à améliorer le monde dans lequel on vit. Donc ils remercient tous ceux qui pratiquent Scrum avec le courage de challenger le statu quo, de faire bouger les lignes (de façon constructive bien sûr).

Et en ce qui me concerne j'ai surtout envie de les remercier eux, parce que Scrum a radicalement changé ma vie aussi bien professionnelle que personnelle. C'est le cas de tellement de gens. Donc ça c'est pour la partie un peu émotionnel, sur mon ressenti sur tout ça.

Ce que je trouve aussi intéressant, et ça s'inscrit un peu dans cette humilité là aussi, c'est que dans ce guide ils rendent un peu à César ce qui appartient à César en explicitant le fait que Scrum est basé sur l'empirisme bien sûr mais aussi sur la façon de penser Lean. Et je crois que c'est la première fois que le terme Lean apparaît de façon aussi explicite.

Ce qu'on peut remarquer aussi c'est que dans la version précédente du guide Jeff Sutherland et Ken Schwaber étaient cités en introduction comme les créateurs de Scrum. Désormais, ils sont cités tout à la fin sur le paragraphe consacré à l'histoire de Scrum. Je trouve ça intéressant, ils ne se sont pas du tout mis en avant. Je me demande si ce n'est pas un peu le signe d'une appropriation de Scrum par la communauté d'utilisateurs de Scrum. Et je pense que c'était quelque part leur objectif et ils l'ont dit, ils s'appuient énormément sur la communauté Scrum pour faire évoluer Scrum. Même si à chaque fois, on est sur des évolutions subtiles encore une fois, on ne réinvente pas la roue évidemment à chaque changement.

Voilà en conclusion finalement ce guide de mon point de vue va nous faciliter la vie en tant que coach agile. Parce qu'il y a quand même de nombreux changements qui visent à prévenir autant que possible les écueils qu'on est nombreux à avoir rencontré. Cette nouvelle version du guide, même si comme je le disais, va soulever plus de questions, elle est plus explicite et du coup peut être qu'on passera moins de temps à redresser des situations compliquées et peut être plus de temps à être plus dans l'optimisation des résultats ou dans l'extension de la diffusion de l'agilité au sein des entreprises.

Mais en tout cas j'espère surtout que cela va contribuer à réduire le nombre d'entreprises échaudés par Scrum parce qu'elles auraient peut être mis en oeuvre Scrum de façon trop approximative. Ce guide étant plus explicite, peut être que ça aidera à limiter le nombre d'équipes qui tombent dans cet écueil, se retrouvent "vaccinées" et ne veulent plus entendre parler de Scrum. Alors qu'à l'inverse, je ne connais pas un seul agiliste (ayant correctement appliqué Scrum) qui soit revenu en arrière. J'en connais pas un seul. Même en les payant plus cher, je ne pense pas qu'ils seraient prêts à revenir à leur ancienne façon de travailler.

Enfin j'avais promis une anecdote. Je vous disais que le guide de Scrum fait désormais 13 pages dans sa version en anglais. Il en faisait 18 dans dans sa version d'avant et l'anecdote nous vient de Ken Schwaber qui, en introduction de la conférence, disait que la toute première version du guide Scrum paru en 2000 ou 2001 de mémoire (il pense se souvenir que c'était juste après la publication du Manifeste Agile, donc plutôt 2001) faisait 160 pages et était divisé en 7 phases. Donc ça vous montre à quel point on est allé loin dans l'épure et du coup dans quelque chose d'épuré, de simple. Pragmatique, et c'est une des qualités de Scrum.

Voilà pour ce podcast consacré aux changements ou aux améliorations du guide de Scrum sur l'année 2020.

Voici quelques liens utiles pour aller plus loin :