Série - PermaScrum

Fil des billets - Fil des commentaires

Permaculture et agilité au 100e singe

Panneau perma

La permaculture, c'est un sujet qui intéresse de plus en plus de monde parmi les agilistes et je m'en réjouis. L'apport de la permaculture à l'agilité, nous en débattrons le 21 mars.

L'association Agile Toulouse organise un événement Permaculture et agilité au 100e singe, le nouvel espace près de Toulouse pour inventer le lieu de travail de demain.

Pour celles et ceux qui ne connaissent pas encore, la permaculture est une approche systémique qui permet de construire des écosystèmes viables en s'inspirant des lois de la nature.

David Holmgren, l'un des deux fondateurs de la permaculture a publié un petit document "L'essence de la permaculture", disponible en version française.

Il y présente 12 principes (dits de conception). On trouve une version résumée de ces principes, traduite par Fabrice.

Lors de la soirée du 21 mars, après la présentation de Pierre Besse (un pionnier toulousain de la permaculture), nous reviendrons avec Benjamin sur la façon dont ces principes peuvent enrichir (ou pas) Scrum et l'agilité.

Nous en avions parlé lors du walkingDev à Toulouse l'été dernier. Depuis j'ai approfondi le sujet, qui fera partie des nouveautés dans l'édition 5 de Scrum.

Inscriptions sur le Meetup Agile Toulouse.

Observer et interagir

La permaculture a le vent en poupe. Chez les agilistes aussi.

Deux événements organisés par l'association Agile Toulouse en témoignent :

De mon côté, la permaculture aura une bonne place dans les nouveautés de mon édition 5 de Scrum. Nous en parlerons le 25 mai lors de Sea, Scrum and Sun.

Pour préparer la soirée du 21 mars, je propose une réflexion sur les principes de la permaculture, tels qu'ils sont énoncés dans l'article de David Holmgren. Commençons par le premier.

Principe 1 : Observer et interagir

À qui s'adressent ces recommandations ? Je pense que c'est à ceux qui font le design en permaculture. Les principes de David Holmgren sont appelés principes de design, et dans les formations à la permaculture, le design prend une place importante.

Si on transpose à l'agilité, observer et interagir s'adresse d'abord à l'équipe Scrum. En permaculture agricole, la conception de l'espace (le design) détermine ce qui va être produit (les résultats). En agilité, la conception des produits qu'on va fabriquer est décorrélée de la conception de l'espace de travail, qui a généralement peu d'importance. Sûrement pas assez, c'est pourquoi je propose de reprendre la notion de zones venant de la permaculture.

Donc pour une équipe Scrum, il s'agit d'abord d'observer. Pour faire le bon produit, il faut observer les futurs utilisateurs. Rapprocher les développeurs et les utilisateurs (ou leurs représentants), cela fait partie de ce que préconise l'agilité. Ce que peut nous apporter la permaculture, c'est une meilleure observation de l'espace de travail. Pour bien faire le produit, l'équipe devrait avoir la possibilité d'agencer cet espace à sa convenance.

Observer et interagir. Les interactions entre les gens, c'est au tout début du Manifeste Agile, nous sommes en terrain connu. Ce que met en avant Holmgren dans ce principe, c'est que ce sont l'observation et les interactions entre les gens sur le terrain (dans l'écosystème) qui vont permettre de faire le design, et que celui-ci ne doit pas être imposé par d'autres : "plutôt que … un système préconçu imposé de l'extérieur".

Très bien ! avec Scrum cela se décline sur :

  • le produit, c'est l'équipe qui le conçoit en collaboration avec les parties prenantes, pas un architecte externe tout puissant,
  • le processus, que l'équipe s'approprie par son auto-organisation et améliore régulièrement, plutôt que se voir imposer une façon de travailler.

Le proverbe associé à ce principe est :

la beauté est dans les yeux de celui qui regarde.

En le présentant, David Holmgren fait référence à une notion de systémique, associée à l'approche constructiviste appelée aussi seconde cybernétique : la présence d'un observateur dans le système modifie le système.

