"The Death of Agile" : les démarches agiles sont-elles en danger ?

12 Oct 2015

Pour Allen Holub, un consultant indépendant de la sillicon valley, les pratiques agiles ne peuvent pas survivre dans les grandes entreprises. Elles sont condamnées à mourrir si on ne change pas des choses importantes dans la culture et l’organisation de celles-ci. Cet article reprend ses arguments. Ils ont été exposés aux conférences Software Architect London en 2014 [1].

#Le fond du problème : le culte du cargo

Le culte du cargo a été observé dans une île isolée de l’océan pacific, durant la Seconde Guerre mondiale. Les habitants de cette île, qui étaient restés à l’âge de pierre, virent arriver des avions pour se servir de leur île comme une base militaire. Ils furent alors en contact avec le 20ème siècle. Eux qui devaient chasser et pêcher pour se nourrir, voyaient arriver des avions-cargo qui ravitaillaient l’île suite aux appels lancés par les opérateurs radio depuis leur tour de contrôle.

À la fin de la guerre, la base fut abandonnée et les habitants de l’île se sont mis à imiter ce qu’il avait vu. Ils construisirent une tour de contrôle en bois, des casques d’opérateur radio en noix de coco et des avions en osier en espérant que les cargos arrivent à nouveau. Ce qui n’arriva jamais évidemment, car ils ignoraient comment tout cela fonctionnait vraiment.

Le plus gros culte du cargo, en fait, se trouve dans la “corporation moderne”. Elle considère qu’il n’y a qu’une seule façon de faire les choses. Elle ne peut pas concevoir que l’on puisse les faire autrement.

Par exemple, quand vous participez à des groupes sur Linkedin, vous y trouvez constamment un flot de mauvaises questions comme : “quel est le rôle du chef de projet dans une organisation agile ?”. La réponse est : “il n’y a pas de chef de projet dans une organisation agile”. Mais notre “civilisation” est persuadée que le chef de projet est un élément nécessaire du travail. Elle ne peut pas imaginer un monde où le chef de projet n’existe pas.

Il est donc très difficile de faire rentrer l’agilité dans les organisations actuelles. Comme dans le culte du cargo elles font des choses sans les comprendre. en fait, elles cherchent un processus très spécifique qu’elles peuvent suivre. Elles pensent qu’il faut former les gens à ce processus (scrum par exemple) et que cela donnera le résultat attendu. Une agilité packagée qui comme par magie va changer les choses. Mais cela ne fonctionne pas.

Cela ne signifie pas que les processus n’ont pas leur place dans l’agilité, il en existe beaucoup qui sont utiles. Mais comme le dit la manifeste agile, ils sont beaucoup moins importants que les individus et leurs interactions. En d’autres termes l’agilité doit s’appliquer aux processus comme au reste.

#Le culte de la certification scrum est destructeur

Beaucoup de gens pensent que Scrum et Agilité c’est la même chose, mais en fait Scrum est un processus. En disant je fais du scrum on dit que le processus est plus important que les gens qui réalisent ce processus. Cela ne peut pas fonctionner.

Ce qu’on constate souvent dans les entreprises qui ont voulu adopter l’agilité, c’est le désastre qu’ont laissé derrière eux les scrum masters certifiés (n.b. il n’y a pas ici d’attaque vers une partie de la communauté, mais vers un business qui s’est mis en place).

Pour Allen Holub, scrum est aujourd’hui le problème, pas la solution.

Le problème des certifications c’est qu’il n’a aucune valeur. pour Scrum, vous lisez 16 pages en une après-midi. Vous répondez à un questionnaire à choix multiples devant un ordinateur et si vous obtenez 60% de bonnes réponses vous devenez un maître scrum !

Le problème c’est que les entreprises pensent que c’est une sorte de diplôme, que ce certificat a un sens. Malheureusement, en faisant ça vous avez quelque chose d’activement destructeur. Parce que si vous imaginez que la personne qui a son certificat est un expert. Mais si les choses ne vont pas, vous n’allez pas blâmer la personne mais vous allez blâmer ce qu’il est supposé vous apporter. Vous concluez que l’agile ne fonctionne pas, vous ne dites pas que c’est le scrum master certifié qui ne sait pas de quoi il parle.

En réalité, ça ne marche pas car on fait croire que scrum peut fonctionner là où il n’y a pas de changement d’organisation. Il est d’ailleurs commun qu’un an après avoir été accompagnées pour faire du scrum, la plupart des équipes ne fassent plus de scrum du tout parce qu’ils ne sont pas dans un environnement pour le faire fonctionner.

