Agile : agir sur l’organisation et la culture ?

Agile : agir sur l’organisation et la culture ?

Est-ce que « la méthode agile » recèle des fragilités qui freinent le passage de la théorie à la pratique ? Et si les freins étaient aussi, voire plutôt organisationnels et culturels ? L’analyse critique proposée par Gil Develey dans son article illustre un point de vue, des inquiétudes et quelques incompréhensions qui sont parfaitement légitimes.  Les pratiques agiles peinent encore à s’imposer à grande échelle. Agir sur l’organisation et la culture est essentiel pour réussir une transformation agile. Au même moment paraissait « Friction », un article passionnant de Mary Poppendieck qui justement éclaire cette question de la difficulté qu’ont les opérateurs historiques publics et privés à intégrer dans leur organisation, dans leur culture, les pratiques qui permettent aux projets informatiques de réussir et de répondre aux attentes des clients et utilisateurs.

Agile-balance

« Les règles de la méthode agile »

M. Develey cite les cinq règles suivantes :

  • décomposer le domaine en activités appréhendables de bout en bout
  • donner la responsabilité d’une activité à une équipe
  • chaque équipe dispose de l’autorité nécessaire pour définir le fonctionnement futur
  • chaque équipe est autonome en termes de capacité de décision, et de compétence technique
  • le client est impliqué au plus près des activités informatiques tout au long du cycle (depuis le design en passant par les tests, jusqu’à l’acceptation finale).

Ces règles correspondent effectivement à des pratiques que l’on retrouve dans les projets agile et sont plutôt représentatives des valeurs et principes de l’agilité. Mais commençons par le commencement : « agile » est plutôt un mouvement qu’une méthode. Prenant ses racines dans dans certaines pratiques de l’industrie (Toyota en particulier), l’agilité apparaît dans l’informatique dans les années 1990 et est basée depuis 2001 sur le manifeste agile. La finalité de l’agilité dans l’IT est de mieux développer des logiciels. Ce manifeste ne décrit pas une méthode, il pose simplement quatre valeurs et douze principes. Les valeurs sont reprises ci-dessous  (texte complet du manifeste agile) :

  • privilégier les individus et les interactions plutôt que les processus et les outils,
  • privilégier la collaboration avec le client plutôt que la négociation d’un contrat,
  • privilégier la réponse au changement plutôt que le suivi d’un plan,

Le fait qu’il ne s’agisse pas d’une méthode est important : les valeurs et principes de l’agilité peuvent en effet s’appliquer à bien d’autres sujets qu’au développement logiciel.

A la suite du manifeste agile, diverses pratiques sont apparues ou ont évolué, qui intègrent les valeurs et principes agiles. Et là on peut parler de méthodes, Scrum par exemple, qui ont en commun un cycle de développement itératif, incrémental et adaptatif.

Méthode Scrum, une introduction très concrète en Anglais (Merci à Michael James)

L’article de G. Develey est donc plutôt juste quand il reprend notions d’autonomie et d’implication du client, ainsi que l’accueil bienveillant du changement, que l’on retrouve dans le manifeste. De même pour la décomposition d’activités appréhendables de bout en bout, qui vient probablement d’une expérience de « feature team » souvent proposé et en même temps débattu par les agilistes . La « notion de clarification » quant à elle, évoque par exemple les pratiques de raffinement de backlog que l’on retrouve en complément de Scrum.  Mais en quoi est-ce ces pratiques, qui sont nées de la volonté de faire mieux, conduiraient en elles-mêmes les projets à l’échec ? L’auteur indique « les demandes de changement, les modifications, font l’objet d’une gestion particulière et sont ou pas intégrés dans les développements ultérieurs ». Accueillir le changement est un des principes de l’agilité justement parce que les approches précédentes échouaient en voulant figer le besoin avant de lancer la réalisation. D’ailleurs, même avec une approche de type « cycle en V » les changements doivent être gérés. Donc s’il y a problème à un moment avec la balance du changement, la cause doit probablement être recherchée ailleurs dans le projet ou son environnement. La fièvre est là, mais ne cassons pas le thermomètre pour autant.

« Fragilité de la méthode » ?

