Le manifeste Agile sert un but. Ses valeurs nous font réfléchir à la façon dont nous pouvons livrer des produits de valeur. Ses principes fournissent une inspiration sur la façon de le faire.

The Agile Manifesto: Why Agile Makes Sense

https://www.benlinders.com/2021/the-agile-manifesto-why-agile-makes-sense/ by Ben Linders

Pourquoi l’agilité a du sens

Lorsque le manifeste agile a été publié en 2001, il était à la fois attendu depuis longtemps et bien en avance sur son temps.

Les méthodes de développement de logiciels axées sur des plans prédictifs ont échoué pendant de nombreuses années au cours du siècle dernier. Elles échouent toujours. Les rapports CHAOS du Standish Group montrent année après année que la plupart des projets informatiques échouent ou connaissent de grosses difficultés. Pour ceux qui réussissent, l’agilité y joue souvent un rôle. Au moment de la publication du manifeste, il était attendu depuis longtemps : nous savions depuis de nombreuses années que faire plus de plans et de meilleurs plans et gérer les projets dans les détails n’était pas la voie à suivre. Nous avions besoin d’une nouvelle approche, d’un nouvel état d’esprit.

Ensuite, des idées telles que travailler en équipe, collaborer étroitement avec les clients, livrer en cycles courts, faire des rétrospectives et adapter notre façon de travailler, challengeaient les personnes et les organisations en 2001. Le monde n’était pas prêt pour cela à ce moment-là. Je me demande en fait s’il est prêt pour cela maintenant, vingt ans plus tard ?

Quand le manifeste a été publié, ce n’était pas quelque chose de « nouveau » pour moi. Mais cela avait beaucoup de sens.  J’ai commencé avec l’agilité avant l’invention d’Agile, dans les années 80s.  J’ai adopté l’approche pour offrir de la valeur à mon client par incréments parce que cela avait du sens pour moi et mon équipe. Nous avons collaboré, fait des démonstrations de produits, réfléchi à notre façon de travailler et avons adaptée cette approche. Elle nous a aidé à livrer un meilleur produit plus rapidement. En 2001, elle a reçu un nom : Agile.

Le manifeste Agile sert un but. Ses valeurs nous font réfléchir à la façon dont nous pouvons livrer des produits de valeur. Ses principes fournissent une inspiration sur la façon de le faire. La publication du manifeste a supporté une vague de nouvelles réflexions sur la façon dont les humains collaborent et communiquent. Pourtant, de nombreuses personnes ont du mal à appliquer l’agilité dans leur contexte spécifique.

Pour aider à donner du sens au Manifeste Agile et l’appliquer pour réfléchir et apprendre, j’ai créé les Cartes de Questions Rétrospectives du Manifeste Agile. Elles peuvent être téléchargées dans ma boutique en ligne pour une somme modique.

Ces cartes contiennent des questions puissantes pour inspirer vos rétrospectives agiles et les garder précieuses et efficaces. Il y a 15 questions pour chacune des quatre valeurs du manifeste, à la fois pour les côtés gauche et droit de la valeur (c’est « ensemble » donc les deux côtés sont précieux). Et 12 questions bonus que vous pouvez utiliser pour aider les équipes à réfléchir à leur parcours agile, et des cartes vides que vous pouvez utiliser pour ajouter vos propres questions. Au total, il y a 78 cartes avec des questions puissantes.

Poser des questions peut aider à approfondir la compréhension et à mieux comprendre ce qui se passe. Le manifeste agile n’apporte pas de réponses ni de solutions. Il guide vers les choses qui ont du sens, qui comptent. Avec ces conseils, nous pouvons trouver des réponses et trouver des solutions qui fonctionnent pour nous.

En résumé, Agile avec le manifeste Agile me semble être du bon sens pour développer des produits. Malheureusement, le bon sens n’est pas si commun.

Comment les auteurs du manifeste agile m’ont inspiré

Au fil des ans, j’ai rencontré et parlé avec la plupart des auteurs du manifeste Agile. J’ai interagi avec eux lors de conférences où nous avons présenté et partagé nos histoires ou fait des interviews ensemble. J’ai lu leurs livres, articles, blogs et bien plus encore. J’ai eu des discussions avec eux sur LinkedIn, Twitter, Slack ou par e-mail. J’ai également interviewé la plupart d’entre eux en tant que rédacteur en chef pour InfoQ car je voulais partager leur expérience.

Voici comment je me suis inspiré d’eux : Vous trouverez ci-dessous mes histoires inspirées du deuxième bloc de six auteurs du manifeste agile (par ordre alphabétique).

James Grenning

