Qu'est-ce qu'Agilité ? Une philosophie qui se développe par la pratique

Conçu à l'origine pour les équipes de développement de logiciels, Agile est désormais la première approche de gestion de projet pour les industries et les entreprises du monde entier. L'attrait réside dans sa simplicité et sa flexibilité : l'absence de pratiques prescriptives d'Agile le rend hautement adoptable. Et pourtant, en guidant les transformations Agiles dans plusieurs entreprises, j'ai constaté que cette flexibilité entraînait également des idées fausses sur ce que signifie être Agile. De nombreuses entreprises donnent la priorité à l'adhésion aux cadres dérivés d'Agile plutôt qu'à la compréhension de la philosophie elle-même.

Au lieu de cela, les chefs de projet et les coachs qui assemblent et guident des équipes Agiles devraient commencer par les former à adopter un état d'esprit Agile, en intériorisant essentiellement les valeurs et principes fondamentaux de la philosophie. Ce n'est qu'alors qu'ils doivent combiner, personnaliser ou omettre les pratiques des cadres Agile en fonction de ce qui répond le mieux aux exigences du projet.

En retraçant le développement historique d'Agile et en liant ses principes fondateurs aux besoins spécifiques des entreprises et des équipes, cet article peut aider les chefs de projet à créer un avenir optimal pour les transformations Agile. Comme le démontrent les cas suivants, Agile ne doit pas être considéré strictement comme une approche de gestion de projet, mais plutôt comme une philosophie de développement de produit en constante évolution dans la pratique.

Antécédents agiles

Compilé pour la première fois en 2001, le «Manifeste pour le développement logiciel agile», un recueil succinct de quatre valeurs fondamentales et de 12 principes, était une réponse radicale aux approches linéaires et lourdes de processus chargées de règles et d'une documentation abondante. Mais l'histoire d'Agile est née des décennies auparavant avec une méthode de rationalisation de la fabrication industrielle.

Un antécédent de la philosophie pour son accent sur l'amélioration itérative, le modèle Plan-Do-Study-Act a été développé dans les années 1930 par le physicien et statisticien des Bell Labs Walter Shewhart. Après la Seconde Guerre mondiale, son protégé, W. Edwards Deming, l'applique pour former les managers de Toyota. La méthode faisait partie intégrante du développement du système de production Toyota, la principale source de la pensée Lean avec sa boucle efficace de construction-mesure-apprentissage.

Dans les années 1970, le concept a été développé lorsque Barry Boehm a proposé la technique Wideband Delphi, utilisant un processus itératif pour estimer avec précision et objectivement le travail et le temps requis pour développer un logiciel.

Avec la prolifération des ordinateurs personnels au milieu des années 1980, il est devenu clair que le logiciel en tant que produit et service deviendrait la pierre angulaire de la façon dont les gens font des affaires. Alors que les professionnels commençaient à prêter une attention particulière aux approches incrémentielles et itératives de l'ingénierie logicielle, Agile a dépassé les processus Waterfall en tant qu'approche de développement et de gestion supérieure.

Les chercheurs ont découvert que les fabricants qui innovaient plus rapidement que leurs concurrents utilisaient une méthode multidisciplinaire axée sur l'équipe pour faire avancer un produit tout au long de son cycle de vie. Ceci est largement considéré comme l'inspiration de Jeff Sutherland pour inventer le framework Scrum en 1993, qui lui a permis de réaliser des projets ostensiblement impossibles dans les délais et dans les limites du budget, avec un minimum de bugs.

Les valeurs Agiles en théorie - issues de ces antécédents - ont été confirmées dans mon utilisation d'Agile dans la pratique, en mettant l'accent sur le développement itératif, le travail d'équipe collaboratif et l'estimation précise.

Qu'est-ce qu'Agile en théorie ?

Alors que les entreprises continuent d'adopter des méthodes de travail Agiles, elles risquent de les rendre plus prescriptives que les auteurs de la philosophie ne l'avaient jamais prévu. D'après mon expérience, les dirigeants qui souhaitent adopter Agile se concentrent trop sur les cadres - ou ensembles de pratiques spécifiques et leur nomenclature associée - et pas assez sur les valeurs et les principes.

Comme le savent bien les praticiens avancés dans la transmission des principes Agile, chaque organisation cherchant à subir une transformation Agile doit trouver et adapter les approches qui lui conviennent. Je facilite ce processus d'apprentissage en montrant aux équipes comment suivre les valeurs et les principes du manifeste, puis en m'inspirant des frameworks, tels que Scrum, Kanban et Extreme Programming (XP), pour les mettre en pratique.

