OVNI

OVNI — Observer avec des Valeurs Non Industrielles — est un outil mis au point par le collectif agile radical.

Objectif de l’outil

OVNI pousse les équipes agiles à intégrer les questions sociales et environnementales dans leurs réflexions sur les priorités des projets ou des fonctionnalités.
Nous parlons d’incitation avec OVNI, car nous pensons que :

la prise de conscience est le premier pas vers l’action.

Les actions futures consisteront à développer des produits et services plus respectueux des personnes et de la planète.

Présentation brève de l’outil

OVNI propose une représentation graphique simple pour cartographier la valeur.
Il s’agit de placer des éléments dans le cadran d’un plan cartésien. Plus simplement nous utilisons deux axes, un premier horizontal (l’axe des abscisses) et un second vertical (l’axe des ordonnées). Ces deux axes se croisent à leur origine.

• L’axe horizontal représente la valeur sociale,
• l’axe vertical la valeur environnementale (ou écologique).

En option, la valeur business peut être représentée par la surface de l’élément.

Le placement des éléments se pratique de façon collaborative pour déclencher des discussions entre les participants sur leur ressenti de la valeur.
L’observation, une fois le placement réalisé, aide à la décision pour ordonner le backlog.

Concepts

La valeur

C’est un but proclamé de l’agilité : chercher à maximiser la valeur. Plus la valeur d’un élément est importante, plus sa priorité est élevée et, comme la priorité définit l’ordre dans lequel les éléments du backlog sont réalisés, les éléments avec le plus de valeur sont développés en premier.

Les types de valeur

Traditionnellement la valeur considérée est la valeur business (ou valeur métier ou valeur économique ou valeur financière ou valeur marchande). Dans le Manifeste agile radical, nous avons proposé d’y ajouter les valeurs sociale et écologique.

Dans l’outil OVNI, nous suggérons de ne pas seulement les ajouter à la réflexion après celle de la valeur métier, mais d’inverser complètement la hiérarchie. En effet, les entreprises sont structurellement orientées vers la valeur économique et nous souhaitons changer radicalement cette orientation, en donnant la priorité aux impacts écologiques et sociaux.

La valeur repose sur des estimations

On a besoin d’avoir une idée de la valeur d’un élément avant de l’avoir développé, c’est pourquoi il faut l’estimer.

Mais ce n’est pas facile d’estimer la valeur ajoutée par une story ou une fonctionnalité !

L’expérience de plusieurs années sur la business value l’a montré, estimer la valeur financière absolue que va rapporter une story par un chiffre est une gageure. C’est pourquoi l’agilité pousse à faire des estimations relatives par exemple avec les tailles de tee-shirt (S,M,L,XL).

C’est ce que nous suggérons aussi pour les valeurs sociale et environnementale, avec par exemple, une graduation sur cinq niveaux de l’impact d’un élément du backlog :

• très négatif
• plutôt négatif
• neutre
• plutôt positif
• très positif

Nous conseillons de ne surtout pas donner un chiffre à ces valeurs, cela pousserait à les rapporter à une valeur économique.

Pour quels éléments ?

Dans le cadran d’OVNI, on place des éléments en fonction de leur valeur. Lesquels ?

Ces éléments qu’on va traiter avec OVNI peuvent être variables selon l’objectif qu’on poursuit. Si on utilise OVNI pour prioriser un portefeuille de projets, les éléments correspondront aux projets de l’entreprise. Si c’est pour prioriser un backlog d’équipe, les éléments seront des fonctionnalités (features) ou des stories.

Dans la suite de l’article, nous allons considérer que c’est au niveau du backlog d’équipe qu’OVNI est utilisé.

Story ou fonctionnalité ?

Même s’il existe des différences dans le vocabulaire, on retrouve généralement deux points de vue sur le backlog.

Au fil du temps, un élément du backlog a été appelé story. La tendance a fait que les stories sont devenues de plus en plus petites. C’est pour de bonnes raisons que nous ne présenterons pas ici. Mais cela a fait apparaître un problème : un petit morceau isolé n’est plus très compréhensible par les parties prenantes et un développeur a du mal à voir à quoi sert ce qu’il fait.
Jeff Patton (le créateur du Story Mapping) a mis en évidence cette situation de backlog trop plat. Il utilise la métaphore des astéroïdes pour décrire une approche de décomposition progressive et propose une carte pour s’y retrouver entre les gros et les petits morceaux. Au-delà de la taille des éléments, le plus important est l’usage qu’on en fait.

Après des années de pratique, nous sommes arrivés à la conclusion que le backlog servait deux points de vue :

• un s’adresse à l’équipe, contenant les petits morceaux sur laquelle elle travaille ou va travailler bientôt,
• l’autre pour communiquer avec les parties prenantes, qui contient des plus gros morceaux. Bien entendu, elle est aussi utile à l’équipe.

L’expérience montre qu’une story est trop petite pour être déployée individuellement et qu’il est plus raisonnable de réfléchir à la valeur pour des fonctionnalités.

Notion de Valuable Increments

Dans la deuxième édition de son livre The Art of Agile Development¹, James Shore présente la notion de Valuable Increment comme l’élément pour lequel la notion de valeur a un sens.

Valuable Increment remplace MMF — Minimal Marketable Feature — qu’il utilisait dans sa 1ère édition.

Dans notre esprit, une fonctionnalité qui a émergé après décomposition est l’équivalent de la notion de James Shore.

Nous lui donnons la définition suivante :