J’ai rencontré James Grenning pour la première fois à la conférence OOP 2015. Nous avons parlé des odeurs du code, ce sur quoi j’ai travaillé en combinaison avec des revues de code. Inspiré par mon expérience, nos discussions et la réflexion sur la façon dont je facilite et enseigne en facilitant les rétrospectives agiles, j’ai trouvé le concept d’odeurs rétrospectives : Des signaux qu’il y a potentiellement quelque chose qui ne va pas dans votre rétrospective. J’ai écrit series of articles on retrospective smells et créé les Agile Retrospective Smells Cards.

J’ai fait un Q&R avec James sur Test Driven Development et Code Smells pour InfoQ où je lui ai demandé pourquoi les programmeurs doivent avoir un bon nez pour les odeurs du code :

Le programmeur qui veut améliorer le code sur lequel il travaille a besoin de trois compétences essentielles. Un bon nez pour le code, des compétences pour envisager un design amélioré et les compétences pour transformer le code malodorant en un meilleur code.

Dit plus simplement, si vous ne pouvez pas identifier avec une certaine précision un problème dans la structure du code, comment pouvez-vous le résoudre ? Je me souviens que les revues de code dans ma carrière n’étaient généralement qu’une question d’opinion. « Je n’aime pas ça, j’aurais fait ça », totalement non justifié. N’importe quel programmeur peut annoncer « ce code pue », mais ce n’est pas suffisant. Un chef dans la cuisine hume une bouffée d’air et dit « jetez les pommes de terre, elles sont mauvaises, et prenez-en des fraîches ». Les programmeurs doivent être en mesure d’identifier des odeurs spécifiques pour avoir une idée de la façon d’améliorer le code.

James Grenning sur InfoQ

James a eu l’idée du planning poker. C’est un excellent moyen d’appliquer la gamification et les jeux pour augmenter la participation des développeurs et créer un environnement sûr permettant aux gens de partager leurs idées et leurs sentiments sur quelque chose d’aussi délicat que les estimations. Dans le planning poker, tomber d’accord ne nécessite pas de débats inutiles. Mon expérience est la même avec des techniques telles que les estimations Delphi à large bande et les bilans de santé ; en utilisant ces techniques, je suggère de passer du temps à discuter des différences car c’est là que se trouvent les apprentissages.

Jim Highsmith

J’ai vu Jim Highsmith faire une présentation à l’une des premières conférences SM/ASM auxquelles j’ai assisté, je crois que c’était en 2001 ou 2002. Ce sont les premières grandes conférences américaines auxquelles je suis allé et dans lesquelles j’ai ensuite pris la parole. J’ai beaucoup appris lors de ces conférences que j’ai utilisées au fil des ans pour mesurer et améliorer la qualité des logiciels lorsque je travaillais chez Ericsson, et j’ai étendu mon réseau professionnel à de nouveaux domaines.

En 2004, Jim Highsmith a publié le livre Agile Project Management. Il est recommandé de lire si vous devez faire des projets et que vous voulez apprendre à mieux les faire :

Dans un projet agile, l’équipe s’occupe des tâches et le chef de projet s’occupe de l’équipe.

Gestion de projet agile par Jim Highsmith

Appliquer le concept d’agilité à la façon dont les projets sont gérés avait du sens au départ pour moi, mais j’ai vu cela échouer beaucoup plus souvent que réussir. L’échec était le plus souvent dû au fait de ne pas adopter l’état d’esprit agile, mais plutôt d’utiliser à mauvais escient l’agilité comme excuse pour répartir le travail de planification entre les membres de l’équipe tout en essayant de tout micro-manager.

La gestion de projets avec agile est un sujet complexe sur lequel j’ai écrit plusieurs articles au début de mon entreprise unipersonnelle : Agile project management, Managing and reporting agile projects, Fixing scope in agile projects, and Managing projects with agile teams. Au fil des ans, je me suis éloigné de la gestion de projet, et mon attention s’est déplacée vers le management des produits et des équipes, ce qui, selon moi, est une approche plus viable et durable pour générer de la valeur. Au cours des dernières années, j’ai présenté et écrit sur les choses Dos and Don’ts of Agile Management.

Andrew Hunt

Andrew Hunt a écrit le livre The Pragmatic Programmer (avec Dave Thomas). Il a été publié à l’origine en 1999, mais la version que j’ai lue est l’édition du 20e anniversaire publiée en 2019.

L’essence de l’agilité, comme indiqué dans « le programmeur pragmatique »

Agile est un adjectif : c’est comment on fait quelque chose. Vous pouvez être un développeur agile. Vous pouvez faire partie d’une équipe qui adopte des pratiques agiles, une équipe qui réagit au changement et aux revers avec agilité. L’agilité, c’est votre style, pas vous.

David Thomas et Andrew Hunt dans The Pragmatic Programmer – Édition du 20e anniversaire