Les principes du manifeste sont désormais une seconde nature pour les chefs de projet Agile :

1. Les individus et les interactions sur les processus et les outils
2. Des produits fonctionnels sur une documentation complète
3. Collaboration avec le client sur la négociation du contrat
4. Répondre au changement au sujet d'un plan

La mise en garde qui suit ces principes dans le manifeste, cependant, est souvent négligée : "C'est-à-dire que, bien qu'il y ait de la valeur dans les éléments de droite, nous apprécions davantage les éléments de gauche." De nombreux praticiens Agiles finissent par ignorer les valeurs de droite et se concentrer uniquement sur ce qui se trouve à gauche. Le résultat? Le contraire de suivre aveuglément des cadres lourds en processus : aucun processus du tout, ce qui est tout aussi problématique.

Trouver le bon équilibre entre les éléments de droite et de gauche est devenu la clé de ma façon de guider les transformations Agiles. Cela est également illustré par les approches de gestion d'Apple, Google, Amazon, Facebook et Netflix, dont aucune n'a souscrit à un cadre Agile unique. Ils ont avant tout incarné les principes du manifeste, tout en suivant ou en modifiant des parties de différents cadres en fonction de ce qui a le mieux fonctionné pour eux ; par conséquent, ils se sont adaptés aux évolutions du marché et sont en mesure de livrer rapidement de nouveaux produits.

Qu'est-ce qu'Agile en pratique ?

Dans l'aperçu suivant, j'ai modifié la formulation originale des valeurs du manifeste. Les modifications apportées à la sémantique aident à clarifier la manière dont j'applique les valeurs Agile dans la pratique.

Dans la première valeur, je remplace le terme « individus » par « personnes », car être agile signifie être axé sur l'équipe. En ce qui concerne le second, il est évident que le logiciel doit "fonctionner", donc l'accent est maintenant mis sur une "livraison" réussie et opportune. La troisième valeur est simplement la « collaboration », car elle s'applique aussi bien aux collègues qui travaillent ensemble qu'aux équipes qui travaillent avec les clients. Enfin, « cadres » remplace « suivant un plan », car cela prévient le malentendu selon lequel la planification devrait être complètement abandonnée.

Les gens plutôt que les processus

Les transformations agiles sont difficiles, principalement parce que la plupart des entreprises sont tellement habituées à suivre strictement les processus. Compléter un certain nombre d'étapes avec un certain ensemble d'outils, au lieu de développer un produit innovant, devient l'objectif final.

J'ai été consterné de voir cette mentalité donner naissance à une « industrie Agile » rentable. Comme l'expliquent les fondateurs d'Agile, Ward Cunningham et Jon Kern, de nombreuses entreprises vendent des logiciels qui, selon elles, aideront les entreprises à « devenir Agile ». Mais devenir Agile, c'est adopter une philosophie, ne pas utiliser de logiciel et suivre le programme qu'il prescrit.

Atteindre le bon équilibre ne consiste pas à éliminer des procédures, mais plutôt à trouver celles qui soutiennent le mieux les objectifs de développement de chaque équipe. Pour l'un de mes clients, une grande entreprise technologique, j'ai mis en place Disciplined Agile, une approche développée chez IBM. Il combine de nombreuses pratiques issues de plusieurs frameworks, notamment Scrum et Kanban. Il utilise le développement itératif mais est un peu plus lourd en termes de processus que l'Agile traditionnel, en particulier dans la phase de démarrage, car il est destiné à combler les lacunes laissées par Scrum. Disciplined Agile a travaillé pour ce client car l'organisation était très axée sur les processus. Cela m'a permis de rencontrer les équipes à mi-chemin, d'obtenir leur adhésion et de les persuader d'adopter un workflow Scrum.

J'ai incorporé des réunions de raffinement du backlog, des réunions de révision et des mêlées quotidiennes pour faciliter la collaboration intra et interéquipe. Le raffinement du backlog fait partie du Scrum Guide, mais pas les réunions de raffinement. Je les ai ajoutés pour permettre une conversation saine sur les raisons pour lesquelles nous avions prévu d'implémenter des fonctionnalités spécifiques dans les prochains sprints, ce qui est utile pour les novices Agile. J'ai également choisi la nomenclature "jalons" - un terme utilisé dans la gestion de projet Waterfall - car elle était plus familière au client. Les revues et les interactions Scrum quotidiennes sont des éléments conventionnels du Scrum Guide, mais je les ai rendus plus structurés en termes de calendrier, de durée et de flux.

De plus, alors qu'une stricte adhésion à Scrum aurait chaque personne entièrement dédiée à l'un des rôles répertoriés dans le Guide Scrum, il y avait des personnes dans les équipes de mon client dont les compétences ne correspondaient pas parfaitement à un rôle. L'utilisation de la méthode Disciplined Agile m'a permis de répartir les responsabilités de ces postes entre plusieurs membres de l'équipe et de créer un processus qui jouait sur les forces des personnes impliquées.

Livraison de logiciels sur documentation

Une autre raison pour laquelle je préfère les flux de travail Scrum ou Kanban personnalisés à la stricte conformité avec n'importe quel cadre est qu'ils me donnent la possibilité d'ajouter le produit minimum viable (MVP) dans le plan en tant qu'objectif. Dérivée du Lean, la pratique de création d'un MVP est cohérente avec le développement itératif et est devenue une technique populaire parmi les praticiens Agile. Il permet à une équipe de fournir efficacement des logiciels et d'autres produits de haute qualité aux utilisateurs, puis de les affiner en fonction des commentaires. L'appliquer dans le cadre d'une approche hybride largement basée sur Scrum ou Kanban a renforcé les capacités de mes équipes à créer des produits répondant aux besoins des clients.

Je travaille actuellement avec une startup basée aux États-Unis et j'utilise cette méthode pour créer un marché de crypto-monnaie pour les NFT. Nous nous concentrons sur la création du MVP, nous n'écrivons donc que la documentation minimale nécessaire pour l'instant. Bien que cette approche soit efficace pour une large gamme de produits, elle est particulièrement utile pour la crypto-monnaie et les NFT, qui appartiennent à une nouvelle catégorie expérimentale qui évolue rapidement. Au lieu de rédiger des spécifications et des fonctionnalités complètes et de devoir les modifier à plusieurs reprises avant la publication, nous pouvons consacrer ce temps à intégrer les commentaires des utilisateurs pour améliorer le développement de notre marché.

Collaboration sur les contrats

L'organisation technologique de grande entreprise susmentionnée s'est fortement appuyée sur des contrats pour de nombreux projets à coûts fixes. Les contrats décrivaient les méthodes qu'ils utiliseraient pour terminer le travail, ainsi que les personnes spécifiques qui seraient responsables de chaque tâche. Une fois signés, les contrats ne pouvaient être modifiés sans un long processus de demande.

Une partie de la transformation que j'ai menée a donné la priorité à la collaboration par rapport à ces accords rigides. Le plan que nous avons mis en place a remplacé les contrats par des documents d'une page. Chacun a déclaré que nous avions accepté d'utiliser Agile pour travailler en collaboration - avec nos clients, ainsi qu'avec nos coéquipiers et collègues de différentes équipes - entre les dates de début et de fin désignées. Tout ce qui sortirait de la collaboration serait le résultat. Je n'ai pas inclus de détails sur ce que pourraient être les produits finis. Étant donné que nous sollicitions les commentaires des clients et que nous les incorporions dans le développement de nos produits, la suppression des spécifications de notre document de plan nous a rendus plus réceptifs à leurs réponses et les a incités à travailler plus activement avec nous.

Pour embarquer la direction, je leur ai demandé de me laisser diriger une preuve de concept avec une petite équipe travaillant avec un petit client, qui avait exprimé des inquiétudes quant au fait que les délais de développement étaient trop longs, avant même que les modifications requises n'aggravent le problème. En faisant collaborer directement ce client avec notre propriétaire de produit, nous avons pu apporter des modifications en cours de développement et réduire considérablement les délais de livraison.

Ces résultats ont persuadé la direction de me laisser déployer le plan auprès d'un plus grand nombre d'équipes. Dans l'ensemble, le contrat rationalisé et notre flux de travail Agile ont réduit le temps nécessaire pour développer et commercialiser les fonctionnalités du produit.

Adaptabilité sur les cadres

Un autre de mes clients, une entreprise de technologie de la santé, n'a pas non plus réussi à trouver un équilibre en termes de reconnaissance de l'importance des deux côtés d'une valeur Agile, à savoir réagir au changement plutôt qu'en suivant un plan. Dans ce cas, cependant, il avait fait le contraire de l'erreur commise par mon client de technologie d'entreprise : au lieu de suivre un processus de manière trop rigide, il avait surindexé la flexibilité tout en négligeant largement le processus. Les ingénieurs savaient rarement sur quoi ils devaient travailler car il n'y avait pas de priorités ni de calendrier. Ils perdaient du temps et de la productivité en essayant de comprendre cela chaque jour et accomplissaient des tâches moins importantes avant des tâches plus cruciales.

