Scrum n'est pas un cadre de travail agile de développement logiciel

Hier, j’ai tweeté ceci :

Scrum n’est pas un cadre de travail agile de développement logiciel. Scrum n’est d’ailleurs pas un cadre de travail de développement logiciel. Les adeptes de Scrum n’arrêtent pas de me le dire depuis plusieurs années. J’aurais dû les croire.

Ce tweet est piège-à-clic et provocateur, bien sûr, mais cela s’avère aussi plutôt exact. Laissez-moi donc vous expliquez. Euh non, ce serait trop long. Laissez-moi donc vous la faire courte.

Un certain nombre d’experts Scrum disent que Scrum est un cadre de travail de développement de produits. La Scrum Alliance indique :

Scrum est un ensemble simple, tout en étant incroyablement puissant, de principes et de pratiques permettant à des équipes de livrer des produits avec des cycles courts, d’obtenir des retours d’informations rapides, de s’améliorer de manière continue et s’adapter rapidement par rapport aux changements.

alors que le Guide Scrum et scrum.org indiquent :

Scrum (nom) : Cadre à l’intérieur duquel des personnes peuvent aborder des problèmes évolutifs complexes, tout en livrant d’une manière productive et créative des produits ayant la plus grande valeur possible.

Aucune de ces deux définitions ne mentionnent le développement logiciel, ni le mot “agile”, et encore moins “Agile”. Et c’est probablement une bonne chose.

Scrum en tant que tel est, de mon point de vue, une bonne chose. Ce n’est pas la meilleure chose possible, c’est ce dont nous allons discuter quelque peu ici, mais s’il est utilisé tel qu’il a été conçu, je pense qu’il est utile aux organisations et généralement sans danger pour les personnes. Mal utilisé, Scrum peut s’avérer être nocif pour les gens, tout spécialement pour “l’Équipe de Dév”, tout en ayant malgré tout une certaine utilité pour l’organisation. Et là ce serait néfaste.

Mais parlons d’abord d’“agile” et de “développement logiciel”. Scrum peut clairement être utilisé de manière agile, et il peut être, et est généralement, utilisé dans le cadre du développement logiciel. Pourquoi, alors, est-ce que je dis qu’il n’est pas un cadre de travail agile de développement logiciel, ou un cadre de travail de développement logiciel d’ailleurs ?

Je préfère utiliser le terme “Agile”, et tout spécialement avec la lettre majuscule A, pour faire référence au Manifeste Agile, ce dernier énonçant différentes valeurs et principes. Quelques fois, il m’arrive d’omettre la lettre majuscule, tout en conservant toujours la même signification, et il peut m’arriver certaines fois d’utiliser le mot “agile” pour signifier danser avec une grande réactivité et une grande souplesse. Scrum ne correspond à aucun de ces éléments.

Scrum peut être utilisé de manière agile et Agile. Il peut être utilisé en accord avec les valeurs et les principes du Manifeste Agile, et il peut être utilisé avec réactivité et souplesse. Il peut aussi être utilisé avec des valeurs et des principes tout à fait épouvantables, et en ne faisant aucunement preuve de souplesse et de réactivité. Et là ce serait néfaste.

Scrum peut être et est souvent utilisé dans le développement logiciel. Toutefois, Scrum lui-même ne présente aucun élément propre qui soit orienté logiciel. Aucun principe ou pratique liée au logiciel. Scrum est défini comme ça. Je peux voir deux raisons expliquant pourquoi il serait fait de cette manière là. Tout d’abord, Scrum essaye d’être une approche générique pour développer des produits, pas seulement une méthode logicielle. C’est une manière tout à fait correcte de positionner un cadre de travail, et c’est celle que Jeff et Ken ont choisi. Ensuite, Scrum essaye d’être minimal. Il essaye d’être aussi simple que possible. Ainsi, cela a un sens que de mettre de côté les détails, et tout spécialement s’ils ne sont pas aussi “universels” que le reste.

