LeSS - Organisation en fonction de la valeur client

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher
Auteur : The LeSS Company B.V.
Source : Organizing by Customer Value - Large Scale Scrum (LeSS)

Traducteur : Fabrice Aimetti
Date : 06/01/2017


Traduction :

LeSS - Portail Structure

Dans une petite équipe produit, l'organisation en fonction de la valeur client est simple. Plus il y a d'équipes, plus elles deviennent des rouages dans la grosse machine du développement. A l'image de Charlie Chaplin dans les Temps Modernes, leur travail est de tourner les écrous mais ils n'ont aucune idée sur la façon dont le client va utiliser le produit... ou même qui est réellement le client. Comment passer à l'échelle et rester focalisé sur le client ?

modern-times-charlie-chaplin.jpg

Équipes pluridisciplinaires

Construire des équipes (fr) pluridisciplinaires est essentiel pour rester focalisé sur le client. Lorsque nous travaillons dans une organisation en silos, nous créons les étapes d'un processus dans lequel la personne suivante devient "notre client". Mais ces clients internes ne sont pas réellement des clients. Avec des équipes pluridisciplinaires, nous changeons complètement de perspective, nous donnons un élément à réaliser à l'équipe et nous laissons l'équipe entière focalisée sur une feature centrée sur le client. L'équipe, qui travaille sur une période courte, devra découvrir comment finir le travail à réaliser durant le sprint tout en restant focalisée sur le client.

Équipes feature

Comme pour les équipes pluridisciplinaires, les équipes feature se focalisent sur le client et s'organisent autour de la valeur client. Les équipes feature choisissent une feature centrée sur le client et "la réalise complètement". Cela permet à l'équipe de parler le même langage que les clients et de supprimer les barrières entre les clients et les utilisateurs réels du produit... donc moins d'intermédiaires.

Spécialisation selon un axe client

Une incompréhension fréquente dans les équipes feature, c'est que l'on doit abandonner la spécialisation. Une part d'incompréhension provient d'une fausse dichotomie entre, soit se spécialiser sur un composant, soit ne pas se spécialiser du tout, c'est un point que nous abordons dans le chapitre sur les équipes feature. Une part d'incompréhension provient de la croyance que la spécialisation est une chose à un seul axe, se spécialiser sur un composant. Mais la spécialisation est à plusieurs axes.

LeSS rapproche les utilisateurs et les développeurs car la perspective utilisateur est presque toujours perdue dans les groupes traditionnels qui travaillent sur un gros produit. Les équipes feature constituent un moyen de s'organiser selon la valeur client mais ce n'est pas le seul. Préférer la spécialisation sur un domaine client mène à d'autres décisions structurantes. Par exemple :

Les banques créent des applications mobiles pour des services bancaires. Les groupes produit sont typiquement organisés par plateforme : (1) les équipes iOS, et (2) les équipes Android. Ces équipes sont des équipes feature et sont spécialisées selon un axe technique, ici la plateforme. Sinon, elles pourraient être organisées selon les domaines du client, tels que (1) les paiements en ligne, (2) l'administration et (3) le reporting. Cela conduit les équipes à implémenter le même type de features sur de multiples plateformes au lieu d'implémenter plusieurs types de features sur une seule plateforme.

Quel est le meilleur axe de spécialisation ? Les organisations traditionnelles ont tendance à se spécialiser selon des axes technologiques. Pourquoi ? Peut-être parce cela paraît trop difficile de faire autrement et que la spécialisation selon cet axe conduit à des développements plus rapides. Mais, dans LeSS, nous préférons la spécialisation selon les domaines client pour augmenter les possibilités de collaboration avec des utilisateurs réels et supprimer les intermédiaires.

L'hypothèse qui est faite dans les organisations traditionnelles, c'est que se spécialiser autour de la technologie c'est "mieux". Mais est-ce vrai, surtout lorsque le secteur a mûri (et vieilli) et qu'être polyglotte, développer avec plusieurs langages de programmation, est devenu fréquent ? Et est-ce vrai selon une perspective client ? Scrum et LeSS ont tendance à préférer une spécialisation selon l'axe client.