fabernovel loader

Sep 19, 2018 | 7 min de lecture

Transformation

L'organisation agile ne se fera pas en un jour

Alexis Godais

CEO FABERNOVEL CODE


FABERNOVEL CODE
Les méthodes agiles sont devenues le standard des grandes organisations qui se transforment. Elles sont notamment pertinentes pour lancer très rapidement des nouveaux produits dans un environnement complexe. Si cela se traduit par la croissance importante de projets effectués 100% avec des méthodes agiles, l’étape suivante est plus compliquée. Transformer l’essai d’un projet agile en organisation agile est lent et laborieux. Je partage avec vous le fruit de mes réflexions et mes retours d’expérience en tant que, CEO de FABERNOVEL CODE.

Les grands groupes sont en pleine transformation. Pour aller vite et impacter, certains choisissent de s’inspirer des GAFAs et des start-up, et comme eux, de s’organiser en squads, ces petites équipes de production de valeur, autonomes et pluridisciplinaires. D’après une étude Neoma et Goetzpartners (2017), près de la moitié des entreprises en Europe a déjà lancé un nombre significatif de projets en utilisant les méthodes agiles.

Cela peut sembler évident tant les exemples sont nombreux et la littérature abondante, mais ça l’était moins il y a encore 3 ans quand nous avons fait le choix de faire pivoter FABERNOVEL CODE d’un modèle d’agence Web classique à un modèle de “digital factory” fonctionnant exclusivement en mode agile avec nos clients. Inspirés par Spotify et nos collègues de FABERNOVEL TECHNOLOGIES et FABERNOVEL DATA&MEDIA, il faut bien l’avouer, nous nous sommes nous aussi réorganisés en squads.

 

Etape 1 : Le premier succès agile

Notre constat après ces trois années, est que réussir à mener, un projet en “Scrum”¹, est en soi un vrai premier succès pour un Corporate. Alors bravo à vous, chers clients. Sincèrement.

Car les enjeux sont très nombreux. Il y a d’abord le choc culturel (et non, venir en New Balance au bureau ne fait pas de vous un startupeur accompli), il y a aussi le rapport à l’échec (lire l’excellent “Vertues de l’échec” de Charles Pépin), il y a encore la capacité à faire travailler une équipe sans cahier des charges et sans engagement forfaitaire, il y a enfin la capacité à prendre des décisions très rapidement, quitte parfois à froisser quelques personnes de l’organigramme.

Forts de trois ans de projets en mode 100% agile, nous pouvons partager avec vous quelques bonnes recettes. Pour votre premier succès agile, nous vous recommandons de recruter les volontaires les plus motivés de votre organisation, d’isoler cette équipe, de la mettre dans une “bulle”, si possible loin du siège social, et de les colocaliser avec une équipe d’excellents artisans provenant de l’extérieur pour qu’ils apportent leur fraîcheur et leur “naïveté”. Pour plus d’éléments sur le sujet vous pouvez relire mon article sur l’unicité de lieu.

Tout ça le temps que cette première équipe coeur se crée, de vrais réflexes prennent, de vrais impacts business se produisent.

Une fois que cette petite équipe agile a lancé avec succès son Minimum Viable Product et qu’elle sent qu’elle est en bonne voie pour trouver son Product Market Fit, l’accord parfait entre son produit et le marché, elle se confronte à la nécessité de “passer à l’échelle”.

 

Etape 2 : Le passage à l’échelle

Ce passage à l’échelle est nécessaire pour plusieurs raisons : après le premier succès, le périmètre fonctionnel confié à l’équipe augmente, on souhaite embarquer des développeurs de la DSI dans l’aventure et on souhaite utiliser les briques technologiques développées pour d’autres expériences utilisateurs. Bref, alors que c’était la recommandation du début, à ce stade l’équipe agile ne peut plus agir isolément dans son coin. Elle doit sortir de sa bulle.

 

Alors comment passer une équipe produit de 5 à 50 personnes tout en restant agiles ?

Chez FABERNOVEL CODE, nous faisons beaucoup de veille. Nous nous inspirons de ce que font les autres. En matière de passage à l’échelle, notre conviction est que c’est un peu comme creuser un tunnel : deux parties doivent faire leur bout de chemin. Les équipes produits doivent passer à l’échelle en augmentant la taille des équipes produits en remontant l’organigramme de bas en haut. Je vous propose d’appeler ce mouvement le “Scale Up”. En même temps, le management doit créer un cadre favorable à l’agilité à l’échelle, de haut en bas. Je vous propose d’appeler ce mouvement la “Strategic Agility”.

Commençons par le “Scale Up”. Quel est l’équivalent de la méthode agile “Scrum” (qui est adaptée aux équipes de 3 à 9 personnes, mais pas plus) pour s’organiser à 50 personnes ? Il existe déjà des méthodologies, et comme souvent dans le domaine des méthodologies, il y en a beaucoup. Toutes présentent des avantages et des inconvénients, toutes ont leurs gourous et leurs fans prêts à tout pour faire gagner leur championne, toutes ont leur système de certification, toutes ont des consultants ultra certifiés prêts à la déployer chez vous. Et comme toujours avec les méthodologies, tout est fait pour que vous, chers clients, n’y compreniez rien, et finissiez par lire un article tel que celui de votre serviteur, au gré de vos recherches sur google.