Ce sont des décisions respectables que vous pourriez prendre lorsque vous créez un cadre de travail : faites-le générique, faites-le aussi léger que possible. Il est possible de ne pas être d’accord avec cette idée. Il est possible de penser qu’ils aient laissé de mauvaises choses dedans et mis de côté les choses qu’il ne fallait pas. C’est tout à fait acceptable. Vous pouvez définir votre propre cadre de travail si vous voulez, ou essayer le cadre de travail de quelqu’un d’autre. C’est tout aussi bien.

De mon point de vue, Scrum est un point de départ convenable pour commencer. Et le plus important, peut-être, est qu’il est de manière quasi-certaine le cadre de travail le plus largement utilisé aujourd’hui (beaucoup plus que d’autres illustres inconnus comme “chaotique”, “complètement m**dique”, et “c’est-quoi-ce-bordel ?” ). Parce que Scrum est là aujourd’hui, il me semble que c’est une bonne idée que de le comprendre et de savoir comment aider les gens à devenir efficients au sein de Scrum.

Il existe, bien sûr, d’autres points de vue. Scrum est beaucoup dénigré ici et là. Il existe deux catégories de dénigrements, et l’une d’entre elle est pertinente et l’autre moins.

La catégorie pertinente fait remarquer que les gens pratiquent mal Scrum, avec un résultat loin d’être efficient, ou, pire encore, rend la vie des gens pire encore. C’est malheureusement pas si rare que ça, cela devrait être signalé et des solutions devraient être apportées pour remédier à cela.

La catégorie moins pertinente de dénigrements de Scrum se produit lorsque les gens décident que quelque chose dedans est mauvais. Les dénigrements qui reviennent le plus souvent sont “les Sprints sont néfastes”, et “les Products Owners sont néfastes”. De mon point de vue, certains sprints sont néfastes, et le comportement de certains Product Owners sont néfastes. Les idées elles-mêmes ne sont pas optimales mais elles sont tout à fait convenables et ne présentent généralement aucun risque. Laissez-moi donc essayer de faire presque justice aux objections et ensuite d’essayer de les réfuter.

Les Sprints sont néfastes

Il semble qu’il y ait deux plaintes principales sous-jacentes à propos des Sprints. La première est que le travail à faire n’arrive pas correctement calibré et que par conséquent le Sprint n’embarque pas suffisamment de travail à faire, parce que ces travaux à faire ne s’articulent pas correctement. La seconde est que des personnes néfastes (il s’agit peut être d’ailleurs de ces mêmes Product Owners néfastes, ou peut être de manageurs néfastes) essaieront de fourrer encore plus de travail à faire qu’il n’est raisonnable de faire pendant ces deux semaines, et cela aura comme résultat que d’avoir des développeurs malheureux et un travail de moins bonne qualité. Par conséquent les Sprints sont néfastes et par conséquent Scrum est néfaste et par conséquent si vous êtes un partisan de Scrum vous êtes vous aussi probablement néfaste.

Oui, j’ai bien pris note. Mais tout cela constitue une fausse piste. Oui, il est exact que le travail à faire n’arrive pas correctement calibré, et que par conséquent nous nous retrouvons avec soit trop ou trop peu de choses à mettre dans un Sprint. C’est un gros problème. Il y en a aussi trop pour que cela puisse rentrer dans ce que nous pouvons faire Mercredi - et ce n’est pas la meilleure idée qu’il soit que de ramener du boulot à la maison le soir. Prenez donc un peu moins de boulot que ce que vous pensez que le Sprint pourrait supporter. Cela devrait bien se passer. Il y aura toujours quelque chose à faire le Vendredi. En fait, il y a de grandes chances que vous ayez trop de travail à faire de toute manière. Cela reste tout à fait correct. Il s’agit d’une prévision, non d’une promesse.

Oh, c’est une promesse ? Alors le problème n’est pas le Sprint, c’est la personne qui a fait de cette prévision une promesse. Le problème n’est pas le Sprint, ce sont les gens.