On peut le comprendre comme une incitation à l'observation. On peut aussi l'interpréter comme une insistance sur interagir (d'où observer ET interagir) : sans interactions, l'observation ne suffit pas et risque de mener à un résultat inadapté.

Collecter et stocker l'énergie

On continue dans la permaculture et l'agilité, pour se préparer à la soirée du 21 mars.

Aujourd'hui le 2e principe de la permaculture.

Principe 2 : collecter et stocker l'énergie

C'est un principe qui, à première vue, est éloigné de l'agilité. Quand on développe avec Scrum, on ne se préoccupe pas de collecter et stocker l'énergie.

L'idée développée par David Holmgren est de collecter des énergies locales plutôt que de continuer à prélever des ressources à un niveau qui n'est plus soutenable. Il parle d'une définition inappropriée de la richesse qui nous a amené à faire de mauvais choix.

On peut rapprocher cela de la pratique des développements offshore où l'on va exploiter des personnes dont le coût est plus faible. Ces personnes sont considérées comme des ressources interchangeables. On est là aussi dans une définition inappropriée, si ce n'est de la richesse, du moins de la valeur rapportée au coût global, celui de toute la chaine.

L'agilité promeut plutôt des équipes co-localisées et stables, pour pérenniser une pratique vivante. C'est ça l'énergie primaire dans Scrum. L'idée est d'investir à long terme dans le capital naturel constitué par les gens de l'écosystème. On peut le voir aussi pour l'espace de travail, pour lequel on profite des moyens financiers en début de projet pour l'aménager.

Dans la 2e partie consacrée à ce principe, Holmgren évoque la légitimité à employer la technologie et l'informatique pour créer des produits. La permaculture n'est pas un retour au passé.

Le proverbe Faites les foins tant qu'il fait beau me fait penser à la notion de valeur qui évolue dans le temps, amenant à ce qu'on appelle le coût du délai.

Créer une production

Les inscriptions continuent à affluer pour la soire Permaculture et agilité au 100e singe.

En attendant, voici mes réflexions sur le principe 3.

Principe 3 de permaculture : Créer une production

Avec ce principe, on retrouve des convergences avec des notions fréquemment mises en avant avec l'agilité.

Depuis longtemps, le développement itératif et incrémental nous a appris à produire des résultats vite et souvent. Cette orientation résultat est un des arguments utilisés pour pousser l'agilité à la place des processus séquentiels comme le cycle en V, dans lequel on rentre dans un long tunnel avant de voir quelque chose qui fonctionne.

Un des points clés de Scrum est d'avoir à la fin du sprint un résultat prêt à la mise en service.

Holmgren donne deux autres recommandations dans ce principe, que l'agilité a déjà faites siennes :

  • bâtir (la confiance) sur des succès,
  • faire (un résultat) fonctionnel et utile.

En fin de sprint, cela correspond à célébrer les succès et produire de la valeur.

Le proverbe on ne peut pas travailler l'estomac vide renforce cette idée d'équipe nourrie par des résultats obtenus rapidement. Nous avions illustré cela, lors de notre présentation à Agile tour Toulouse 2017 avec Benjamin, par ce dessin de Patrice Courtiade (qui a fait de nouveaux dessins pour mon édition 5 de Scrum).

on a une tomate - Copie.png

À propos de ce principe, Holmgren met en avant la systémique en évoquant une boucle de rétroaction positive, qui correspond à l'idée de développement incrémental où chaque morceau vient s'ajouter et s'intégrer aux précédents. Le produit est en expansion continue, tant que le résultat d'un sprint incite à en vouloir plus.

Appliquer l'auto-régulation et accepter la rétroaction

La permaculture, ce n'est pas seulement agricole. D'ailleurs "Permaculture humaine" c'est le titre du livre qui a été choisi pour le prochain klub de lecture, en avril.

Je poursuis l'examen des principes avec le regard de l'agilité. Voici le 4e des 12 principes, énoncés dans L'essence de la permaculture de David Holmgren.

Principe 4 : Appliquer l'auto-régulation et accepter la rétroaction

David Holmgren profite de ce principe pour nous expliquer un point essentiel de l'approche systémique : les boucles de rétroaction.

C'est la cybernétique qui a défini les deux types de rétroaction :

  • la rétroaction positive qui crée l'expansion.
  • la rétroaction négative qui est au cœur de la régulation.

Pour faire le lien avec Scrum, on pourrait dire que l'incrément de produit qui grossit à chaque sprint est un exemple de rétroaction positive. L'utilisation de la vélocité est un exemple de rétroaction négative : on ajuste la capacité d'un sprint en fonction de la vélocité mesurée.

Je n'avais pas compris le proverbe associé en première lecture : les fautes des pères rejailliront sur les enfants jusqu'à la 7e génération.

Une boucle de rétroaction externe (par exemple par des personnes qui ne sont pas dans l'écosystème) met du temps à avoir de l'effet. On a donc intérêt à avoir des boucles de feedback courtes et de favoriser la rétroaction négative pour éviter des expansions incontrôlables.

Un backlog de plusieurs centaines d'éléments, comme on en voit parfois, est un exemple d'expansion néfaste.

Holmgren déclare qu'avec ce principe, les économies d'échelle et les avantages de la spécialisation s'amenuiseront. Cela s'applique aussi à l'équipe Scrum auto-organisée.

Utiliser et valoriser les ressources et les services renouvelables

Permaculture et agilité 5/12

Dans permaculture, il y a permanence. On retrouve cette idée de durée dans le 8e principe du Manifeste agile, celui qui parle de rythme soutenable.

Principe 5 : Utiliser et valoriser les ressources et les services renouvelables

Ce principe me fait penser à Henrik Kniberg. Le plus brillant des pédagogues de l'agilité a réalisé une vidéo (VF) expliquant le réchauffement climatique.

C'est une animation dans la veine de ce qu'il avait réalisé pour le Product Ownership, et tout aussi remarquable.

Racontée par Holmgren, la plaisanterie de la corde à linge (le sèche-linge solaire) me fait penser aux outils simples que nous défendons dans l'agilité.

Il y a bien longtemps (en 2009 ! c'était à l'époque où j'étais encore Product Owner d'iceScrum), j'avais écrit un billet de blog titré "Jira pas", qui n'avait pas été apprécié par tout le monde. Maintenant Jira est très utilisé mais est aussi devenu une usine à gaz… Il y a des tweets qui circulent sur Jira et l'agilité.

Les outils simples de management visuel répondent à mon avis à la plupart des besoins, un outil n'ayant du sens que quand l'équipe n'est pas co-localisée.

Certes, les notes collantes ne sont des ressources renouvelables. Mais on peut s'appuyer sur l'étude comparative de Matti Schneider pour choisir ceux qui ont le moins d'impact.

David Holmgren propose d'utiliser des animaux pour remplacer l'usage du tracteur ou du motoculteur. Le dessin pour illustrer ce principe est un cheval et Il cite les cochons et les poules, une référence subliminale à Scrum ?

Le proverbe associé est : Laissons faire la nature. Il peut-être transposé à l'équipe : "Laissons faire l'équipe (pour s'organiser pendant le sprint)".

Ne pas produire de déchets

perma6.png

Principe 6 de la permaculture : Ne pas produire de déchets

Ce principe est illustré par le ver de terre, ce qui fait comprendre le titre comme ne pas produire de déchets à l'extérieur de l'écosystème. Les vers de terre de l'écosystème se chargent de recycler les déchets.

Le premier proverbe est : Pas de gaspillage, pas de manque.

Holmgren utilise une définition de Bill Mollison, l'autre fondateur de la permaculture : un polluant (déchet) est un produit de n'importe quelle partie d'un système qui n'est pas utilisé de manière productive par une autre partie du système.

Cela me fait penser à des fonctions d'un produit qui ne sont utilisées par les utilisateurs finaux. Une enquête montrant qu'un nombre important de fonctionnalités développées ne sont pas utilisées a longtemps circulé dans les présentations d'introduction à l'agilité, pour illustrer le gâchis avec les processus basées sur une spécification détaillée au départ. En considérant l'équipe de développement comme un système, ce qu'elle produit et qui n'est pas utilisé de manière productive par les parties prenantes constitue donc du déchet.

L'auteur évoque aussi Bill Mollison à propos de la notion de problème, bien connue aussi avec Scrum (on appelle ça un obstacle).

Pour illustrer l'idée que le problème d'un élément est la solution d'un autre élément, Bill prenait l'exemple d'un jardin dont les jeunes pousses sont attaquées par les limaces (c'est un problème courant des jardiniers) en disant : ce n'est pas qu'il y a trop de limaces, c'est qu'il manque des canards (les fameux canards coureurs indiens qu'on voit dans le film L'éveil de la permaculture).

Ce principe possède un deuxième proverbe : Un point à temps en vaut cent.

Il m'évoque l'affinage et la dette technique. L'idée est de faire un entretien régulier (sur le backlog, sur le code) plutôt que des gros travaux de restauration, qui sont très coûteux. C'est très Scrum.

Partir des structures d'ensemble pour arriver aux détails

Les 6 premiers principes de la permaculture que vous avons présentés considéraient l'élément, tandis que les 6 suivants vont partir du système.
Nous passons donc d'une approche bottom-up à du top-down.

Principe 7 : Partir des structures d'ensemble pour arriver aux détails

Ce principe s'appuie sur le premier principe "Observer et interagir", dans lequel il s'agissait d'identifier des formes. On pourrait dire pattern à la place de forme, peut-être. Holmgren évoque ici la similarité (des formes) comme un concept important pour le design. On cherche dans l'observation des similitudes avec ce que l'on a déjà rencontré ou avec ce qu'on trouve dans la nature (biomimétisme).

Le dessin associé à ce principe est une toile d'araignée. Avec ces cercles concentriques et ses radiales, une toile suggère des zones.

Le zonage est une notion clé en permaculture. Dans mon édition 5 de Scrum, j'ai repris cette idée pour l'adapter à l'espace de travail d'une équipe.

Partir des structures d'ensemble avant d'arriver aux détails, c'est en résonance avec l'approche agile, que ce soit pour la spécification (le quoi) ou la conception (le comment).

Mes premiers billets de blog, en 2006-2007, mentionnaient le BRUF ou le BDUF (big requirements/design up front) comme antipatterns de l'agilité.

Le proverbe associé est : c'est l'arbre qui cache la forêt.

Dans un backlog, une story détaillée au milieu de nombreuses autres aussi détaillées ne permet pas d'avoir la vision. C'est pourquoi je conseille de faire 2 parties dans un backlog : une partie pour que les parties prenantes y voient clair, c'est le backlog de fourniture qui contient des fonctionnalités, et l'autre contenant les stories et servant au travail de l'équipe.