Quand l’Agile peine à s’imposer…

Cet article est une synthèse d’un échange sur une mailing-list interne Octo, qu’il nous a paru intéressant de partager. Merci à Jonathan Scher, Ludovic Cinquin, Yannick Martel, William Montaz et les autres pour leurs contributions. Bonne lecture !


Un de nos consultants est embarqué chez l’un de nos clients, dans un projet de dev d’une application web innovante, à interface très riche. Ce projet est conduit par le client suivant une bonne vieille méthode en cascade…

 

Il se trouve dans l’équipe en charge du développement du « front ». Le reste du projet (web-services et stockage) est réalisé par une autre équipe.

Et il et se désole tous les jours des freins qu’il rencontre à la production d’une application de qualité : IDE imposé et obsolète, système de gestion de versions inutilisable, batailles sans fin avec l’équipe d’architecture transverse qui impose des technologies obsolètes et incompatibles avec l’ambition du projet.

Les specs sont relativement contraignantes et conduisent au développement d’une appli assez pauvre sur le plan architectural (domaine anémique, code passe-plat…)

Au-delà de ces aspects techniques, le projet souffre également des défauts de la cascade : les écrans sont produits par une web-agency depuis longtemps, et l’intégrateur web à déjà créé 2 mois de stock en amont des développeurs, quand notre consultant se rend compte que le HTML produit sera inutilisable en l’état. Il faut reprendre HTML et CSS, ce qui donne des sueurs froides au chef de projet (planning), et à l’intégrateur web (qui n’a pas très envie de revenir sur 2 mois de travail).

Stocks, défauts qui s’entassent dans la chaîne de production … c’est-à-dire des freins à une production efficiente (cf Lean ou encore la théorie des contraintes de Goldratt)

Autant de raisons qui poussent notre consultant à argumenter en faveur de l’Agile auprès de notre client… mais il se voit opposer un certain nombre de contre-arguments.

 

Le design émergent voué à l’échec ?

L’agile ne serait que le développement de petites fonctionnalités les unes derrière les autres, sans penser au lendemain, et où l’on passe un temps très coûteux à refactorer. Notre client, lui, préfère penser au logiciel dans son ensemble tout de suite, prenant en compte immédiatement les besoins fonctionnels et non-fonctionnels pour définir dès le début l’architecture cible.

Pour Jonathan :

On est dans le pari classique du « Big Design Up Front » vs « architecture émergente ».

Lorsque je fais du BDUF, je fais le pari suivant :  »Je passe du temps à concevoir quelque chose de générique et de réutilisable ».

Dans la pratique, on se rend compte que dans 80% des cas, la généricité n’est pas utilisée. Et elle ajoute une couche de complexité.

D’autant que dans le Big Design Up-Front, il faut penser à tout, tout de suite. Hors, nos projets sont de plus en plus complexes : appréhender le système dans sa globalité (infra, intégration, stockage, performance, sécurité, ergonomie…) est mission impossible. Surtout dans un contexte d’innovation.

Jonathan :

Lorsque je fais du design émergent, je fais le pari suivant : « Je fais du spécifique. Je passerai ensuite du temps à réutiliser mon code. Mais je passerai moins de temps à le faire que ce que j’aurais perdu à rendre TOUT réutilisable ».

La facture se paye, mais d’un côté on la paye tout au début, par une grande analyse, et de l’autre côté on la paye en refactoring. Et le refactoring, nous faisons tout pour qu’il soit le moins cher possible, notamment grâce au harnais de tests.

Enfin, quelque chose que je recommande sur tous mes projets : prendre en compte très tôt dans le projet les besoins non fonctionnels. Il faut 10’000 utilisateurs en même temps ? Je mets en place un test le prouvant dès le début, et je surveille tout au long du développement.

Mais comme le souligne William :

Le client a généralement du mal à accepter de passer du temps (ie. dépenser de l’argent) sur une révision de l’archi en cours de projet. Il perçoit ça comme une trahison, un mensonge sur la vitesse de livraison. Mais en fait l’agile ne promet pas d’aller plus vite.