Aussi longtemps qu’il y aura une surcharge de travail sur l’équipe, il s’agira bien d’une mauvaise idée. Une équipe sous pression prendra des raccourcis, qui conduiront à des anomalies et à une mauvaise conception. Les membres de l’équipe seront malheureux, ce qui conduira à moins d’implications de leur part au travail, et enfin à la défection de personnes de qualité. Et c’est cruel. Qu’est-ce qui cause cette surcharge ? De mauvais product owners, de mauvais manageurs, un mauvais leadership. Un calendrier, en tant que tel, ne provoque pas de surcharge.

Néanmoins, il est probablement exact que Scrum offre de fréquentes opportunités aux gens de mettre la pression. Le Sprint est l’un d’eux et le standup quotidien en est un autre. Et quelques fois, les éléments qui caractérisent ces réunions sont détournés pour mettre la pression. C’est plutôt stupide, toutefois, d’imaginer qu’en supprimant ces réunions, nous enlèverions la pression. C’est plutôt le contraire. Étant donné que la pression est appliquée par une personne, pas un évènement, cette personne trouvera simplement une autre manière d’appliquer la pression.

Le problème ce n’est pas le Sprint, ce sont les gens.

Les Product Owners sont néfastes

L’idée principale ici est que le rôle de Product Owner ne devrait pas exister. Les objections varient allant du mot “owner”¹, qui combiné avec le mot “master”², évoquerait apparemment aux yeux des certains de nos contemporains, l’esclavage ou quelque chose comme ça. En toute sincérité, l’esclavage est bien sûr quelque chose de tout à fait horrible et malfaisant, mais il doit y avoir quelque chose de plus important dans la vie que de se prendre la tête sur ces mots-là à chaque fois qu’ils apparaissent ³.

Une objection plus substantielle est que la notion de Product Owner est trop exclusive, et que cela ne permet pas de démontrer que l’ensemble de l’équipe devrait se sentir elle-aussi propriétaire de la problématique et de l’espace de solution dans une collaboration douillette et coopérative. Ouais, eh bien, j’adhèrerai à cela lorsque tout le monde conduira en respectant les limites de vitesse, que personne ne franchira la ligne blanche continue et que tout le monde qui a des items dans la colonne 12 items ou inférieurs aura bien 12 items ou inférieurs (d’ailleurs, cet indicateur devrait dire “ou moins” et non “inférieur” ⁴)

Je préfère désormais le terme Product Champion, terme dont j’ai entendu parler la première fois via un PO de chez Disney et qui m’a expliqué très clairement “Je ne veux pas être le propriétaire du produit, je veux que l’équipe le soit.”. Et oui, c’est tout à fait exact. C’est comme cela que vous devriez faire. Bien joué. Continuons.

Toutefois, il n’y a rien dans le mot, ou dans le rôle, qui vous empêche de travailler de cette manière là et il y a vraiment beaucoup de choses dans le monde Scrum en terme de formations, d’ouvrages, de coaching qui vous feront vous rappelez de travailler de cette manière là. Et si l’entreprise a nommé la mauvaise personne “en charge” du produit, alors vous aurez ce problème.

Le problème ce n’est pas le Product Owner, ce sont les gens.

Scrum est correct, je suppose

Je pense que Scrum est un point de départ tout à fait acceptable pour commencer un voyage sur une voie plus agile et plus Agile pour réaliser des produits, y compris des produits logiciels. C’est une façon tout à fait acceptable pour faire tourner une boutique de pâtisserie.

Existe t’il de meilleures manières de faire les choses ? Absolument, mais il n’y en a aucune qui arrive dans une belle boîte. Vous pouvez créer la vôtre si vous êtes capable de le faire, mais la plupart des gens qui n’ont jamais fait d’[A/a]gile ne sont pas capables de le faire. Vous pouvez prendre un autre processus de l’étagère, mais elles sont sauf exception toutes aussi mauvaises les unes que les autres voire pires encore. Scrum est une façon appropriée de commencer.

Alors vous devez le faire fonctionner. Le principe fondamental de Scrum est “Inspecter et Adapter”. Lors de chaque Sprint, vous planifiez un Incrément du produit, vous réalisez l’Incrément, vous passez en revue l’Incrément avec les parties prenantes pour avoir leur retour, et vous passez en revue votre performance avec toute l’équipe pour voir comment vous améliorez. Qu’est-ce qui pourrait mal se passer ?

Il y a une seule chose qui pourrait vraiment mal se passer, vous pourriez voir quelque chose qui ne s’est pas bien passé et échouez à le corriger. Vous pourriez voir que les gens avec qui vous travaillez sont débordés lors des Sprints, et vous échouez à corriger cela. Vous pourriez voir que votre Product Owner pilote mal et ne collabore pas assez, et vous échouez à corriger cela. Vous pourriez voir que votre code devient pourri et vous échouez à le corriger. Vous pourriez voir que le nombre d’anomalies augmente et vous échouez à corriger cela.

Votre problème ce n’est pas Scrum

Le problème ce n’est pas que Scrum n’est pas agile, même s’il ne l’est pas. Le problème pourrait être que vous ne l’utilisez pas de manière Agile.

Le problème n’est pas que Scrum ne soit pas un cadre de travail de développement logiciel, même s’il ne l’est pas. Le problème pourrait être que vous n’utilisez pas les valeurs et les pratiques du développement Agile de logiciel, ou les techniques agiles de développement logiciel au sein de Scrum pour construire du logiciel.

Le problème n’est pas que Scrum ait des Sprint ou des noms bizarres pour ses rôles. Le problème est que vous n’inspectez pas, n’adaptez pas et n’améliorez pas ce qui se produit.

Vous n’êtes pas obligé de commencer avec Scrum si vous ne voulez pas. (Oui, euh, quelqu’un pourrait aussi vous l’imposer. Ça aussi, ce serait néfaste, mais si quelqu’un le fait, vous avez le droit et la responsabilité d’inspecter, d’adapter et d’améliorer. Et à nouveau, il s’agit bien ici des personnes, et non de Scrum).

Existent-ils de meilleures manières de commencer ? Je ne suis pas certain : avec la plupart des équipes que j’accompagne, je démarre souvent avec quelque chose qui ressemble beaucoup à Scrum, mais je suis amené à considérer d’autres points de départ également. Scrum, de mon point de vue, n’est pas une mauvais point de départ pour commencer.

Existent-ils de meilleures points de départ pour avancer ? Absolument ! C’est mieux de réaliser un incrément testé opérationnel livrable chaque jour ou chaque heure. Scrum ne dit pas que vous ne pouvez pas le faire. C’est beaucoup mieux de travailler ensemble de manière si étroite que vous n’aurez pas besoin de réunions de standup. Si c’est le cas, abandonnez-les (et arrêtez de dire que vous faites du Scrum). C’est mieux d’avoir un Product Owner qui partage les problèmes de l’équipe et qui laisse l’équipe les solutionner. Donc faites-ça. Appelez-les par un autre nom si vous voulez, c’est OK. Vous pouvez même dire “Nous faisons du Scrum et nous appelons notre Product Owner l’Expert en Chef des Problèmes.”. C’est correct.

Le but même d’Inspecter et d’Adapter c’est d’améliorer

Suzuki Roshi a dit :

Vous êtes parfait tel que vous êtes. Et vous pourriez juste faire usage d’un peu d’amélioration.

Votre problème ce n’est pas Scrum. Peut est-il que vous pourriez faire usage d’un peu d’amélioration.

Auteur : Ron Jeffries
Source : Scrum is not an Agile Software Development Framework
Date de parution originale : 19 Juillet 2018

Traducteur : Nicolas Mereaux
Date de traduction : 21/07/2018

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.