#Pourquoi les grandes entreprises ne sont pas (ou ne seront jamais) agiles ?

Pour vérifier si on parle bien d’agilité, on peut le remplacer par le terme “flexibilité”. Si vous dites “je fais les choses de façon agile”, tout va bien, mais si vous dites “l’agilité me dit de faire les choses de cette façon”, ça convient pas du tout. Ce que nous voulons c’est de la flexibilité. Nous voulons nous adapter rapidement à des besoins qui changent.

Malheureusement les grandes entreprises actuelles sont incapables de le faire et n’en seront certainement jamais capables car c’est dans leur nature de pas être flexible. Cette non-flexibilité y est “encastrée”.

Par exemple, si une grande entreprise décide de transformer une application standard en application pour mobile, en combien de temps sera-t-elle dans les mains de l’utilisateur ? Plusieurs semaines ou plusieurs mois ?

Regardons ce que cela impliquerait: de la formation, des nouvelles personnes dans l’équipe pour aider, etc. Si l’objectif est de livrer l’application en quelques semaines et qu’il faut plusieurs mois pour faire valider les formations (ce qui est courant dans les grandes organisations), vous n’êtes pas agiles.

Pour avoir un contrôle sur les dépenses (de formation par exemple) l’entreprise a décidé de créer un processus qui rend impossible à l’organisation d’être agile. Nous avons ici une friction et l’agilité c’est justement l’élimination de ces frictions. Si vous travaillez dans une entreprise qui ne permet pas d’éliminer les frictions votre chance d’être agile est nulle.

Autre point important, la grande entreprise pense que l’agilité se produit au sein de l’ingénierie, et tout ce que vous avez à faire, c’est de former vos ingénieurs à scrum et vous avait fini. Mais en fait être agile est quelque chose d’organisationnel. Il n’y a pas de silo (des regroupements d’experts) dans une organisation agile. Ce qui est agile c’est l’organisation par les équipes, les départements ou les gens mais l’organisation dans son ensemble.

Parce que si j’ai besoin d’une formation, j’ai besoin d’une formation maintenant. S’il y a un département des finances séparé qui met des “frictions” pour que j’obtienne ma formation il n’y a aucune chance qu’il y ait de l’agilité dans cette organisation.

#Que faut-il changer dans les entreprises ?

Votre organisation est structurée pour supporter les processus existants, donc si vous changez vos processus vous devez changer votre organisation. Si par exemple votre organisation est construite pour supporter un processus en cascade (cycle en V, waterfall) vous ne pouvez pas tout à coup être agile sans la modifier. Ceci parce qu’une organisation pour faire du waterfall ne fonctionnera pas pour supporter des cycles courts.

Il y a un certain nombre de choses que l’on pense ne pas devoir changer, mais qu’il faut changer néanmoins. En voici quelques exemples :

• Le département qualification (QA departement) par exemple, qui est une des raisons pour laquelle il est si difficile de rendre une organisation agile. Dans tous les processus agiles qui fonctionnent, le test est très fortement intégré dans le processus de développement (cf comment google test ses logiciels). Toutes les 20 minutes pour les tests globaux, toutes les 2, 3 minutes pour les tests unitaires. À la fin d’un cycle le code est complètement testé et prêt à être déployé. Ça signifie qu’il n’y a rien à faire pour un département qualification. Votre responsable du département Q.A. ne sera pas très content de ça et il se battra de toutes ses forces pour que l’agilité n’arrive pas dans son organisation parce qu’il va perdre son travail. Maintenant si c’est une véritable organisation agile, il ne perdra pas son travail. Il changera de travail pour faire de la véritable qualification en regardant les processus et en essayant d’apporter des conseils pour les améliorer.

• Les pratiques de gouvernance, comme celles utilisées par le département financier dont nous avons parlé plus haut sont aussi à supprimer. Si j’ai besoin d’une formation, j’en ai besoin maintenant pas dans six semaines, si j’ai besoin d’un nouveau logiciel j’en ai besoin maintenant pas dans 2 mois. Les équipes agiles ont un budget qu’elles dépensent comme bon leur semble. Si l’ensemble de l’équipe a décidé d’aller dans une conférence, elle le fait, elle ne demande à personne. Si elle doit acheter un nouveau logiciel elle le fait. Bien sûr elle doit gérer son budget, il n’est pas infini mais ce c’est l’équipe qui fait le choix, pas un département extérieur dans la société.