Une fonctionnalité est un service ou une fonction d’un produit dont l’énoncé est clair pour les parties prenantes ; elle constitue un incrément qui s’ajoute au produit et peut déclencher une nouvelle livraison ; elle contribue à un impact sur un utilisateur en lui procurant de la valeur.

C’est cette notion de fonctionnalité (ou feature) que nous allons prendre pour montrer comment s’utilise OVNI.

Déroulement de l’atelier OVNI

Le moment idéal pour un premier OVNI est pendant le prélude, avec une équipe constituée et qui s’est alignée avec les parties prenantes (voir l’outil CARE).

Préparation

Prérequis

Disposer d’un backlog initial comportant entre 7 et 15 fonctionnalités. Elles ont pu être identifiées par un atelier de Story Mapping, par exemple.

Avec qui

L’atelier OVNI accueille l’équipe et les parties prenantes.
Le Product Owner de l’équipe est le mieux placé pour animer l’atelier et apporter des réponses aux questions sur les fonctionnalités identifiées.

Première étape : rassembler vos features

Dans un premier temps, faites l’inventaire des features du produit (si ce n’est déjà fait au sein du backlog) et notez une feature par post-it sans accorder d’importance à leur valeur et donc sans autre marque distinctive que leur nom.

Le Product Owner répond aux questions éventuelles des participants.
Disposez ces features en vrac sur une table ou un tableau.

Nous utiliserons l’exemple PermaBio dans la suite de l’article.

Deuxième étape : valeur sociale & environnementale

Ensuite dessinez le plan cartésien suivant (plus exactement un cadran du plan cartésien) :

Dans cette deuxième étape les participants sont invités à positionner les features dans ce cadran en considérant la valeur sociale et environnementale. L’ensemble des parties prenantes peut positionner à tour de rôle une feature.

Suivez votre instinct pour ce classement.

Vous obtenez alors un premier positionnement des features au sein du cadran :

Troisième étape : repositionnement

Sans discussion, les participants sont maintenant autorisés à repositionner les features dans ce cadran. Cependant à chaque changement vous devez apposer une ou deux marques sur l’élément.
Vous apposez une marque sur le bord horizontal de la carte représentant la feature lorsque vous le déplacez suivant l’axe horizontal, c’est-à-dire l’axe représentant la valeur social.

Vous apposez une marque sur le bord vertical de la carte représentant la feature lorsque vous le déplacez suivant l’axe vertical, c’est-à-dire l’axe représentant la valeur environnementale.

Si la carte est repositionnée suivant les deux axes, vous apposez deux marques.

Pour une durée d’environ 5 à 8 minutes, réalisez ces changements.

Quatrième étape : discussions, échanges, synthèse

Les éléments n’ayant pas d’annotation ne font donc pas débat et sont laissés à leur place.

Les éléments ayant été repositionnés sont à discuter, c’est le moment d’échanger afin d’avoir le point de vue des parties prenantes. Si un consensus est trouvé pour leur positionnement, il convient alors de les placer.

Cinquième étape : faites maintenant apparaitre la valeur métier

Cette étape est optionnelle ; elle est omise pour une version radicale.

Créez de nouvelles cartes de tailles différentes (réprésentant la taille du T-shirt), la surface de la carte réprésentant la valeur métier de la feature. Les formats A5, A6, A7 et A8 sont, par exemple, de bons candidats mais libre à vous d’en imaginer des plus adaptés.

Vos features sont alors classées en fonction de leur valeur business, il se peut donc que plusieurs features soient dans la même classe Medium ou Large par exemple.

Une fois le classement réalisé vous obtenez ceci :

Reprenez le cadran précédemment établi et remplacez les post-it initiaux par ces nouvelles cartes, vous obtenez alors ceci.

Sixième étape : limite basse

Si l’équipe a décidé de se doter de limite basse ou zone rouge (CARE et KARMA peuvent contribuer à cette réflexion), il est alors possible de renoncer au développement des éléments se trouvant dans cette zone. Ce renoncement peut être que temporaire, cette prise de conscience encourage alors à mener une réflexion pour ces features.

Vous devriez maintenant avoir assez d’éléments pour prioriser le backlog au regard des trois dimensions métier, sociale et environnementale. Dans notre exemple, le développement peut être engagé pour les features compostage, préférences alimentaires, soupe, plats, entrées et dessert se trouvant au dessus des limites basses.

Quant à la feature mesrecettes.com le fait qu’elle soit en zone rouge va conduire à quelques séances de brainstorming si l’équipe souhaite explorer des pistes pour augmenter à la fois sa valeur écologique et sociale.

Il est possible d’écrire sur les cartes la valeur (relative) sociale et environnementale retenue.

Variantes

Produit existant

Cet atelier peut également se dérouler au niveau des features d’une application existante. Il est ainsi possible de cartographier la valeur des features existantes en considérant la valeur sociale, environnementale et business.

Selon le palier de maitrise de l’équipe

Les paliers sont présentés dans l’outil KARMA.

L’usage d’OVNI varie selon la maitrise de l’équipe, par exemple :

• Une équipe en quête de focalisation se préoccupera d’abord de la valeur sociale interne, c’est-à-dire la sienne. De même elle prendre en compte l’impact environnemental du développement qu’elle maitrise mieux, avant celui de l’utilisation du produit.
• Au palier technicité, une équipe prendra en compte la valeur sociale externe, c’est-à-dire avec toutes les personnes concernées par l’usage du produit. Pour les produits numériques, les questions sur le contrôle des données seront abordées. À ce même palier, l’impact sur le vivant lié aux usages des produits sera considéré. On s’intéressera à l’impact sur le climat et sur la biodiversité.