L'impact sur le vivant comme critère pour définir les priorités
Nous voulons des coquelicots !
Le Manifeste agile met en avant la collaboration avec le client plus que la négociation du contrat. Dans notre précédent article, nous avons constaté qu’en fait, sur le terrain, ce qui s’est passé dans les équipes agiles, c’est :
la coopération avec le Product Owner plus que la collaboration avec le client
C’est bien. Mais il est temps d’aller encore plus loin.
Pourquoi aller plus loin
La coopération avec le PO n’empêche pas d’avoir de fréquentes rencontres et conversations avec les utilisateurs ; mais cela n’empêche pas non plus que le PO, qui est imputable du résultat auprès des parties prenantes, oriente le produit vers la satisfaction des actionnaires plus que vers celles des utilisateurs en ignorant son utilité sociale et écologique.
L’agilité radicale est née pour donner une dimension plus démocratique, solidaire et écologique au développement de produits et services. C’est pourquoi cela nous conduit à revisiter le rôle de PO dans sa responsabilité de prioriser le backlog, pour intégrer cette dimension.
Prioriser dans le VRAI
Prioriser est un néologisme souvent utilisé, et pas que pour un backlog. Avec Scrum, on dit que le PO priorise les éléments du backlog.
À propos des critères pour prioriser
J’ai écrit des dizaines d’articles sur cette question de la priorité. J’en ai fait des sujets de conférence, des jeux ; j’ai écrit des parties significatives de mes livres sur le sujet. J’ai évolué, comme d’autres, sur cette notion délicate, conscient que se baser uniquement sur la valeur métier (business value) n’est pas tenable. Par exemple, je me suis intéressé il y a 10 ans à la notion d’utilité ; puis j’ai mis en avant les critères VRAC ; plus récemment, et cela figure dans l’édition 5 de Scrum, je conseille de commencer à prioriser les impacts attendus (outcomes) plutôt que de le faire sur une liste de fonctionnalités et encore moins de stories.
J’en reviens à la façon dont on peut prendre en compte la transition écologique dans le développement de produits et services. Une réponse pratique est de l’ajouter comme critère pour définir la priorité des fonctionnalités à réaliser.
Un Product Owner avec son équipe s’appuient déjà sur la valeur métier (business value), la réduction du risque et l’apprentissage (knowledge value ou learning value) pour définir les priorités ; en y ajoutant la question de l’impact sur le vivant, ils seraient dans le VRAI :
- Valeur métier
- Réduction des risques
- Apprentissage
- Impact sur le vivant
Car le développement et l’utilisation d’un produit impacte les écosystèmes sociaux (l’équipe, les utilisateurs) et plus largement les écosystèmes vivants. Il y a des impacts positifs (la valeur métier en est un) mais aussi des impacts négatifs (le stress sur les équipes, l’inégalité des utilisateurs, et bien sûr toute l’énergie extraite des écosystèmes vivants pour faire fonctionner les infrastructures de développement et de production).
Retour au manifeste
Nous sommes partis du Manifeste agile. En 2001, il énonce que définir le périmètre d’un logiciel à partir d’un document n’est pas une bonne idée et qu’il vaut mieux que l’équipe échange avec le client.
Depuis, l’importance d’impliquer les utilisateurs dans les boucles de feedback et d’intégrer leur représentant dans l’équipe a fait son chemin. Maintenant il est temps, en adoptant une approche systémique, de se préoccuper de l’impact sur les écosystèmes (utilisateurs et au-delà). C’est le souhait de beaucoup de développeurs et aussi d’utilisateurs que nous avons rencontrés.
C’est l’ambition de l’agilité radicale de les encourager à maximiser l’impact positif sur le vivant tout en diminuant radicalement la consommation de matière et d’énergie.
C’est pourquoi le 3e item du Manifeste agile radical est :
la collaboration avec le client plus que la négociation du contrat, mais l’impact sur le vivant encore plus que la collaboration avec le client
Photo (prise dans le Lauragais) en référence à l’appel Nous voulons des coquelicots !
