Faire de l'agilité à l'échelle de l'entreprise - Part I: le constat

“Il n’y a rien de constant dans la vie, si ce n’est le changement” - Bouddha

Avant la révolution numérique, l’accès à la connaissance, le partage d’information étaient plus complexe:

  • Clients comme employés étaient alors peu informés et captifs
  • Le franchissement, de ce que nous appelons les « barrières à l’entrée », était compliqué à franchir

Toute entreprise pouvait, alors, se permettre de faire des plans stratégiques à 10 ou 15 ans sans trop de « risques » et les dérouler tranquillement car le monde était prévisible.

Mais la révolution numérique a, totalement, transformé les comportements individuels et sociaux à travers l’usage des nouvelles technologies. Les notions de temps et d’espaces sont, dorénavant, totalement chamboulées. Les façons d’accéder à la connaissance, à l’information sont profondément modifiées. Les changements induits sont profonds: Clients et employés sont devenus « hyper » informés », ils ne sont plus captifs, Les barrières à l’entrée n’existent plus pour la plupart des marchés.

Cette révolution technologique doit être vue comme une rupture dans les modes de fonctionnement existants. Le progrès est constant, les besoins évoluent de plus en plus vite, il devient impossible de piloter des projets à long terme. Aucun business n’est plus à l’abris d’être remis en question à tout moment. Aucune entreprise ne peut se permettre des plans à 10 ou 15 ans, tant le monde est devenu complexe.

« Adapt, collaborate, iterate”

Les monopoles établis, sont aujourd’hui remis en cause de tous côtés par de nouveaux acteurs qui n’ont pas peur de prendre des risques. Ils s’appuient sur un modo très simple «Fail Fast, Learn Faster».

Conscient eux même qu’ils peuvent être disrupter, ils cherchent à apprendre vite pour mieux pivoter si leur idée n’est pas bonne afin de trouver le fameux “product market fit” tant recherché.

“Ideas are easy. Implementation is hard” - Guy Kawasaki

Cette réussite éclair d’acteurs de la nouvelle économie a fait devenir, en quelques années, l’agilité, la coqueluche des acteurs de l’économie traditionnelle en recherche d’un second souffle.

Les dirigeants de ces entreprises historiques y voient le graal dans la quête de l’amélioration perpétuelle de l’efficacité opérationnelle désormais nécessaire dans ce nouveau monde numérique.

Ainsi au cours des dix dernières années, plusieurs initiatives côtés IT, dans différentes entreprises, ont été lancés avec plus ou moins de succès, pour créer des équipes travaillant sous approche agile (Scrum pour la majorité).

Depuis 2017, on voit une forte volonté des acteurs de l’économie traditionnelle de déployer les concepts de l’agilité sur l’ensemble des strates de l’entreprise. Il ne se passe pas un mois sans qu’un article déclare que telle ou telle entreprise est passée, à ce qu’on appelle l’agilité à l’échelle.

On peut donc raisonnablement penser qu’entre 2000 et 2017, période que j’appellerai de “Bac à sable”, a permis à ces acteurs de l’économie traditionnelle d’appréhender les concepts de l’agilité.

Cependant plusieurs faisceaux d’informations me laissent penser que malheureusement ce n’est pas le cas.

Le premier faisceau est un sondage réalisé mi 2018, par le magazine en ligne CIO-online, sur le thème “Etes vous réellement Agile à l’échelle” met en évidence plusieurs choses:

  • 36% des entreprises indiquent que la plupart de leurs projets IT ne sont pas réalisés en méthodes agiles
  • 51% des entreprises qui déclarent faire de l’agilité, n’utilisent pas un cadre formel tel que Scrum (qui a fait ses preuves), elles y sont même parfois hostiles (sic!)
  • 37% des projets travaillant sous forme de sprints n’envisagent absolument pas le recours à l’utilisateur final pour avoir du feedback et donc ajuster le projet (arrgh!)
  • 50% des entreprises sont hostiles au DevOps
  • 59% des entreprises refusent la mise en place d’une démarche d’amélioration continue tel que l’approche Kaizen
  • 52% des entreprises n’ont pas formés leur IT et leurs métiers à l’agilité

Ce sondage est révélateur sur deux points:

  • L’agilité à l’échelle est une utopie,
  • La connaissance de la culture agile est un doux rêve car les bases que sont l’implication des utilisateurs, des métiers, la réduction de la boucle de feedback, l’amélioration continue, ne sont pas maîtrisées

Le second faisceau est mon constat quotidien dans mon activité professionnelle où il ne se passe pas une journée:

  • Où je lis, dans des AO, du waterfall déguisé en cycle itératif:

    • Chacune des itérations définies ci-après se composera des différentes phases suivantes :
      • une phase d’élaboration des spécifications
      • une phase de développement : sprint de x semaines (souvent 2 semaines)
      • une phase de recette de l’application, dont des tests techniques et performances
    • Chacune des releases (3 à 6 itérations) se composera des différentes phases suivantes :
      • une phase recette Bout en Bout
      • une phase de déploiement site pilote puis généralisation
      • une phase de réversibilité déclenchée à la fin du volet si reprise par un tiers ou par nous meme
    • Pour une Release, le donneur d’ordre dispose de 15 Jours Ouvrés, suivant la validation de la recette de la dernière itération du cycle, pour valider son contenu par des tests de bout en bout et de pré-production avant déploiement
  • Où je reçois, des propositions de missions de ce type:

    • Scrum Master (c’est en fait un Chef de projet renommé):
      • Connaître en permanence la disponibilité, la charge et le reste à faire de son équipe.
      • Contrôler et alerter l’équipe et le PM sur les tâches en retard
      • Répartir les tâches aux développeurs en tenant compte de l’expérience, la compétence et de la disponibilité de chacun
      • Gérer les risques, les budgets et les plannings
      • Reporting au management de l’avancement des travaux
    • Product Owner (C’est en fait une maitrise d’ouvrage renommée):
      • Est une sorte de Chef de projet digital
      • Gère une équipe composée de Designers et de Développeurs
      • Assistance à la maîtrise d’ouvrage : planification et suivi des projets avec les différentes équipes, rédaction des use cases
      • Assistance à maîtrise d’oeuvre : aide à l’élaboration des tests

Ces publications sont révélatrices d’une chose, nous sommes face à un phénomène d’agile washing à l’image de greenwashing pendant quelques temps par des entreprises qui voulaient paraître plus verte!

Le troisième faisceau concerne les publications et déclarations des signataires du manifeste agile:

  • The State of Agile Software in 2018 de Martin Fowler (Aout 2018): “The Agile Industrial Complex imposing methods on people is an absolute travesty”
  • Developers should abandon Agile” de Ron Jeffries (May 2018): “Too commonly, the “Agile” approach a team uses has been imposed. Larger-scale “Agile” methods appear actually to recommend imposition of process”
  • Time to kill agile de Dave Thomas (Mai 2014):”“The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.”

Ce constat crée un sentiment de malaise sur la planète Agile. Comment en sommes nous arrivé là aux points que les signataires eux mêmes appellent à quitter l’agilité? Y a t il des solutions pour faire disparaître le Dark Agile? Ceci sera l’objectif de mes prochains articles.

Liens vers les autres articles de la série