Définition de la transformation

De Wiki Agile
Aller à la navigation Aller à la recherche

Auteurs : Jon Moore et Marty Cagan
Source : Transformation Defined
Date : 31/05/2022


Traducteur : Fabrice Aimetti
Date : 16/11/2022


Traduction :

Il y a tellement d'anti-patterns quand il s'agit de transformation.

Beaucoup d'entre nous ont été témoins de transformations ratées, mais peu ont été témoins de véritables réussites. Ce qui fait que les leçons tirées des transformations réussies sont exceptionnellement précieuses. Nous avons l'intention d'écrire davantage sur les anti-patterns et les leçons tirées des réussites.

Une question que nous recevons assez fréquemment est la suivante : "Qu'est-ce qu'une entreprise qui s'est transformée peut faire de mieux qu'une entreprise qui ne l'a pas fait ?".

Comme nous, dans le monde des produits, parlons beaucoup de résultats, nous pensons que c'est la bonne question. Et nous avons privilégié les capacités et les résultats des entreprises qui se sont transformées, notamment la capacité à répondre aux menaces et à exploiter de nouvelles opportunités.

Mais en supposant que les dirigeants d'une entreprise pensent qu'ils doivent vraiment se transformer, qu'est-ce que cela signifie vraiment ?

Beaucoup d'entre vous nous ont entendu dire des choses comme : "La transformation vers l'Agilité est peut-être nécessaire, mais en aucun cas suffisante."

Ou encore, "le cœur de la transformation est de passer d'équipes features à des équipes produits émancipées".

Ou encore, "l'objectif est de se transformer en une entreprise dirigée par les produits".

Bien que chacun de ces commentaires puisse parler d'un aspect spécifique de la transformation, ils ne donnent pas une bonne image globale de ce que signifie vraiment la transformation.

C'est pourquoi, récemment, nous avons commencé à adopter une approche différente.

Au lieu d'appliquer une étiquette ("Agile", "Equipes émancipées", "Entreprise dirigée par le produit"), nous avons trouvé utile d'examiner ce qui change réellement :

1. Changez la façon dont vous construisez et déployez

Malgré l'existence de la méthode Agile depuis de nombreuses années, il y a encore beaucoup trop d'entreprises qui s'en tiennent à des versions trimestrielles (ou pire) et à des versions big-bang. L'essor du faux agile permet à ces entreprises de se faire passer pour agiles, sans pour autant améliorer de manière significative leur façon de construire.

Notre entreprise et nos clients ont besoin que nous ayons des véhicules de livraison fiables, cohérents et fréquents. Si vous ne pratiquez pas la livraison continue, vous devriez au moins publier de véritables versions au moins toutes les deux semaines. Notez que vous n'avez pas besoin des méthodes agiles pour y parvenir, mais le passage à l'agilité est souvent la force qui permet d'y parvenir.

Voir ici pour plus de détails sur le changement de la façon dont vous construisez.

2. Changez la façon dont vous résolvez les problèmes

C'est l'essentiel de ce que signifie le passage des Équipes features aux Équipes produits (fr) émancipées.

Au lieu que les parties prenantes classent par ordre de priorité les solutions qu'elles envisagent ( features et projets ) et les fournissent sous la forme d'une feuille de route à une équipe feature, c'est maintenant l'équipe produit qui se voit attribuer les problèmes à résoudre, et l'équipe produit est habilitée à découvrir une solution qui soit de valeur, utilisable, faisable et viable.

En pratique, cela signifie qu'il faut développer les compétences nécessaires à la découverte de produits et s'assurer que vos ingénieurs et concepteurs de produits disposent d'un véritable Product Manager (compétent en matière de clients, de données, d'activité et de secteur d'activité) afin que l'équipe produit dispose des compétences pluridisciplinaires nécessaires pour réussir.

Il est important de noter que ce changement implique une nouvelle relation avec les parties prenantes de l'entreprise, où l'équipe produit passe d'une relation de subordination à une relation de collaboration où l'équipe produit doit découvrir une solution que les clients aiment et qui fonctionne pour l'entreprise.

Voir ici pour plus de détails sur le changement de la façon dont vous résolvez les problèmes.

3. Changez la façon dont vous choisissez les problèmes à résoudre

Acquérir des compétences en matière de découverte de produits afin que vos équipes puissent résoudre systématiquement et rapidement des problèmes difficiles d'une manière qui plaise à vos clients tout en étant rentable pour votre entreprise est un progrès considérable, mais cela ne répond pas à la question "comment avez-vous décidé que ce problème était le plus important à résoudre".

Chaque entreprise est confrontée à de nombreuses menaces et à de nombreuses opportunités. Les menaces que vous prenez au sérieux et les opportunités que vous décidez de saisir peuvent faire la différence entre le succès et l'échec.

Une entreprise forte, orientée produit, a une vision produit convaincante et une stratégie produit basée sur les prises de conscience pour identifier les problèmes les plus critiques à résoudre afin d'atteindre les objectifs métiers.

Voir ici pour plus de détails sur la façon de changer la façon dont vous décidez des problèmes à résoudre.

Quelques notes importantes

Tout d'abord, ces trois changements dépendent de solides leaders produits (responsables de la gestion des produits, de la conception des produits et de l'ingénierie), et j'espère que vous comprenez pourquoi le leadership produit est difficile. Les membres des équipes produits auront besoin d'un coaching et d'un soutien stratégique. Si vos leaders produits n'ont pas eux-mêmes les compétences nécessaires, c'est là qu'il faut trouver un coach en leadership produit.

Deuxièmement, il semble évident de traiter chacun de ces trois points comme les étapes d'une progression, et c'est effectivement une façon d'aborder la transformation d'une entreprise, mais ils peuvent en fait être menés en parallèle. Plutôt que de penser à ces trois étapes comme à une progression, nous recommandons généralement de poursuivre les trois (ou tout sous-ensemble qui n'a pas encore été accompli) en parallèle, mais en le faisant avec une ou quelques équipes pilotes, ou un sous-ensemble de l'organisation, puis en étendant la transformation à partir de là.

Résumé

Donc, pour résumer :

Changer la façon dont vous construisez et déployez signifie passer des grosses versions trimestrielles à une cadence de petites versions cohérentes.

Changer la façon dont vous résolvez les problèmes signifie passer de feuilles de route dirigées par les parties prenantes et d'équipes features, à des équipes produits émancipées à qui l'on donne des problèmes à résoudre, puis qui utilisent la découverte de produits pour trouver des solutions qui sont de valeur, utilisables, faisables et viables.

Changer la façon dont vous décidez des problèmes à résoudre est généralement le changement le plus radical de tous, car cela détermine les opportunités que vous choisissez de saisir et la façon dont vous tirez le meilleur parti de l'investissement que vous faites, y compris la vision et la stratégie du produit.

Nous espérons que ce cadrage vous aidera à réfléchir de manière plus globale à la transformation dont votre entreprise pourrait avoir besoin, et à déterminer où vous en êtes dans ce processus.

Un grand merci à Chris Jones pour son aide dans cette publication.