Nous avons lu (beaucoup, trop ?) de la littérature méthodologique, nous avons rencontré des experts, nous avons écouté nos clients. Notre conclusion est la suivante – et nous la remettrons en cause autant de fois que le marché nous dira de le faire pour créer de la valeur pour nos clients. Une partie de nos clients – aidée par leur cabinet de conseil IT favori – nous demande de les aider à passer à l’échelle avec la méthode “SAFe”, un cadre de travail très imposant, qui a le mérite de détailler précisément ce que vous devez faire et l’inconvénient de ne pas vous laisser une grand marge de manoeuvre.

De notre côté nous nous sommes intéressés au “Scrum@Scale” pour la simple raison qu’il est édité par l’un des deux fondateurs de la méthode “Scrum” que l’on utilise, et que l’on a vraiment apprécié la construction du Scrum Guide, qui dit tout ce qu’il faut savoir en moins de 16 pages. Nous nous sommes formés et nous sommes certifiés car nous pensons qu’il est de notre devoir de savoir de quoi on parle avant de l’utiliser avec vous, chers clients. Mais non, nous n’irons pas en guerre pour défendre le “Scrum@Scale”, car mourir pour une méthodo, d’accord, mais de mort lente.

 

Les équipes produits ont besoin d’un terreau organisationnel fertile à l’agilité

Mais pour que les équipes produits s’agrandissent tout en restant agiles, il faut leur créer un cadre propice à leur expansion. Plus les équipes sont élargies, plus certaines contraintes vont émerger, liées à l’organisation historique du groupe. Les product owners de vos différentes squads ont-ils vraiment les mêmes objectifs ? Dépendent-ils du même service ? Quel est la capacité réelle d’une équipe à se motiver sur des objectifs qu’on lui aura imposé et qu’elle sait être inadaptés voire irréalisables ? Comment souvent, lorsque de la complexité émerge, l’enjeu pour l’organisation est de “ré-aligner”.

Oui, chers managers, vous aussi avez votre rôle à jouer dans le passage à l’échelle. Vous disposez de modèles organisationnels pour favoriser le passage à l’échelle. Nous sommes très inspirés par les organisations qui ont réussi à libérer le leadership, à fournir le fameux triptyque de l’auteur Dan Pink : vision, autonomie et maîtrise (clique ici pour voir une vidéo et tout comprendre). Ce triptyque est très simple à comprendre, et extrêmement difficile à mettre en place “pour de vrai”.

Quelques GAFAs ont réussi à le mettre en place, je pense notamment à Spotify qui, en 2012, a mis en ligne deux vidéos (à voir ici et ici) sur un mode “draw my organization”, qui vous décrit comment ils arrivent à rester agile malgré leur très forte croissance. Leur système organisationnel repose sur des squads, ces petites équipes agiles autonomes et pluridisciplinaires.

Apparemment rien de nouveau, me direz-vous. Et pourtant, c’est une véritable révolution. Et pour cause : que deviennent les trois millions² de “managers” dans ces modèles de Minimum Viable Bureaucracy ? Le landerneau du conseil en organisation est en ébullition. Nous y reviendrons dans un post ultérieur.

Avant de reposer ma plume, je voudrais vous parler d’un bon dernier concept qui nous semble très intéressant pour passer à l’échelle de haut en bas. Il s’agit des OKR (Objectives & Key Results) une méthode qui permet de décliner ses objectifs moyen terme en objectifs plus court terme, délégués dans l’organisation.. En effet passer à l’échelle, c’est aussi être capable d’aligner les efforts à court terme avec ses objectifs à moyen terme. Je vous invite à écouter ce podcast de Jean-Charles Samuelian, le fondateur du fameux Alan, la start-up qui s’attaque au marché de l’assurance santé (certains attaquent les pics par la face Nord, right ?), que j’ai trouvé très inspirant en la matière.

Ce post ouvre un cycle de prises de parole sur l’agilité à l’échelle, qui se compose d’une série d’articles, et quelques petits déjeuners thématiques dont nous communiquerons les dates sur nos réseaux sociaux (cliquez ici pour nous suivre sur twitter, ici sur linkedin).

 

A bientôt !

Alexis

 

¹La méthode agile la plus répandue, et certains diront que ce n’est pas une méthode mais un framework, et ils auront raison, mais ce n’est ni l’endroit ni le moment d’en débattre …

² Selon une étude opinion way

Ces sujets vous intéressent ?

Contactez-nous
logo business unit

FABERNOVEL CODE

Nous réalisons des plateformes Internet en un temps record, en mêlant talents et méthodologies agiles.

à lire