Selon M. Develey, la fragilité de l’agilité résiderait dans trois conditions, que l’on suppose implicitement impossibles à réunir puisqu’elles constituent une fragilité selon l’auteur.
Premièrement « trouver un représentant qui ait à la fois autorité et connaissance métier ». Diantre. Est-ce que cela n’est pas autant nécessaire sur un projet non-agile ? A un moment, il faut bien par exemple valider des spécifications, donc prendre une décision en connaissance de cause sous l’angle métier.
Ensuite « réunir une équipe de développeurs qui maîtrisent leurs outils (…) trouver un bon interprète ». Saperlipopette ! Mais comment faire un projet réussi sans une équipe compétente et sans passeurs efficaces entre le métier et la technique[1] ?
Enfin, « disposer de testeurs expérimentés » et « intégrer très en amont les problématiques d’exploitation ».  L’article évoque également comme des difficultés le travail collaboratif et le debriefing quotidien. N’est-ce pas également surprenant ?
Il semblerait que la conclusion « fragilité de la méthode » masque en fait des problèmes propres à l’organisation. En tout état de cause, il est difficile d’incriminer des bonnes pratiques qui ont prouvé leur efficacité dans bien des contextes.

Agile, l’affaire des directeurs de la transformation ?

L’article débute en fait par une déclaration qui peut éclairer un peu les choses :

« Depuis une bonne dizaine d’années, plusieurs Directeurs de Transformation (mènent leurs projets en mode agile) ».

Nous y voilà, non ? Pourquoi diable le fait mettre en œuvre des pratiques destinées à améliorer l’efficacité des projets informatiques serait-il l’apanage plutôt des directeurs de la transformation ? Est-ce parce que ces méthode sont nouvelles ? Non, elles ont plus de vingt ans.
Les directeurs de la transformation sont chargés dans ce cas de réussir la transition numérique d’un business. Et ils le font en réinventant complètement l’expérience client, parce que c’est ce que font justement les nouveaux venus, qui innovent radicalement dans la manière d’aborder le client et son parcours. Et parce que ces nouveaux venus concurrencent directement les opérateurs historiques.
Il se trouve que souvent, les équipes qui réussissent cette transition numérique contournent les organisations en place pour regroupent dans la même équipe la palette complète des compétences nécessaires. Réunir une équipe qui maîtrise la réalisation, de bout en bout, nous retrouvons le propos de M. Develey. C’est ce que Mary Poppendieck appelle dans son article les « full stack capabilities » :

« Les grandes entreprises ont les mêmes ensembles complets de compétences que les startups, mais ces comptétences appartiennenet à des services différents et il existe des frictions aux frontières de chaque service. Plus encore, les opérateurs historiques sont profondément impliqués dans les modes de fonctionnement actuels, donc les grands opérateurs historiques sont généralement incapables de vraiment réinventer le parcours client. Malgré tous leurs efforts pour se montrer innovants, (ils) ont tendance à ne pas voir les frictions embarquées dans le parcours client qu’ils fournissent actuellement. »[2]

On voit donc de plus en plus coexister deux types d’organisation. La structure « historique » conserve ses processus, ses règles, sa structure très hiérarchisée et cloisonnée, et on confie à des sortes de startups internes le soin de réussir à repenser l’expérience client via le digital. C’est ainsi que naissent les directions de la transformation, les laboratoires d’innovation digitale ou autres pôles digitaux. La DSI elle même est contrainte de répartir ses ressources entre les projets « classiques » et les projets « digitaux », souvent pilotés en direct par la communication, le marketing voire la direction générale.

Cette situation conduit à un système d’information bimodal (Bimodal IT). Une informatique à deux vitesses en quelque sorte. C’est probablement la marque d’une transition profonde. Nécessaire et parfois douloureuse, cette transition remet en question l’organisation et la culture des entreprises. Elle bouscule également les rôles et les responsabilités, certains managers étant appelés à devenir plus des servant leaders que des figures d’autorité. Les inquiétudes exprimées par Gil Develey sont donc légitimes. Mais l’agilité, qui les met en lumière, n’en est pas la cause. Plus que jamais, il est important d’échanger sur nos points de vue pour réduire les inquiétudes. Il faut dialoguer pour rapprocher les « classiques » et les « digitaux », les « agilistes » et les sceptiques, les équipes agiles et les managers ou cadres dirigeants. Cet article y aura-t-il contribué ? C’est en tout cas l’intention de ce billet.

[1] Rôle dévolu au Product Owner dans la méthode Scrum.

[2]« Large companies have the same full stack of capabilities as startups, but these capabilities lie in different departments and there is friction at every department boundary. Moreover, incumbents are deeply invested in the way things work today, so large incumbent companies are usually incapable of truly reinventing a customer journey. As hard as they try to be innovative, incumbents tend to be blind to the friction embedded in the customer journey that they provide today. »M. Poppendieck : réduire les frictions pour réinventer le parcours client.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *