Comment faire évoluer le développement logiciel agile avec la technologie et le Lean

Le développement de logiciels agiles peut être réalisé à grande échelle grâce à l’utilisation de technologies telles que les API en libre-service, le provisionnement d’infrastructure, les logiciels de collaboration en temps réel et les systèmes de gestion de versions distribués. Le Lean peut compléter et faire évoluer une culture agile avec des techniques telles que l’obéias, la résolution systématique de problèmes, le flux monobloc et le takt time, ainsi que le kaizen. Fabrice Bernhard a expliqué comment son entreprise utilise la technologie avec une pensée Lean pour réaliser du développement logiciel agile à grande échelle lors de FlowCon France.

Le manifeste agile ne s’applique pas aux grandes organisations, a déclaré Bernhard. Les dirigeants à la recherche de principes pour maintenir leur culture agile tout en faisant évoluer leur organisation logicielle devront chercher ailleurs. Et malheureusement, cet « ailleurs » regorge désormais d’options dites « agiles à grande échelle », dont beaucoup sont très bureaucratiques et ne correspondent donc pas à l’esprit du manifeste agile, a-t-il mentionné.

Agile peut évoluer, a déclaré Bernhard ; il existe de nombreux exemples d’organisations qui ont évolué tout en conservant une culture agile. Dans l’ensemble des connaissances sur la pensée Lean, ils ont trouvé les principes qu’ils recherchaient pour faire évoluer leur organisation tout en restant fidèle au manifeste agile.

Dans le livre The Lean Tech Manifesto que Bernhard a écrit avec Benoît Charles-Lavauzelle, il explore les principes, systèmes et outils que la pensée Lean fournit pour étendre les principes du manifeste agile. Il a cité quelques exemples :

• Modèles de valeur, obéissance et flux de valeur, pour faire évoluer la « collaboration client » en garantissant que la « valeur pour le client » devienne l’étoile polaire de l’ensemble de l’organisation.
• Résolution systématique de problèmes avec PDCA et 5S, soutenue par les chefs d’équipe et rendue possible dans notre monde numérique par la technologie de collaboration, pour faire évoluer « les individus et les interactions » et transformer l’organisation en un « réseau d’équipes technologiquement avancé ».
• Jidoka, dantotsu, poka-yoke, pull, one-piece-flow et takt time, pour mettre en œuvre le « bon du premier coup et juste à temps » et faire évoluer les « logiciels de travail »
• Normes, Kaizen, matrice de compétences et communautés de pratique, pour « répondre au changement » avec « la construction d’une organisation apprenante »

Bernhard a mentionné qu’ils estimaient que la pensée Lean n’expliquait pas entièrement la réussite de certaines grandes organisations agiles. Il a décidé d’explorer comment le projet open source Linux et sa communauté sont passés de 1 à 55 000 contributeurs, où ils ont utilisé la technologie pour résoudre les problèmes de mise à l’échelle auxquels ils ont été confrontés en cours de route :

La première crise d’ampleur s’est produite en 1996, lorsque Linus a écrit qu’il était « enterré vivant dans des courriels ». Ce problème a été résolu en adoptant une architecture plus modulaire, avec l’introduction de modules de noyau chargeables et la création du rôle de mainteneur, qui aide les contributeurs à garantir qu’ils mettent en œuvre les normes élevées de qualité nécessaires pour fusionner leurs contributions.

La deuxième crise de mise à l’échelle a duré de 1998 à 2002 et a finalement été résolue par l’adoption de BitKeeper, remplacé plus tard par Git. Cela a réparti le travail de fusion des contributions à travers le réseau de responsables et de contributeurs.

Dans les deux cas, la technologie a été utilisée pour réduire le nombre de dépendances entre les équipes, aider les contributeurs à conserver un haut niveau d’autonomie et faciliter la fusion de toutes ces contributions dans le référentiel principal, a déclaré Bernhard.

La technologie peut contribuer à réduire le besoin de communiquer entre les équipes lorsqu’elles dépendent d’une autre équipe pour accomplir leur travail. Les dépendances organisationnelles typiques, par exemple lorsqu’une équipe s’appuie sur les données d’une autre équipe, peuvent être remplacées par des API en libre-service utilisant les technologies et la bonne architecture, a mentionné Bernhard. Cela peut être étendu à des dépendances plus complexes, telles que le provisionnement de l’infrastructure, comme AWS l’a fait en inventant EC2, en proposant des API en libre-service pour faire fonctionner des serveurs virtuels, a-t-il ajouté.

Un autre type de dépendance concerne le défi de fusionner les contributions apportées à un document similaire, qu’il s’agisse d’une illustration, d’un texte ou d’un code source, a mentionné Bernhard. Cela a été transformé au cours des 15 dernières années grâce aux logiciels de collaboration en temps réel tels que Google Docs et aux systèmes de gestion de versions distribués tels que Git, a-t-il déclaré.

Bernhard a mentionné qu’il a beaucoup appris de la façon dont la communauté Linux a résolu ses problèmes de mise à l’échelle. Et là où les premières méthodologies agiles, telles que Scrum ou XP, se concentrent sur une seule équipe d’ingénieurs logiciels, la pensée Lean a été testée à grande échelle depuis des décennies dans de très grandes organisations, a déclaré Bernhard. Quiconque tente de faire évoluer une organisation agile devrait étudier la pensée Lean pour bénéficier de décennies d’expérience sur la manière de diriger de grandes organisations tout en restant fidèle à l’esprit du manifeste agile, a-t-il conclu.