L’une des promesses de l’Agile, c’est qu’au contraire, on PEUT se permettre une révision de l’archi. Introduire un ORM dans une couche d’accès aux données, découper un modèle de données en sous-parties et les déplacer dans l’infrastructure, changer de framework d’IHM … tout ça sont des chantiers qui bousculent le socle d’une appli et qui sont certes difficiles, mais néanmoins faisables. Surtout si on a mis en place un harnais de tests suffisamment complet.

Ce genre de chantier est carrément irréaliste en cascade, car on s’en aperçoit souvent trop tard, et il serait trop risqué et/ou coûteux de changer son fusil d’épaule.

En fait, faire du « design émergent » ne signifie pas qu’on arrête de travailler sur l’archi, bien au contraire ! Ca permet même aux architectes de se concentrer sur des problématiques moyen-terme (au travers de dossiers d’archi, de POC, de tests…), en faisant confiance aux développeurs pour prendre un certain nombre de décisions plus court-terme par eux-mêmes.

 

L’agile inadapté au « monde réel » ?

Mais au-delà de cela, pour ce client, l’agile est une belle utopie qui ne résiste pas au « monde réel » : celui de la contractualisation. Un budget doit être évalué en amont, le projet doit aboutir à la date convenue, le livrable doit être conforme au cahier des charges (obligation de résultat), et le tout doit respecter le « droit » en vigueur (contractualisation interne ou avec le fournisseur).

Jonathan :

Effectivement, le modèle même du forfait est la cause de beaucoup de problèmes. Faire un forfait « dans le monde réel », c’est :

- Réfléchir à ce dont j’aurai besoin dans un an

- Rechercher un prestataire capable de s’engager à y répondre.

Et ça ne marche pas.

Si tu pars de l’idée que tu ne sais JAMAIS ce que tu veux un an à l’avance, ce qui est vrai pour tous les projets « innovants », l’agile devient une solution. On va construire ensemble ce que vous utiliserez dans deux mois, puis on améliorera. Et, oui, c’est très difficile à contractualiser.

C’est le modèle même, qui diffère :

D’un côté, la vision prônée par l’Agile : L’informatique doit être un centre de gains, non de coûts. Pour cela, il faut répondre au plus vite et au plus près des besoins utilisateur.

En face, il y a le « vrai » monde. Celui qui contractualise, qui ne prend pas de risque, qui a plus à coeur de respecter un droit informatique que d’évoluer.

Et, oui, introduire un modèle d’innovation, c’est prendre un risque.

Et, comme le rappelle William, passer d’un modèle au forfait à un autre modèle beaucoup plus impliquant pour le client, car beaucoup plus collaboratif, ne se fait pas sans peine :

Dur à vivre pour le client en fait, habitué à être serein tout le long du projet et à serrer la vis sur la fin…

Habitué à serrer la vis sur la fin, ou encore qui trouve normal de passer des nuits blanches à intégrer les projets en provenance de plusieurs équipes et qui ne s’intègrent pas comme prévu dans la spec !

 

Alors, comment introduire le changement ?

Comment convaincre ce chef de projet ? Comment lui-même peut-il convaincre sa hiérarchie d’aller vers l’Agile ?

Pour Ludo,

On est dans les contre-arguments classiques de l’agile. Et on est modèle contre modèle, ce qui ne mènera pas bien loin.

Il a visiblement sa conception du monde et aucune douleur qui ne justifie qu’il la change.

Il a donc raison… :)

Yannick :

La douleur est encore le meilleur facteur pour pousser quelqu’un au changement, mais il faut encore que celui-ci reconnaisse qu’il puisse être aidé et te laisse une ouverture, te fasse une demande, bref comme dirait Sinek que son cerveau reptilien soit réceptif…

Et en général sa demande va être pour l’aider à lever la douleur, et pas se voir proposer un modèle (plus ou moins controversé et à la mode : SOA, Agile, programmation objet… on les a tous vu).

Voilà peut-être le coeur du problème : considérer l’Agile comme un modèle à déployer comme ce qu’il-est-écrit-dans-le-bouquin.

L’entreprise, ou l’organisation, doit penser son propre modèle de production, adapté à son besoin d’innovation, son business, ses collaborateurs.

Et puiser dans la boite à outil de l’Agile (ou d’autres approches : Lean, DevOps…) ce qui est adapté à son contexte.

 