Je partage ce point de vue ; agile n’est pas ce que vous êtes, mais ce que vous faites et comment vous le faites. Le manifeste ne fournit qu’un ensemble de valeurs et de principes, il appartient à chaque individu de réfléchir à la façon de les appliquer et d’agir d’une manière qui a du sens.

En lisant ce livre, je voulais faire un Q&R (interview écrite) avec Andrew et Dave. J’ai posé des questions sur des sujets dans lesquels se plonger. Il s’est avéré qu’Andrew et Dave préféraient faire un podcast ; Voici l’interview que mon collègue rédacteur en chef d’InfoQ, Shane Hastie, a réalisé avec eux : Dave Thomas & Andy Hunt on the 20th Anniversary Edition of The Pragmatic Programmer.

Andrew a fondé la série Pragmatic Bookshelf avec Dave. Il s’avère que j’ai lu beaucoup de livres publiés par eux :

• Create Your Successful Agile Project by Johanna Rothman
• Code with the Wisdom of the Crowd by Mark Pearl
• Liftoff, Second Edition by Diana Larsen and Ainsley Nies
• Creating Great Teams by Sandy Mamoli and David Mole
• Agile Retrospectives by Esther Derby and Diana Larsen
• Become an Effective Software Engineering Manager by James Stanier
• Competing with Unicorns by Jonathan Rasmusson

Ron Jeffreys

J’ai été en contact avec Ron Jeffries au fil des ans par courriel. Nous avons eu de brefs échanges liées à des discussions sur Twitter, des publications sur InfoQ ou l’un de mes livres. Ron est assez direct sur ce qu’il peut ou ne peut pas faire, quelque chose que je reconnais et apprécie (je suis néerlandais).

Ron Jeffries a « inventé » les Story Points comme un concept pour estimer la taille des histoires dans XP. Avec les Story Points est venu la vélocité comme un moyen de suivre le nombre de Story Points qu’une équipe peut livrer. Oui, livrer : La seule façon d’obtenir des Story Points est lorsqu’une histoire est terminée, le logiciel livré, et donc la fonctionnalité décrite dans l’histoire est disponible pour les utilisateurs.

Au fil des ans, j’ai vu de nombreuses discussions sur l’attribution de Story Points lorsque les histoires sont partiellement terminées (aucune valeur livrée, alors ne le faites pas), l’obtention de Story Points pour résoudre les bogues (encore une fois aucune valeur car le bug n’aurait pas dû être là en premier lieu) et la normalisation des Story Points à travers plusieurs équipes (ce qui conduit généralement à comparer les équipes, ne le faites pas). Il semble y avoir beaucoup de choses qui vont mal et les gens ont du mal à comprendre. Ce qui est dommage.

Le véritable avantage que j’ai vu dans les Story Points est les discussions qu’ils déclenchent. Si tout le monde arrive avec le même nombre ou si les estimations sont proches les unes des autres, ma suggestion est de convenir rapidement d’un nombre et de passer à autre chose. Ne passez pas de temps à savoir si cela devrait être un 3 ou un 5, cela n’en vaut pas la peine. Lorsqu’il y a un écart plus important dans les estimations, discutez pour augmenter une compréhension partagée de l’histoire et non pour estimer. Une fois que les gens s’alignent sur le contenu de l’histoire, il est facile de l’estimer. Si c’est difficile à estimer, alors il y a un manque de bonne compréhension. Travaillez là-dessus.

En 2019, Ron a publié l’article Story Points Revisited où il a exploré comment les Story Points sont mal utilisés. J’aime cette déclaration sur la pression sur les équipes :

La meilleure façon de créer de la valeur n’est pas plus, plus, plus, c’est de faire de petites choses précieuses fréquemment. Si, au lieu d’estimer les histoires, nous les rendons « suffisamment petites », nous pouvons arriver à un flux de valeur fluide, livrant tout le temps.

Ron Jeffries dans Story Points Revisited

Compte tenu du temps perdu avec l’estimation, je suis devenu un fan de l’approche d’estimation que Pawel Brodzinski a mise au point (1 / TFB / NFC) et de #NoEstimates. Ce n’est pas une question d’estimation. Il s’agit de découper les choses jusqu’à la plus petite pièce qui a encore de la valeur et de fournir un flux continu de valeur qui compte.

J’ai fait une séance de questions-réponses avec Ron Jeffries sur la nature du développement logiciel pour InfoQ, où je l’ai interrogé sur le rôle du management lorsqu’une organisation adopte l’agilité :

Tout d’abord, les organisations ne doivent pas « adopter » l’agilité. Elles devraient créer des équipes vraiment agiles et apprendre d’elles. Deuxièmement, les méthodes agiles visent à donner aux équipes les moyens de travailler directement avec les gens du métier et les besoins de l’entreprise. Cela implique que bon nombre des choses faites généralement par les cadres intermédiaires sont prises en charge par l’équipe et son product champion. Les managers doivent l’accepter.