J'ai proposé la mise en œuvre de Scrum au PDG et au CTO, expliquant que les sprints obligeraient les ingénieurs à être disciplinés et à planifier par tranches de deux semaines, au lieu de décider sur quoi travailler chaque jour. De plus, j'ai conseillé d'embaucher un propriétaire de produit, ce qui résoudrait le manque de responsabilité de l'équipe vis-à-vis du produit. J'ai demandé aux dirigeants de me donner trois ou quatre mois pour travailler avec leurs équipes avant qu'ils ne puissent espérer voir des résultats.

Après avoir obtenu leur approbation, j'ai d'abord présenté les valeurs et principes Agiles, puis j'ai formé l'équipe sur le backlog produit et les différentes techniques pour l'organiser, y compris la création d'épopées et d'histoires d'utilisateurs, et la création de sous-tâches. Les techniques et les réunions que nous avons incluses dans notre flux de travail sont des écarts par rapport à Scrum traditionnel en ce sens qu'elles n'apparaissent pas dans le Guide Scrum. Je les ai intégrées dans le plan parce que les épopées, les histoires et les sous-tâches ont résonné avec les équipes pendant la formation et les réunions ont favorisé des discussions productives.

J'ai également inclus le concept de vélocité, un ajout tardif à XP qui mesure les estimations de l'effort total pour toutes les histoires d'utilisateurs dans chaque itération de produit. Cependant, j'ai utilisé le terme «capacité», que je préfère car il met l'accent sur la quantité de travail que les membres de l'équipe peuvent acquérir plutôt que sur la vitesse à laquelle ils peuvent accomplir les tâches.

Pour estimer, j'ai commencé avec la taille des t-shirts, une technique qui mesure les projets et les tâches en petits, moyens et grands ; Au fur et à mesure que l'équipe progressait, je suis passé aux points d'histoire, une technique d'estimation plus traditionnelle. Les points d'histoire sont souvent mal utilisés par des équipes non initiées à Agile, qui tentent de les convertir en heures ou en jours de travail, en se concentrant excessivement sur les délais et en jugeant les gens en fonction de leur capacité à respecter les délais.

La taille des t-shirts est plus abstraite, ce qui permet aux équipes d'éviter plus facilement cet écueil. Cependant, c'est aussi moins précis. Ainsi, une fois que l'équipe a compris comment estimer en termes relatifs, je les ai fait passer à la technique la plus sophistiquée.

Au moment où l'équipe a terminé deux sprints, la haute direction a pu voir ses employés travailler de manière plus productive et communiquer plus efficacement. Les développeurs s'engageaient pour la première fois avec les parties prenantes et la direction générale. Ils avaient rencontré l'équipe de support client et avaient compris comment les fonctionnalités qu'ils avaient implémentées amélioraient la vie des utilisateurs.

Cette approche a rapidement conduit à une augmentation de la qualité des logiciels de l'entreprise et à une réduction des délais de livraison des nouvelles fonctionnalités de plusieurs mois à plusieurs semaines.

Quel est l'avenir de l'agilité ?

La pandémie de COVID-19 a créé une nouvelle réalité dans laquelle les équipes ne pouvaient plus être colocalisées, ce qui était la façon préférée de travailler au sein d'Agile lors de sa conception. Cependant, l'idée qu'il doit en rester ainsi est un mythe : alors que le travail à distance est devenu monnaie courante, il est devenu clair qu'une communication rapprochée est tout à fait possible avec un logiciel de visioconférence. Les équipes avec lesquelles je travaille actuellement sont entièrement réparties et je dispense des formations à distance. Certaines équipes choisissent même de travailler de manière asynchrone, en utilisant des outils tels que Notion et Loom, ainsi que des plugins Slack comme Standuply.

Le modèle distribué de collaboration est le nouveau monde du travail, avec l'agilité en son centre. L'équilibre travail-vie accordé aux équipes distantes a un impact positif sur le moral et le bien-être mental, ce qui stimule la productivité et la qualité ; il place les gens au-dessus des processus et est flexible et adaptable, ce qui le rend essentiellement agile.

Les coachs agiles, les Scrum masters et les chefs de projet doivent revenir aux racines de la philosophie et la présenter comme l'ont fait les rédacteurs du manifeste : un ensemble flexible et dynamique de directives de développement et de livraison. Ils devraient enseigner aux cadres et aux chefs d'équipe que, même s'ils peuvent s'inspirer de la gestion de projet, ils ne gèrent vraiment rien en Agile, ils guident les équipes et les libèrent pour qu'ils fassent de leur mieux.