Mots-clés: ,

11 commentaires pour “Quand l’Agile peine à s’imposer…”

  1. Si on réfléchit un peu, on s’aperçoit que l’agilité révèle les plus profonds défauts de l’homme, et cela au cœur du monde professionnel : crainte de la transparence, de la confiance, de l’efficacité du feedback concret, peur bleue de l’auto-organisation etc
    Cette fameuse « recherche de perfection » (tout planifier, figer une architecture préalable etc) citée par Thierry Cros, autrement appelée ici le « vrai monde » (qui est tout sauf vrai en somme) est effectivement le coeur du pb. C’est un mythe auquel les organisations s’accroche en vain.
    Qu’on le veuille ou non, le mouvement agile adresse des choses incroyablement profondes, qui probablement le dépasse lui-même.
    C’est pour moi à la fois une des grands intérêts de la Chose et à la fois peut être le germe de sa propre destruction. Le bons sens a rarement eu sa place en informatique depuis longtemps… Et pour cette raison la bataille n’est toujours pas gagné après 10 ans d’agilité.
    Ce fabuleux mouvement, si louable soit-il, ne pourra rien contre l’aveuglement.
    @+

  2. dans le mille le commentaire de Jonathan ! :

    - »Il faut 10’000 utilisateurs en même temps ? Je mets en place un test le prouvant dès le début, et je surveille tout au long du développement. »

    et aussi « L’informatique doit être un centre de gains, non de coûts. Pour cela, il faut répondre au plus vite et au plus près des besoins utilisateurs. »

    et encore une fois on en revient à la même solution : « L’entreprise, ou l’organisation, doit penser son propre modèle de production, adapté à son besoin d’innovation, son business, ses collaborateurs. ».

    dans le style, jetez un oeil à l’article de sébastien douche : http://douche.name/blog/2011/08/08/l-agile-est-mort/

  3. Un vrai projet agile ca n’est possible qu’avec 100% des gens 100% convaincu que ca marche (une équipe OCTO quoi :) ).

    En réalité beaucoup en parle mais personne ne veut faire l’effort, car meme si ca apporte des satisfactions, c’est quand même un effort important sur plusieurs plans (cf David)
    J’ai arrêté d’en parler … mais j’essais de d’en pousser les principes petit a petit dans mes projets.

  4. Reconnaissons d’abord que l’agile est peu adapté à l’esprit cartésien du management hiérarchique et bureaucratique des entreprises en France …

    L’informatique ne sera jamais un centre de gains, car ce sont les financiers qui décident! Les revenus viennent du business et les couts de l’IT.

    Dans mon entreprise on est passé du modele en V, à l’agile, puis sous la direction d’un nouveau VP, on est revenu au modele en V. On voit très vite alors les avantages de l’agile qu’on perd de vue au cours du temps.

    Passer des semaines à discuter une virgule de Bus. Req. au lieu de développer un proto et de faire évoluer. Se parler par email et document au lieu de se voir chaque jour. Sans parler des impacts sur la gestion des talents.

    La mise en place d’un méthodologie en V est la preuve d’une organisation qui doute de la valeur l’IT (infra et software) et qui souhaite à terme externaliser ce fardeau (pas « core business »).

    L’agile fonctionne quand il est adopté par l’organisation toute entière pas juste par une équipe projet ou un SSII qui développe une app en silo!

    L’agile se développera aussi avec la nouvelle génération d’informaticien, celle d’avant ne peut / ne veut pas y adhérer.

  5. je suis effaré au quotidien par tant de naïveté et d’excès de confiance des managers grandes organisations qui s’accrochent aux modèles traditionnels de gestion de leur informatique. ne pas accepter l’agile, c’est refuser de reconnaître que l’on fait des erreurs et rejeter toute solution pour y remédier.

  6. Effectivement, comme le souligne William, le point essentiel est d’avoir un sponsor du projet convaincu de l’agile et décidé à y aller. Sans ça, on se bat contre une organisation pensée et structurée pour le cycle en V.
    Une fois ce sponsor acquis, il est plus facile d’organiser la montée en compétence en agilité et d’obtenir des équipes 100% agiles comme le voudrait Benoit ;-)
    Mais même avec une équipe rompue à l’agile, les tensions vont apparaître aux interfaces avec les équipes qui ne le sont pas. Car finalement, cette équipe agile au milieu du reste avance, délivre, et devient exigeante vis-à-vis des autres. C’est une mutation de l’ensemble de l’organisation, qu’il faut. Ambitieux !…

  7. @Laurent : effectivement, on rejoint un peu les conclusions de Sébastien Douche. Mais je n’aime pas le titre de son article ;-)
    En fait, il pointe le côté Silver Bullet de la chose http://blog.octo.com/aristote-contre-les-balles-dargent/

  8. Je vais être un peu « violent » mais je constate aujourd’hui que les pires ennemis de l’Agile, sont les architectes. Ils gravent dans le marbre et c’est foutu. Jetez (virtuellement!) les par la fenêtre ! Ensuite revenez à votre meilleur IDE : papier, crayon, tableaux blancs (bon ok un peu d’Eclipse ou d’IDEA).

  9. L’inconvénient de l’agile ne réside pas tant dans l’organisation de celui-ci mais étonnamment dans son argument phare qui est de considérer les feedbacks perpétuels.

    Gérer des feedbacks de façon perpétuels peut fonctionner pour résoudre des bugs, et des choses qui ne fonctionnent pas ou mal. Mais quand il s’agit d’améliorer l’expérience utilisateur (point de vue de l’ergonome), ce n’est pas aux développeurs de gérer ce genre de questions, non seulement car ce ne sont pas leur compétences, mais aussi car l’expérience utilisateur n’est pas quelque chose qu’on pense au fil de l’eau.

    En ergonomie il n’est pas question de « fonctionnalités », il est question d’ »expérience utilisateur ». Et dans toute conception de cet ordre, il est nécessaire de créer une cohérence globale à la création. Chaque problématique s’inscrit dans son ensemble. On retrouvera les mêmes discours du point de vue des graphistes et des intégrateurs.

    Ce n’est pas une question d’habitude ou de façons de penser « archaïques », il s’agit là de méthodes qui ne répondent pas à des problématiques réelles de conception.
    L’agilité est parfaite pour une équipe exclusivement constituée de développeurs, mais elle est un frein à la qualité de conception.

  10. @Nigel Le Product Owner à une position centrale dans les processus Agiles.
    L’agile ne préconise en aucun cas de laisser les développeurs faire les choix d’ergonomie. C’est même l’inverse puisque l’objectif est de « coller » aux besoins.
    C’est le rôle du PO.

  11. En lisant ce post, cela m’a fait penser au Bloc-Notes de Bertrand Duperin, conseiller en management et entreprise 2.0
    http://www.duperrin.com

    Il retrouve les mêmes problématiques avec les managers, la hiérarchie et l’organisation d’entreprise, qui sont en « command & control », qui sont sans confiance envers les exécutants, et qui sont bloqué dans de vieux schéma de production, très bureaucratique, mais protégeant leurs fesses en cas de gros soucis.

    Quelques exemples :

    http://www.duperrin.com/2012/07/12/frustre-de-perdre-le-pouvoir-hierarchique-devenez-client/

    Résumé : beaucoup de managers craignent, avec l’évolution future de leur rôle, de perdre le contrôle sur le travail de leurs équipes. Une situation que d’autres vivent très bien en transformant le lien hiérachique en lien “client/fournisseur”. Visiblement plus efficace, ce dernier pose à nouveau la question de la confiance dans l’entreprise.

    http://www.duperrin.com/2012/07/26/pas-assez-dengagement-ou-echec-manipulation/

    Résumé : l’entreprise de demain, sociale, 2.0 ou peu importe a besoin de l’engagement de ses collaborateurs. Problème : tout montre qu’ils sont de moins en moins engagés. Inquiétant mais quelque part logique, tout dépendant de ce qu’on met derrière la notion d’engagement. En effet, devant le peu d’empressement à faire évoluer les modèles d’organisation et l’impérieuse nécessité de le faire, le terme est de plus en plus dévoyé pour, dans de nombreux cas, se résumer à faire porter le poids et le risque du changement aux salariés sans contrepartie, soutien, ni garantie.

Laissez un commentaire