Ron Jeffries sur The Nature of Software Development

J’aime la façon dont il met l’accent sur l’autonomisation des équipes, la collaboration avec l’entreprise et ce que le produit doit faire. Il ne s’agit pas de devenir agile, cela revient aux valeurs du manifeste et à la façon de les mettre en pratique.

Jon Kern

J’ai rencontré Jon Kern lors de l’Agile Greece Summit 2018, une conférence avec de nombreux auteurs du Manifeste Agile. C’était formidable de parler avec lui et d’entendre ses expériences dans sa conférence A Day in the Life of a Jon Kern Agile Project.

Après la conférence, j’ai travaillé avec lui sur l’article d’InfoQ Agile in the Context of a Holistic Approach. C’est un excellent article avec de nombreuses idées pratiques sur l’agilité et l’utilisation de pratiques agiles.

Dans l’article, Jon a partagé son point de vue sur l’état du Manifeste Agile :

Parfois, on me demande si je reviendrais en arrière et changerais le manifeste si je le pouvais.

« Non » est ma réponse.

Au contraire, nous devons nous efforcer de (ré)éduquer les gens sur ce que nous avions l’intention de faire lorsque nous avons écrit le Manifeste.

Jon Kern dans Agile dans Agile in the Context of a Holistic Approach

Je suis d’accord avec lui. Les valeurs du manifeste agile sont grandes et elles n’ont pas vieilli avec le temps. Débattre si elles doivent être mis à jour ou remplacer quelques mots ne nous aide pas beaucoup. Comprendre de quoi il s’agit et le mettre en pratique est ce qui compte.

Brian Marick

Après avoir fait une interview pour Leanpub Frontmatter Ben Linders: Auteur de What Drives Quality , j’ai été présenté à Brian Marick. Après avoir publié ses livres via Leanpub (tout comme moi), il a également fait une interview avec Leanpub Frontmatter: Brian Marick, auteur de An Outsider’s Guide to Statically Typed Functional Programming où le cofondateur de Leanpub, Len Epp, lui a posé des questions sur les arguments de vente de Agile et du manifeste agile:

Ce que nous avons promis, c’est : « Nous vous donnerons des logiciels fonctionnels tous les mois, toutes les deux semaines, que vous pourrez réellement utiliser et montrer. Vous comprenez. Nous vous promettons que si vous décidez à mi-chemin du projet que nous avons en réalisé toutes les fonctionnalités que vous vouliez, vous pouvez simplement vous arrêter, livrer ce que vous avez à ce moment-là et licencier tout le monde, et ne pas aller plus loin dans le projet » – ce qui est très attrayant pour les managers.

Ce que nous n’avons pas promis, c’est : « Nous ne prétendons plus vous dire exactement quel type d’éditeur de texte vous aurez à la fin de l’année. Mais nous vous promettons que vous aurez le meilleur éditeur de texte, l’éditeur de texte le plus complet, avec les fonctionnalités les plus importantes que vous pouvez avoir avec cette équipe à la fin de cette année. Nous ne pouvons tout simplement pas vous dire maintenant ce que ce sera. Vous pourrez le faire, vous apprendrez à le savoir, parce que nous allons vous laisser nous dire quelles sont les choses les plus importantes, et nous les ferons tout de suite, plutôt que de passer un an à en écrire les fondations avant que vous puissiez voir quoi que ce soit. C’est à la fois un bon moyen de développer des choses pour la plupart des types de choses, la plupart des types de logiciels, et c’est aussi un argument de vente très puissant.

Brian Marick dans l’interview de Leanpub Frontmatter

Tenir cette promesse était et a été un élément clé dans de nombreuses entreprises qui envisageaient d’adopter l’agilité. Agile consiste à fournir de la valeur là où vous devez investir du temps pour découvrir quelle devrait être cette valeur. Il ne s’agit pas de spécifications ou d’exigences de projet. Ce qui compte, c’est une discussion intensive et transparente continue qui aide à déterminer ce dont les utilisateurs ont le plus besoin maintenant et à le faire. Si une organisation n’est pas prête à en discuter, alors ne faites pas d’agilité.

En 2018, j’ai été invité à la conférence eXperience Agile 2018 où j’ai parlé avec Brian Marick. Après la conférence, Brian a commencé à travailler sur un article sur la cognition incarnée. Malheureusement, nous ne l’avons jamais terminé et publié. Mais nous avons eu d’excellentes discussions.

Agile a du sens

Les idées mentionnées ci-dessus ne sont que quelques-unes des choses auxquelles je pouvais penser en écrivant ce billet. Cela résume à quel point l’agilité a eu du sens et a encore du sens pour moi. Comme vous pouvez le constater, les auteurs du manifeste agile ont été une source d’inspiration tout au long de ma carrière et à bien des égards.