• Les dates butoirs (deadlines) et les plannings basés sur le temps n’existent pas dans le monde de l’agilité. Tout est planifié sur les priorités. Comme rien n’est basé sur le temps, il n’y a donc pas de feuille excel et autres tableurs à remplir. Car tout ce que vous faites, qui ne met pas directement de la valeur dans le logiciel des utilisateurs, c’est du gaspillage.

• La gestion de projets. Il n’y a pas de gestion de projets en agilité. Vous faites confiance aux gens pour qu’ils fassent leur travail et qu’ils se gèrent eux-même. En fait, il n’y a pas du tout de “middle management” dans le monde agile.

Il faut donc supprimer ces choses. Mais les grandes entreprises ne le feront pas. Elles pensent que, pour fonctionner elles doivent continuer à le faire et que si elles ne le font plus elles ne fonctionneront plus. Ce qui est un non-sens car il existe de grandes entreprises qui fonctionnent parfaitement de façon agile (i.e. sans ce que l’on a listé au-dessus). Mais la plupart des entreprises ont des managers et s’attendent à ce qu’ils travaillent comme des managers. Elles pensent qu’en changeant leur titre (le chef de projet devient scrum master par exemple) tout va bien se passer.

Spotify est un bon exemple. Elle a aujourd’hui 500 développeurs, ce qui permet de dire qu’une grande entreprise peut être agile. Il n’y a aucun projet sur la planète qui nécessite une équipe de 500 développeurs. Le projet est donc découpé en plusieurs petits projets. La particularité chez Spotify, c’est qu’il n’y a pas de hiérarchie, il n’y a pas de pyramide avec des managers et des contrôles. C’est en fait une matrice, qui n’est pas une organisation matricielle classique. Il n’y a pas de chef. Les petits groupes ont juste une personne, un architecte système, qui est membre de chaque équipe et qui s’assure qu’il y a une certaine cohérence dans le système qui se construit. Mais il ne commande personne. Il fait juste remarquer à l’équipe A que l’équipe B fait de manière différente et que c’est peut-être une meilleure de façon de faire. L’équipe A peut alors changer sa manière de faire car ils sont flexibles. C’est un processus très collaboratif.

#Pour trouver une issue, revenons aux fondements de l’agilité

L’agilité est à la base quelque chose de vraiment très simple.

Premièrement c’est une culture définie comme les attitudes et les comportements d’un groupe social particulier. Et la culture est la chose la plus importante, pas le processus. Encore une fois, ceci ne signifie pas que les processus ne sont pas importants, mais un processus spécifique n’est pas plus important qu’un autre processus spécifique dans la culture agile. Pour être agile vous devez mettre en place la bonne culture. Ce qui veut dire que cela doit venir du haut. C’est le le travail du CEO (Chief Excutive Officer - Directeur Général) de gérer la culture de l’organisation. Donc si le CEO ne comprend pas ce qu’est l’agilité, il n’y a aucune raison qu’il mette en place une culture qui supporte l’agilité.

Le deuxième élément c’est la confiance. Tout dans l’agilité repose sur la confiance que l’on a envers les gens pour qu’ils fassent correctement leur travail. Pas besoin de leur demander de remplir des formulaires pour les autoriser à aller dans une conférence, car on leur fait confiance. Ils connaissent leurs capacités et ils savent que la conférence va les augmenter. On les laisse donc y aller.

Le troisième c’est le lien entre les valeurs, les principes et les pratiques. Les pratiques existent car les principes existent. Les valeurs existent car les principes existent. Si les principes et les valeurs ne sont pas en place, alors les pratiques ne seront pas fonctionnelles. Par exemple, lorsque l’on pratique le refactoring (remaniement du code) et que les principes comme accepter le changement et la valeur du courage (et il en faut pour modifier du code qui marche) sont ignorés alors ça ne peut pas fonctionner.

Enfin, le processus de base, commun à tous les autres, est très simple. Vous interroger votre client et essayez de comprendre ce qu’il veut. Vous faites des petits morceaux que vous construisez et que vous leur montrez au fur et à mesure. C’est tout ! Tout le reste c’est du glaçage.

En conclusion, si l’agilité est de loin la façon la plus efficace de construire du logiciel, les entreprises qui font les choses de manière agile, auront un avantage compétitif énorme comparé aux autres. Les entreprises qui ne travaillent pas de façon agile vont cesser d’exister. Toutefois, la plupart des entreprises n’ont pas cet objectif de disparaitre dans les 5 à 10 ans parceque leurs concurrents bougent plus vite. Donc si vous voulez survivre, faites les changements nécessaires pour faire survivre l’agilité.